Net2WG/Notes/20061012
Meeting minutes for October 12th, 2006
Present: Phil, Om, Rodrigo, Sukun
Notes: Rodrigo
Phil: I found one bug in CTP in the Link Estimator, when calculating ETX: there is a division by 0 if you have many transmissions and no success. (note : the context here is that when you send data packets, you count how many actual transmissions and divide by the number of successes. If you have no successes, you are dividing by 0).
Rodrigo: Om, I am going to test tomorrow, did any of the scripts for testing change?
Om: I just had to adjust the offset of a field by one.
P: We should add the scripts to contrib, so that people could download the test framework. It's not part of the core protocol, but people can still do the tests if they want to.
P: Another thing: there is a low power CC2420 stack now. I haven't checked it in, but will soon. We should get this working with the low power. It will be a good test for both the collection and the low power stack itself.
O: What does it actually do?
Phil:LPL
Om:How are the packets made long?
Phil:Sends the same packet multiple times
Rodrigo:This should play well with the trickle timers we are using for the beacons.
P: I see no problem.
Phil: In Sensys this year there are 2 papers on low power stack, from ISI and Boulder.
Om: ISI is quite complex. The Boulder one doesn't require synchronization.
Phil: it's good to have two papers, two points of view
Om: I think this LPL is closer to Colorado than ISI.
Phil: seems to be.
P: We should be discussing Arsalan's proposal soon. I will also be generating a smaller proposal for the link layer, radically different.
Phil: packets being ack'd but not being received by the basestation I guess one problem is a divide by 0. You have EWMA over samples of link quality. Two source of samples are direct ETX and beacon estimates. The beacon estimates are EWMA.
Om: I am not doing EWMA on the data. We have on estimated EWMA, and one beacon EWMA. When I find ETX on the last data transmissions, I use it on the main EWMA. On the beacon side, I use estimates over some number of packets.
P: might be good to make the link estimation rate be the same as the beacon rate, so that the link estimator doesn't generate its own packets.
Om: Let's talk about when to send beacons. We're dynamically adjusting the rate for routing beacons, between 4 and 1024 seconds. There is a LE packet at least every 64 seconds.
P: The way this is working is that if your table is stable, you have a small # beacons. There are three things that can trigger a reset in the beacon timer:
1. if your path quality changes significantly 2. if your table is empty. You also set the pull bit on your beacons when you do that 3. if you receive a packet with the pull bit in it
P: it might be good to set the lower limit of the timer to be 1s.
Om: Let's step through this: how would bootstrapping work?
Phil: Initially, your tables are empty, a node will send beacon with short time intervals, with the pull bit set. The neighbors will then engage into an active period of estimations, and the tables will be populated
Om: Likewise, if a new node joins, it will send a beacon with the pull bit, the neighbors will send messages
R: in this scenario, are the beacons sent by the neighbors synchronized? That might be dangerous.
P: the are randomized within an interval. The interval has an exponential time increase. This was in Trickle early on: I don't know how many people are here. I should exponentially decrease the rate to avoid ack implosion.
R: I will run tests on the Mirage tomorrow.
O: any idea of why the beasestation is missing some packets?
P: one hypothesis is the 802.15.4 ack bug.
P: the other is that on the basestation, data packets are actually forwarded to the UART, using a 1-deep queue. We may be loosing these, because it's competing with the debug traffic.
R: how is the UART being multiplexed?
P: just like the rest of AMs: fair queueing among clients with a 1 deep queue.
P:let's have another dbg msg, telling 'Fail to send to UART', for finding whether this is the error
Sukun: I was wondering if a shim layer could do the forwarding to the UART on behalf of the application.
P: absolutely
Om: will do some tests.
P: Increase the rexmit fail count to something large.
R: won't you waste energy doing that?
P: the goal is to have you scan the table trying to retransmit. you should retry at least until the next table refresh.
P:code freeze in two weeks. We can't push this, but we are in good shape. Look, we have 95%, and we think we can get a 100. We should present in the birds-of-a-feather section in Sensys.
R: how long is presentation? 5 minutes
P: Talk about CPT. Pushing this stuff forward. Collection: no one fully solved the problem. we want to be the closer in this chapter.
P: there are many tcp papers are in Sigcomm, and some people complain, but TCP works really well. People could figure out all ways to improve it, but it was still standard that the could use throughout
R: and the spec of CTP is open in some aspects to allow experimentation while keeping the different implementations compatible.
O: how is the pull bit story in the TEP?
P: when you receive a pkt, you should xmit beacon reasonably soon. SHOULD is there to allow suppresion if you want it.
O: so here are the action items following this meeting:
* change the ETX computation * UART msg * change the routing timer 1,1024 * disable the link estimator own beacons * set the xmit max to 30, such that the total time transmissing is > routing beacon minimum time
