Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01

[David Young <[e-mail]>]

> Am Freitag 13 Mai 2011, 18:46:30 schrieb David Young:
> > You can probably derive a much better metric than ETX by tapping into
> > information that the rate adaptation collects.  More than one 802.11
> > rate adaptation in the literature has tried to optimize the so-called
> > goodput of a link by choosing a suitable bitrate for each packet based
> > on packet properties such as size.  Advantages of collecting information
> > from the rate adaptation are that you avoid duplicating any code or
> > computational effort, and you collect the information from a more
> > suitable (IMO) place in the network stack.  All the world's MANETs are
> > not built on 802.11, it is true, but the same general principles apply:
> > don't needlessly compute the same metric twice, and collect the link
> > metric at the most suitable place.
> Doing this on one operation system with different wireless cards is hard... 
> doing it for multiple operation systems and different cards will get you 
> insane pretty quickly...

Let us cross our fingers and hope that each OS provides a uniform API.
:-)

> If you rely on the rate control, you need to send unicast probing packets to 
> all of your neighbors regularly if you have no traffic in this direction.

It seems to me, too, that that is a problem with using a rate
adaptation.  One hopes that there are probe packets or else that the
inherent background unicast traffic keeps the rate adaptation fresh.  I
think that having to induce some unicast traffic may be a reasonable
trade-off for being able to derive a link metric from the rate
adaptation.

FWIW, I have lingering doubts whether or not a link metric can be
updated or link metrics propagated nearly as quickly as the channel
makes a substantial change of state.  From N hops away, a single metric
for a link may not be nearly as useful in a routing decision as the
historical range or distribution of metrics on a link.  People have
experimented with "opportunistic" routing/forwarding, I think this is
why.

Dave

-- 
David Young             OJC Technologies
[e-mail]      Urbana, IL * [phone] x24