Net2WG/Notes/20070817
Contents
Net2WG/Notes/20070817 Meeting Notes
Agenda
* CTP, next steps. * Moving existing TEPs towards community review * Arsalan's LL work - kill it or ressurect it? * Packet interface with message pool - kill it or ressurect it?
Participants
* Om, USC * Phil, Stanford * Rodrigo, Berkeley * Kyle, MIT * Razvan, JHU
Discussion Notes
CTP
Om: The first item is CTP next steps. We did some experiments about the white bit to see it it's useful or not and if it's useful how is best to implement it, what layers should implement what interfaces. We found out that the white bit is quite useful. Phil sent an email, during the week, with a figure that shows that shows that is pretty useful, it's a good thing to have and we have some ideas of which layer should export what bit. I think the plan is to implement this into the repository. I don't know the timeline but in terms of implementation there is not a lot. Are we comfortable about the parameters and general applicability of the experimental results that we obtained?
Rodrigo: About incorporating into the stack: there are there independent components, for example the Ack bit. The Link Layer is basically saying whether the packet was acked or not. This is a very useful signal to the Link Estimator. So, because of that we were able to drop the requirements that link estimates are bidirectional. I have no doubts that this should be incorporated as soon as possible.
Om: I agree. That part should be incorporated quickly. What do you think about the all 4 bits?
Phil: So the question is which of the 4 bits we are unsure about? The Ack bit seems pretty certain. The Pin bit is very certain, it has to be there. It's already there and it always was. So the question remains about the Compare and the White bit. The results in that figure 6 show the effect of the White and Compare bit. It's like a 13% improvement. So there is evidence that these things can help so the question is if there are situations when they hurt. Because if it happens that in 50% of the link layers this add up to 30% it's a pretty good justification for yes to me.
Rodrigo: The other side of figure 6 is the following: the topology of the tree changes, it becomes much broader. I don't see it as particularly troublesome in collection. Maybe the energy becomes more unevenly distributed.
Phil: I don't believe that. It's not possible in the sense that anything having a greater in-degree will lead to a better distribution of energy in the sense that root can have more children.
Rodrigo: That make total sense. I'm just saying the tradeoff is not absolutely crystal clear because some nodes are going to forward more packets than others.
Phil+Om: Yes.
Rodrigo: But I don't see that as a big problem.
Om: Well, network lifetime depends on how do you define it. If we said the lifetime is up to then the first node is dead then probably is a bad thing so have such a high in-degree.
Phil: I don't think that having a high in-dregree is bad. Each in-dregree is not equal.
Rodrigo: And we have a measurement: the cost. And the cost is much lower.
Om: Yeah.
Phil: Another way to look at it is: what is the distribution of sub-tree sizes of the children of the root.
Rodrigo: I think I computed the metric that was the fairness... Maybe we could compute the fairness of forwarded packets. Right? I don't think is a show-stopper though.
Om: When is the next release Phil? By that time we need to have an implementation on CC1000.
Phil: I'm not sure what the schedule is.
Om: 3 months?
Phil: Yeah. Around Sensys maybe.
Om: If it's November then probably there is not problem.
Rodrigo: The other question I have is about the White and Compare bit. By asking the routing layer if this is a good node and the routing layer say yes then CTP evicts a random node from the table and picks that guy. It increases the churn. Again, there is not a direct implication than that is bad.
Phil: Let's back up. Network efficiency CTP is making we can separate that out... For example, let say that Link Estimator Compare will always return zero and the White bit will always return zero. Is anyone harmed? Is the Link Estimator worse?
Rodrigo: It's like you don't have the link.
Phil: Yes. My point is that there is evidence that it help significant in some cases then the argument against should be based on the fact that it hurts.
Rodrigo: What I was trying to say is that these are the impacts that are now show in the figure. I don't think they particularly hurt.
Phil: Om's point is good though. What if we cannot do this on CC1000? It seems kind of lame to have this supposedly general functionality that can only be realized effectively on a single chip.
Rodrigo: Is the ack bit on CC1000?
Phil: Yeah, of course. It has acks. I was talking about the White bit and Compare bit.
Rodrigo: the Compare bit it obviously possible because is not dependent on the radio at all. Right? It's a routing layer thing. So the questions is if we can do the White bit.
Om: I was wondering that is your timeframe for you Kyle? Some time in September? Some preliminary experiments?
Kyle: Yeah, preliminary. Can we talk a little more about what we're shooting for?
Om: We want to know if White bit hurts CC1000.
Phil: I think what we really want to do is figure 6 for CC1000.
Om: Right.
Phil: And also figure 6 for Tutornet.
TEPs
Om: Next topic: Phil, we talked some time ago about moving our TEPS to community review.
Phil: I haven't look at them in a while. Thing haven't change in terms of the APIs. We should do a read over of them and then send them to the steering committee.
Om: These are commentary TEPs and we had CTP for a while in the distribution so it might be time to do that.
Phil: Yeah. 123 and 124, CTP and LEAP, they require a little more though.
Om: I agree. I was talking about Dissemination and Collection interfaces.
Phil. Yes. They seem to be pretty stable.
Rodrigo?: Except the unidirectional. Ack bit obviates most of the what's describe in LEAP.
Phil: But the 117 doesn't talk about LEAP.
Om: OK. Let's then try to look at them in the next two weeks and then send them to the steering committee.
Phil: It's basically your call. You are the only person that can send them to the steering committee. You decide when they are ready.
Arsalan's LL and Packet interface with message pools
Om: About two other things that were drop off: Arsalan's LL interface. What people think about this?
Phil: I've talk with Arsalan. I asked him What's up and he said: I was working for Microsoft, today is my last day. He's hoping get back to it but I have no idea in what direction it's going to go.
Om: Maybe we should wait till Arsalan calls back. Rodrigo, do you meet Arsalan often?
Rodrigo: Yes. I work very close to him.
Om: Do you mind chatting with him about the LL?
Rodigo: Yes.
Om: OK. Maybe next meeting will decide what to do. How about the packet interface with message pools and all kind of jazz we had in the very beginning?
Rodrigo: [...] It's kind of look like SP.
Om: Phil, you are the author of this proposal.
Phi: Which proposal?
Om: The packet interface with message pools and other things. It was the very first discussion we had in this group. It was dropped saying we can't really come to a consensus so let's try to do something simple, Collection and Dissemination.
Phil: I'm not convince that we need all the complexity of SP to do efficient networking. I think there a lot of useful observations in SP but part of the problem is there are also a lot red herrings. And it's important to distinguish the two. And that's kind of tough. The reason we spin around in circles so much is that you come up with all kinds of abstract things and stuff you might want etc but ultimately, the progress comes from putting a stick in the ground and whacking it. I think there are important protocols that SP cannot handle. If you really look at it, SP claims that is CDMA and TDMA neutral, but really is more TDMA than CDMA in the sense that you send bursts of packets and there is no rate control. If you want an interface that is MAC neutral it's something you have to deal with. If that make sense...
Om: It does.
[...]
Om: So interface as complex as this unnecessary.
Phil: If you look at the current interface from TinyOS, there is something that definitely inherits from SP: it doesn't have a linear queue of message. It has a pool of outstanding send requests and a queuing policy.
Om: The main goal is to optimize the power. Sending batches amortizes the cost of the preamble.
Phil: Any layer that can introduce delay can do that. The ? packet layer can do that today. If you are in listening mode you can wait till there are 4 packets or 2 seconds have passed then send.
Om: Can you are the Link layer to do that? To delay a number of seconds or up to a number of packets?
Phil: The queue can do that.
[...]
Om: It would also be good to hear from Joe about this. How SP was been instrumental in applications. Things that would not be achievable using simpler interface.
Phil: The real trick is that, on one hand SP is trying to be a completely general interface and implementation independent etc but if you look at it there are assumptions in the higher layers about how the SP is implemented. In the sense you don't have rate control or fairness and all this kind of things. Urgent bit for example. What is the Urgent bit mean? Right? That being said, having more experience would be great.
Om: I think they are using the SP as their radio stack.
Phil: Yes, I think they do.
Om: OK. We'll discuss this as well. The Collection seems now kind of done so we can try to add some things. That is all I have.
Phil: One thing: CTP is pretty solid from the Link Estimation point of view but it's still the question of low power. The focus was to reduce the cost, improve the routing efficiency. Now we leaked that problem so now we need to figure out how to make it low power. First step is to minimize the number of packet you send and then to make sure you transmit them at the right time. So that you don't waste energy.That would be a major thing forward. Wouldn't be fantastic to have in TinyOS a collection protocol specifically design to have really efficient low power operation.
Rodrigo: There are tradeoffs in the sense of how fast the network forms, what duty-cycle you maintain, what latency you get...
Phil: Absolutely.
Rodrigo: People might have different requirements.
Phil: The radio has a global low power setting. You can have a routing protocol that adapts to that.
Rodrigo: I think that's a reasonable set of challenges to go after next.
