Net2WG/Notes/20070907

From TinyOS Wiki
Jump to: navigation, search

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


*