Net2WG/Notes/20071214
Net2WG/Notes Meeting Notes
Agenda
* Collection
Participants
* Om, USC * Phil, Stanford * Mike, JHU * Razvan, JHU
Discussion Notes
Collection
Om: I send an email, PHil you probably haven't look at it yet, you can look at it later...
Phil: About the one hour [[1]]?
Om: Yes.
Phil: Can we stop here for a second? It would really helpful if you'll organize the plots so that they will have increasing values. I see: 1, 9, 2, 8. 2, 8, 5.
Om: They are in the order of increasing time...
Phil: It's not helpful.
Om: It's harder to see, I agree.
Phil: Let me look at this. Mike and Razvan: did Om send this to you guys too?
Razvan: No.
Phil: Let me forward it to you.
...
Phil: Let me know when you get it. Is Rodrigo or Kyle on the call?
Om: No. That's why I don't think we'll have too much discussion.
Razvan: We got it.
Phil: Ok. Let's look at first two plots. These are the two basic numbers that we really care about. Delivery ratio and cost. Number one case is cost. Om, can you explain that is the difference between a and ctpa?
Om: The last for are the one hour runs.
Phil: What is the difference between a1, a9, a2, a8 and ctpa2, ctpa8, ctpa5.
Om: The last 4 (lqi3, ctpa2, ctpa8 and ctpa5) are the one hour runs. All the rest are from 20 minutes runs.
Phil: So what is matter is ctpa8 and lqi3. We know we don't want and alpha of 2 and we don't want an alpha of 5. If you look at these numbers, ctp has a lower cost than lqi and significantly higher delivery ratio. 99.9 vs 75...
Om: For Raz and Mike: ctpa8 means a ctp with an alpha of 8. Alpha is used as a decay factor in the link estimation.
Phil: Higher alpha means that you consider history more. Alpha of 1 means you put 90% of the weight in your current sample and 10% in the history. An alpha of 9 means you put 90% in history and 10% in the current sample. The reason we play with alpha is that what we see is that in Tutornet it varies rather rapid which lowers the delivery rates and causes enormous cost because the links are swinging around so fast. And that is causing loops and things blowing up. If we increase the alpha then we damp out those oscillations but still settle on the right links. Om, we can see that ctpa8, the one hour experiment, it beats lqi3 at cost and also beats it at delivery ratios. So overall it's up. How did you measure cost?
Om: Cost is all the transmission in the network.
Phil: So we beat it even worse because what you get is all the transmission divided by all the receptions. Cost per packet. If the delivery ratio is zero your cost is infinite. Since we delivery 25% more packet the cost is 25% lower.
Om: Right.
Phil: So this suggests that a value of alpha of 8 or 9 is the right value to use. We'll see how the ctp 9 looks like...
Om: We can imagine I think...
Phil: We should wait for the data.
Om: Yes. What is more important is, at least for my experimental settings, that higher alphas are good. I'm going to ping Rodrigo again to see if the same things holds for Mirage. Probably does...
Phil: It does because Mirage is much more stable. High alpha will hurt you only if link changes quickly and for long term periods because you're slow to adapt.
Om: Right.
Phil: We should still evaluate it. Let's look at average depth. What we see is that ctp is choosing more hops over fewer hops. That is weird. That is exactly that you wouldn't expect from lqi. You expect the lqi to choose longer paths but it doesn't.
Om: Yep.
Phil: This is totally because of the fact that if lqi sees a good link which is good 50% of the time it will chose it as a single hop. Having a higher alpha also brings the churn down. a8 has a lower churn. It has lower control because is has less churn. Aaa: look at the max degree!
Om: Yes, that is Rodrigo also saw on Mirage too.
Phil: lqi has a big fan-out. I bet is the max degree at the basestation. It must be given the average depth of 1 and 2. Basestation has like 20 children.
Om: What will require a little better understanding and I don't have right now is... the idea behind white bit was not to suffer from this. If you have regular bi-directional estimation most of the time bounded by the number of entries you have.
Phil: It's a startup. If you are right about how you feed using bi-directional estimates as you are with the the database estimates... but the problem is eventually you will coalesce to a network which is all database estimates. Did the lqi and ctp has the same retransmission count?
Om: Ctp has more.
Phil: It would be good to normalize that.
Om: Yep.
Phil: What is the value of fail?
Om: Number of fails normalized to the length of the experiment.
Phil: What is the transmission rate in the network?
Om: One packet each 8 seconds per node.
Phil: How many nodes?
Om: 56.
Phil: That's 7 packets per second. With a average depth of 1.5 for lqi that's 11 packets per second transmitted in the network and then we'll see a fail of let's say 2.5 so that's were most of packets are being lost.
Om: So far fewer fails with a larger total number of packets in the network because the depth is larger. The tree is deeper.
Phil: Yeh, but there are also more retransmissions per link which is partially what's going on. Oh, that's interesting! It says that the cost for ctp is lower but the average depth is much higher so there are more transmission but far fewer retransmissions.
Om: Exactly. It you look at wait, which counts all the retransmission, ctpa8 is lower than lqi. So the number of possible retransmission is higher but overall you don't end up doing a lot of retransmissions.
Phil: Right. Mike and Razvan, did you follow this?
Razvan: Partially. What full means?
Phil: Full is when your queue is full and you drop a packet.
Mike: What about wait?
Phil: Wait is you didn't get and ack and you retransmit. The term comes from the debug message which is ack wait. The packet was not ack and I'll wait a random amount of time before I retransmit. You don't retransmit immediately.
Om: What we were just talking about, if you look at wait, ctpa8 for example has lower number of retransmissions but if you go the graph with fail you can see that lower number of packet don't make it.
...
Om: I would say that overall the results concur. The crucial thing is alpha has a dramatic impact.
Razvan: Would it be possible to plot some of these graphs over time?
Om: Go one level up in the url. If you go on one of those directories you can see plots over time of various stuff.
...
Om: So that's about collection. Does it make sense to investigate how to make things work with low alpha?
Phil: No. If high alpha works then high alpha works.
Om: By the way: Tenet now also uses ctp.
Phil: Cool!
Om: So we'll get some experience from there as well. One interesting thing would be how to minimize the duplicates.
Phil: We still have to handle the low power question. We need to figure out how to bring the control traffic down. If we can do all these with LPL and then tweak ctp so maybe it doesn't retransmit immediately upon reception of a packet, when the queue is half full for example, that will greatly improve the energy efficiency.
Om: You can batch it.
Phil: Yeah.
Om: So those are the two main things. Loops are an immediate concern to me because we advertise the use of ctp in Tenet and now we can see the duplicates.
Phil: a1 has the highest number of duplicates, followed by a2, ctpa2, lqi1, lqi2, lqi3. So lqi has a lot of duplicates. Lqi3 for example: 50% of the nodes have 50 duplicates or less. Ctpa8 is down to 11 or 12.
Om: We might be doing better than lqi with higher alpha but I think this is also an obvious place to improve because we are getting quite some duplicates.
Phil: I would not be surprise if a good deal of them are at the last hop. The basestation doesn't do duplicate suppression.
Om: Yes, that's true. That's something I need to solve quickly. If the basestion would do the same thing what will be these numbers...
Phil: Cool. What we would like to see is ctpa8 and ctpa9.
Om: I'll work on that and also look at the duplicates.
Phil: I'm not as much concern with the duplicates as I am with the control traffic. The duplicates looks fine. They are better than lqi. We want to look into to see how many are last hot but I don't think we need to improve them further. The duplicate suppression is quite robust. It will catch duplicates on the same path. You only get a duplicate when you send to A, you don't get an ack and then switch to B and sent the packet. Both will send to the basestation and you'll get a duplicate.
Om: I remember I did an experiment when I increase the cache but that is not helping.
Phil: No, it's not. That's only if you burst packet. We need bring down the control traffic and show the LPL working.
Om: All right. About other things. We already heard from Matus. I heard from Andre about thinking about files and where everything should go. We haven't seen anything concrete but there is communication and I think they are still committed to contributing Zigbee.
Om: One other thing. I'll setup a [[2]] and ask people if they want to reschedule the meeting.
