Net2WG/Notes/20070824
Contents
Net2WG/Notes/20070824 Meeting Notes
Agenda
* TEP 118 / 119 * lib/net directory structure * SP and Arsalan's LL work * LPL with dissemination and CTP
Participants
* Om, USC * Phil, Stanford * Razvan, JHU * Mike, JHU
Discussion Notes
TEP 118 and 119
Om: I looked at the dissemination TEP, and it looks OK. I will look at collection TEP today. I am thinking of forwarding to aliance in a day or two
Phil: I think there are couple things in the collection TEP that might need change. In particular, there are some statements that are kind of backwards. For example, "CollectionC SHOULD NOT set a node to be a root by default". What it really wants is "it SHOULD make a node to be a non- root by default". There are also some services from which generic components are instantiated, such as CollectionReceiverC, a CollectionSnooperC, and a CollectionInterceptorC. Finally, 119 should reference MultihopLQI.
Om: It probably doesn't hurt describing the implementation in a paragraph.
Phi: Collection is pretty sparse in that it shows you only the component and interfaces, but not how they look like, which makes sense because it is covered in CTP TEP.
Om: I think I will send the dissemination TEP to David Culler for now, and maybe collection in a week because there might be some changes.
lib/net dir structure
Phil: Did you see my response about moving things around.
Om: Yes. One comment about the naming is that it is not going to be obvious. My names are longer and that's the minus.
Phil: I agree. You choose what you are naming. For example, you need to specify which collection layer you are going to use by specifying lib/net/ctp or lib/net/lqi. So, that was just kind of my point. You want to be able to set the dissemination layer, whether it is for any dissemination layer. But, if you want to take a particular one, then you have to say lib/net/dip or lib/net/trip. Now, certainly, we need to better advertise those names for people who are new at something.
Om: When we have 6lowpan, we will probably put the interfaces in lib/net as well to follow the same convention.
Phil: Yah. 6lowpan is a particular protocol, so, follow the way you've done it, interfaces in lib/net are for programming instructions or services, but then the protocol specific stuff is in the sub-directories.
Razvan: What if someone wants to use two collection or dissemination protocols simultaneously? We have components, like CollectionSenderC, inside each of those folders, and one will take precedence.
Phil: Generally as the case in TinyOS, CollectionSenderC maps to one specific implementation, and it will be the implementation that comes first in the include directory. That being said, if you want to use LQI and CTP running on the same node, you have to make new like lqi_collectionSenderC, or you can wire directly to lqi/collectionC. Any top-level service has a single implementation that is global enough to cross the name space. If you want a particular collection layer, you should not use the collection-layer-independent name, you should use the particular name.
Om: Also the name is slightly different, there are usually prefixed.
SP and Arsalan's LL work
Phil: Arsalan sent me a list of observations, and I ask him to send to the list. There are a bunch of good stuff, but there are also some stuff that might not be completely necessary. What Joe found in practice that might be useful for SP has been amazingly useful for applications built at Moteiv.
Om: So, hopefully, Joe will respond to my e-mail.
Phil: Moteiv certainly has experience in applications that none of us do. So, they might have some observations.
LPL with Dissemination and CTP
Om: There is a post on the list about running dissemination on LPL. That person said dissemination is very slow compared to collection. Because dissemination messages are not retransmitted that fast?
Phil: It uses Trickle, and that's the whole point, unicast is much faster than broadcast because you don't know how many people can answer the broadcast.
Om: With LPL, I think the timing in some sense will no longer be valid. I wait for a certain amount of time, if I don't hear update, I am gonna retransmit. That time needs to consider how long the radio spends in sleeping.
Phil: Well, if the radio check interval is larger than the minimum trickle size, such that it takes longer to send a packet than a trickle interval, then we will have trouble.
Om: But it doesn't matter if it is longer
Phil: No. I think that in theory this works, but it doesn't mean in practice it does in terms of interaction.
Om: Now for CTP control messages. I don't think for regular beacons it matters because there is very little timing assumption. The only place where it may make a difference is when we send the pull bit. Even there, if some of the nodes reply and some wait for the reply, I don't think it matters.
Phil: For the general routing beacons, it doesn't matter. But there are situations where timing matters, not with pull bit that controls how quickly a node can get update, but rather on routing layer. When CTP discovers a routing loop, it sends out a beacon. And, there are some timing there, which is suppose to go out before the data transmission forwarding. Generally, if you have any comm management system, you want to cluster packet transmission to amortize the wake up cost, whether it is to respond to a wake-up packet from LPL. That's something CTP is not aware of. You know, like, wait to send packets until there are couple of packets in the transmission queue, call off the routing beacons, and that kind of things.
Om: It seems some control messages might have problems. For data transmission, it is probably not a problem, other than retransmissions. CTP uses sendDone to do retransmission, so it is going to be very slow.
Phil: LPL signals sendDone after acknowledgement, so retransmission is slow. CTP assume the radio is always ON, and it has forwarding timer. So, after it sends a packet, it waits a few packet time before sending the next one. This is fundamentally what you don't want to do.
Om: Maybe we go back to this SP-like interface. In that case, you can update the number of outstanding packets. Lower level can query for the next packet before turning the radio OFF.
Phil: The only reason SP did that is because sendDone is not async. With this give-me-next-packet, it is essentially a sendDone issued in async context. After a transmission is completely, LPL waits for a maximum of packet time before turning the radio OFF.
Om: This time is enough for forwarding engine to queue another packet?
Phil: Yes. Actually, what David Moss implemented is if you receive a packet, you stay ON for a few packet time. If you receive another packet during that time, you reset the timer. So, node A sends packets to node B, and node B finally wakes up. Now, node A will get the ACK immediately.
Om: Now, if we have forwarding engine on top of LPL, then for packets that will be forwarded, there is no delay between send and sendDone. The same will probably be true for retransmitted packets also. Would forwarding still work without much delay?
Phil: I think it is a totally open quesiton.
Om: This is the next major thing for CTP.
Phil: One of my students was working on link characteristics, and has found that sending packets in burst is a really good idea. Because packet loss is not independent, if one packet succeeds, the next one will also probably succeed. So, you should send packets until one is lost, and try somebody else. Going back to you point where some MAC layers can give better retransmission than routing layer can. I am worried that we come up with a perfect abstraction for all MACs, but we don't have some of them to test on.
Om: The forwarding engine still needs to take care some of the timing issues for forwarding packets, if not for retransmission.
Phil: I think if we stick with the protocols that we have, and come up with a good soluiton for that. I think that is a concrete way of moving forward.
