Net2WG/Notes/20071221
Contents
Net2WG/Notes Meeting Notes
Agenda
* Collection * Deluge * DIP * Zigbee / 6lowpan
Participants
* Om, USC * Phil, Stanford * Kaisen, UCSD * Rodrigo, Berkeley * Andreas, JHU * Mike, JHU * Razvan, JHU
Discussion Notes
CTP
Om: Alpha 9 seems to be the best on Tutornet. I have also checked-in the getlinkquality fix suggested.
Rodrigo: I have 4 hours reserved on Mirage today. I guess I will need to change the interval so that the network is not congested, maybe like 16. Should I run alpha 8 and 9?
Phil: I would suggest running alpha 5, 6, 7, 8 and 9, so you can see the curve.
Rodrigo: So, the problem with alpha 9 is that we don't react to changes, and there is nothing preventing alpha being even higher.
Phil: Suppoe alpha is 9, and a link dies. That gives a link quality estimate of 6. 6 times 0.1 is 0.6, which is a pretty significant change and likely to create a route change (assuming you have other candidates). Why don't we see what happens on Mirage. If it turns out alpha 5 is the best, that's going to lead us to a very different direction than if alpha 9 is also the best.
Rodrigo: It takes about an hour for experiment to stablize, right?
Phil: Time is not necessary relevent, the number of packets is, about 200 packets. Even if it takes half hour to settle down, on a network that is going to reliably run for months or weeks, it is not a problem.
Om: I have data from other experiments, such as LQI with 30 max retries for 4 hours, alpha 8 and 9 for 7 hours. I just haven't got the time to analyze.
Mike: Alpha 9 means you use 90% of the history, right?
Phil: Yes. To give a little background story. A low alpha can create a big jump in ETX if all the sudden you admit a few packets. Such jump can be big enough that routing loops become possible. So, on Tutornet, when we tuned up the alpha, the CTP became to perform well. Mirage is a relatively-stable network where alpha 5 works very well. We want to see if alpha 9 is also a good value on Mirage.
Om: Did you guys look at the graph on piece-wise linear stuff? The graph is labelled cum_good_cost. Looking at the first graph, you can see the jump, which I think corresponds to a lot of parent change. These are the results of a lot of retransmission to resolve parent change.
Phil: I think it is much easier to look at the derivates, rather than just these jumps. How do we know it is due to retransmission, it could be just due to parent change. If a packet has high THL, then the cost includes THL and retransmissions. So, I think you can compare a packet's retransmissions with THL.
Om: I think it would be interesting to plot those results from 7-hour run.
Phil: The graph I find the most interesting is the cum_packet_count_p_with_goodcost_greater_than_20. This is a distribution of time of packets that have high cost. 80% of high-cost packets for alpha 9 were the first half, and 20% was second half. This suggests that it is discovering good and bad links, and settle down.
Om: It is a little bit strange that it takes a long time to discover paths. Is it because we don't do a lot of beaconing?
Phil: If the path were stable and links have independent packet losses, then you wouldn't see something like this.
Om: What about LQI? Is it because it doesn't remember information, so it is linear?
Phil: Yah, it doesn't pay attention to the fact that packets are lost.
Om: By the way, have you guys looked at the delivery ratio by node ID? This is the one where packets from far-away nodes have lower delivery ratio.
Deluge
Om: Future requests for Deluge.
Razvan: The first point I still need to fix, and I hope to finish it by tonight.
Om: What about the second point?
Razvan: That isn't really fixable because flash is not there in TOSSIM.
Phil: I got a student working on that.
DIP
Kaisen: I have done limited testing and simulation. I just tested enough to see if it works. I don't know how much more testing you want.
Phil: The key thing is to test on a real testbed, like Mirage. Also, it would be good to test on multiple platforms, such as micaZ and telosb. You can also send it to Om for testing on Tutornet. Do you want to briefly talk about DIP?
Kaisen: It is a dissemination protocol that exchanges summary until it finds the missing item. The benefit is scalability.
Om: Something I requested was a recommendation on when to use DIP and when to use DRIP. For example, for collection, we say that if you are constrained on space, then use LQI. If you want to good performance, then use CTP.
Zigbee and 6lowpan
Om: I have not heard anything from them this week.
Phil: There is the free zigbee stack. Is that going to make its way into net2?
Om: Yes, that's the plan.
Phil: That's pretty impressive. When 2.1 rolls out, there is going to be DIP, 6lowpan, zigbee, 4-bit estimator and so on.
