From TinyOS Wiki
Jump to: navigation, search


Net2WG/Notes/20070511 Meeting Notes


* Deluge


* Om, USC
* Rodrigo, Berkeley 
* Phil, Stanford
* Mike, JHU
* Razvan, JHU

Action Items

* Phil: Examine CTP link estimator behavior under new TOSSIM
* JHU: Check in Deluge

Discussion Notes


Om: We talked about TTX a bit last week. Phil, any additional comments from TTX?

Phil: There was a comment about us not providing not 100% reliability which is necessary in many real world applications. Kyle's response was providing high reliability with CTP will enable other end-to-end protocols to provide 100% reliability efficiently. Next step for net2 might be to implement such an e2e protocol.

Om: Any thing jumped at you from the contrib session?

Phil: SNPK. The slides are on the web.


Om: Let's talk about Deluge.

Mike: I've been testing Deluge and wrote the Deluge manual. It's a draft, but it's complete.

Mike: The results are that the code is working fine. I also benchmarked Deluge. I tried to disseminate an object of 20K in our testbed. It took about a minute. This result can vary depending on your topology. I generated a timeline of the behavior, and I can see that it's 2-3 hops. I kept all the parameters the same as in T1. Just a direct port.

Mike: We also have a potential external tester. But he is using micaZ. Currently we only support Telos.

Razvan: The issue is TOSBoot.

Om: I'm happy to do testing on Telos. We have a 90 node telos testbed. You should check in the code, and put in testing scripts.

Razvan: Because we have TOSBoot, we have not modified the make system. It's not integrated that well.

Phil: What's the timeframe for TOSBoot?

Razvan: Prabal says he's busy until the 24th.

Om: So let's talk about where to put the code.

Phil: How about tos/lib/net/deluge?

Om: Should we worry about names? Is there a name for the dissemination protocol that Deluge uses?

Mike; We call it Deluge.

Razvan: We sit on top of BlockRead and BlockWrite.

Phil: Does Deluge have an abstraction on top of block read/write?

Razvan: No.

Phil: So we don't need tos/lib/deluge?

Mike: Correct.

Razvan: One issue with the original deluge was that it took advantage of a particular format of the flash. We don't do that any more. We just disseminate large binary images.

Mike: All of the parameters are as they were in T1. We're just disseminating large data objects.

Om: So should we think of Deluge simply as a protocol for disseminating large objects, and one possible application is new binaries.

Mike: Right.

Razvan: So currently we have a Deluge component that does the dissemination. We also have something sitting on top of that that does the thing that causes TOSBoot to load the right image.

Mike: Another component is the network service part, and that's the part we're primarily responsible for. It's basically the dissemination.

Om: What about the Python tools?

Mike: That's part of the network service, so we're responsible for it.

Om: So there are three sets of code. The first is programming: TOSBoot. The second is dissemination: Deluge. The third are these scripts. How do we pull these three things together?

Razvan: There is currently a sample application that includes reprogramming.

Om: I guess, eventually, some applications will have Deluge enabled by default. Like MultihopOscilloscope.

Om: Is there any timeline for the next release?

Phil: Beginning of July.

Om: Does that fit with the timeline for Deluge?

Mike: Looks good from our side.

Om: How about TOSBoot and things?

Razvan: Depends on Prabal. We could port.

Phil: It might be in your best interest to just do it yourself, if he's busy until the 24th.

Om: Does it make sense to get other people to help out with testing? It sounds like the protocol is almost ready.

Mike: External review is good. Currently we support telosb only.

Razvan: In addition to TOSBoot, we have some applications that use the network service.

Om: Applications should go into apps/ or apps/tests.

Phil: The control path can go into tos/lib/net/deluge too.

Om: Anything else?


Phil: We discovered that CTP does not choose links quickly enough and settles on sub-optimal links. Can easily cause lot of control messages. How do we fix these things?

Rodrigo: Decoupling who you send packets to and who you advertise as a parent. Even after changing the parent, make sure the parent is good before advertising it.

Phil: If we reset the timer after changing the parent, then we wait long enough (1s?) to advertise the new parent.

Phil: Selection threshold should be lower. In our EWMA, new hybrid estimate gets a weight of 0.8. Because we can get fast estimates we should probably consider a smaller weight for the new estimates.

Rodrigo: So it seems we need EWMA weights and less control traffic.

Om: Maybe there are better experiments to study the link estimator. Maybe run many link estimators (with different alpha's) simultaneously.

Rodrigo: It is difficult conclude anything from a study of a link estimator alone without any data traffic.

Phil: We could use the T2 simulator to determine the ground truth and compare that to the estimator outputs when running CTP with data traffic. Maybe that is the first step.