[net2-wg] mirage progress

[Rodrigo Fonseca]

On 6/16/06, Philip Levis <pal at cs.stanford.edu> wrote:
> On Fri, 2006-06-16 at 10:22, Rodrigo Fonseca wrote:
>
> > That may be the case. The link estimates do change a little, and are
> > stable, but the timescale of those is 10 times slower than the data
> > rate. There could also be a bug in the acknowledgement code at L2?
>
> If 130 is not receiving the packet, it makes sense that it's not
> acknowledged. It is unlikely that there is a bug in the L2
> acknowledgment code.

Ok.

>
> > A couple of directions:
> >  1. having more than one option to use as a next hop. This was the
> > original interface, getNextHops. A sensible policy, given the recent
> > measurements, would be: try twice on a link, if it fails, try another
> > neighbor, until some maximum.
> >  2. feedback from failed acks to the link estimator: differently from
> > having data packets go through the link estimator, this is similar to
> > Phil's early email: some sort of signal from the ForwardingEngine to
> > the LinkEstimator, saying: "I have just had a message transmission
> > fail in the link to A" and "It took me 5 retransmissions to get this
> > across". This could be incorporated into the math to compute link
> > quality, it can probably lead to a good "Expected Transmissions"
> > measure.
>
> I'm (of course) of the opinion that this last mechanism is better: it
> lets the FE tell the LE that 0 of the past 5 packets have succeeded,
> then the RE can update its estimates, etc. But if you think that 1) is
> better, I would not object to taking that route (haha, pun intended).

These are not exclusive, in fact. We discussed two ways of doing 1),
and I will go ahead and implement the getNextHops call in the
UnicastNameFreeRouting interface.

After that we can test by changing the ForwardingEngine.

The second option I think requires more careful thinking on how to
change the link estimation function.

>
> > What to do for the release? The code is failing because messages are
> > being retried forever: this causes interference at nearby nodes and
> > flows, and fills up the buffers. Should we add a maximum number of
> > retransmissions and drop the packet?
>
> I think that we should not drop the packets. If the protocol is
> implemented so that the only cause of packet drops is queue overflow,
> than an ECN bit will be an easy way to approach 100% reliability (with
> backpressure at sources).
>

That works provided there are back pressure and alternate route
mechanisms, otherwise the whole thing grinds to a halt. One problem
with the current code is that the parent is not changed among retries:
the routing engine is only asked once, and not at each retry, so even
if the routing were to change the route the message would still fail
forever.


> The interference should not be *that* bad: there is a 128-256 retry
> timer on a failed ACK.

That is true, especially in this case when there is only one route.

>
> Phil
>
>