Net2WG/Notes/20070511
Contents
Net2WG/Notes/20070511 Meeting Notes
Agenda
* Deluge
Participants
* 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
TTX
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.
Deluge
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?
CTP
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.
