Net2WG/Notes/20070907
Contents
Net2WG/Notes/20070907 Meeting Notes
Participants
* Om, USC * Mike, JHU * Razvan, JHU * Phil, Stanford
Action Items
* Om: TEP shepherd, collection components, 4BLE * Phil: mica2 white bit
Next Meeting Agenda
* Send interface (Arsalan?) * Dissemination (Kaisen?)
Discussion Notes
Dissemination Implementation
Om: What should we name it? TRIP? Trickle? DRIP?
Phil: I'll ask Gil what he thinks.
Dissemination TEP
Om: David responded about the TEP. He asked if we had any recommendations for a shepherd.
Mike: What would the shepherd do?
Om: Responsible for getting comments from the community.
Phil: How about John Heidemann? Om, can you ask him?
Om: I can ask. I think David will also look for people. I will send him an email.
Enhanced Send interface
Om: So we had this discussion, do we need SP or not? Joe gave one comment, that changing the receive interface is helpful.
Phil: I don't think that was his one comment!
Om: He said that it tended to reduce errors. Everyone saw this email.
Phil: Agreed -- I think that's right. This is something that has come up a few times. There are basically three reasons why buffer swapping has remained. First, once you institute a copying interface, then you have to copy at every layer. E.g., layer X copies out 50 bytes, passes 45 bytes to layer X+1, which copies 45 bytes, passes 42 bytes to layer X+2, etc. The second reason is that it's a one-way street: you can implement a copy interface on top of a swap interface, but not vice versa. The third reason is the cost when you get to large packets (especially considering the layering problems).
Razvan: I think that the Pool has made it easier.
Om: Agreed -- queue and pool have made it easier. In TinyOS 1.x, we didn't have those abstractions, that made it harder.
Om: Well, there were no comments on the send interface.
Phil: I think the reason Arsalan is not here is because he has a meeting at Berkeley now.
Om: We can ask Arsalan where he wants to go with this.
New Collection Components
Om: Phil sent a suggestion for additional collection components, and a better way to organize them. I had a question about the snoop interface? Is that necessary?
Phil: Well, there have historically been some examples when this has been useful, e.g., for aggregation.
Om: CollectionReceiver, Interceptor, Snooper: do you need snoop as well as intercept.
Phil: I'm not convinced it's critical: it's in the signature of the collection engine. I mean, nobody has asked for it. It could be a MAY rather than a MUST.
Om: But interceptor, we would need that. That was the one question I had. I think making Snooper a MAY is a good idea.
Merge FourBit Into the Tree
Om: We are pretty much ready. The only think I am not sure about is the issue of unidirectional versus bidirectional estimation.
Phil: Bidirectional estimates constrain your indegree -- they need to go. The ack bit fills in.
Om: So there will be no reason to have bidirectional estimates. Would there be a problem with this? I guess not. Let's look at this historically -- the first ETX work, in that era (2003), some information was available in the link layer, from the driver. Why did they do ETX rather than use ACKs?
Phil: Maybe it just wasn't obvious at the time?
Om: OK, so this is great then. This is a significantly different stand, a departure from the MintRoute paper. It's for good. Especially the degree constraint. OK, I just wanted to discuss that briefly.
Om: So I guess that we have to trim down the data structures.
Phil: We should probably do a code cleaning.
Om: Well, we can replace /le or make a new one.
Phil: If we make a new one, then it can be another LEEP implementation that's interoperable (but better). It sends the footers, just doesn't happen to use them.
Phil: Since Kyle is hosed for NSDI, I might do the mica2 white bit.
Misc
*
