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

[Henning Rogge <[e-mail]>]

Answer to Georg Wittenburg, Teco Boot and David Young...

Am Freitag 13 Mai 2011, 16:23:19 schrieb Georg Wittenburg:
> > The funkfeuer metric drafts suggests to use all RFC 5444 packets for link
> > loss estimation, not only a certain message type. Your suggestion would
> > make it necessary to pad all RFC5444 packets to the maximum MTU, which
> > might be a considerable overhead.
> 
> I agree. However, it still remains true that link loss estimation that
> relies excessively on small packets will lead to suboptimal results. I'm
> aware that the original ETX paper doesn't cover this, but it doesn't mean
> that it shouldn't be addressed in this draft.
> 
> How about, for example, only incrementing the respective counters for
> packets whose size is above a certain threshold, say MTU / 2 (or even MTU
> / 4)?
What if no OLSR packets are that large ? Do we add padding to get at least one 
or multiple large packets each second ?
 
> > We do this in the Freifunk/Funkfeuer meshs, but in NHDP/OLSRv2 this would
> > be the job of the link hysteresis (which easily could be implemented
> > based on the link cost value).
> 
> But since the link cost value depends on the metric used, it would be up to
> this draft to suggest values for this, wouldn't it?
We had some discussion about this, but it seems that most people here don't 
like to use the link metric to do the hysteresis.

In Freifunk/Funkfeuer, we ignore each link with an link quality below 0.1 in 
one direction.
 
Am Freitag 13 Mai 2011, 17:53:53 schrieb Teco Boot:
> > How about, for example, only incrementing the respective counters for
> > packets whose size is above a certain threshold, say MTU / 2 (or even
> > MTU / 4)?
> 
> How can packet sizes of lost packets be measured?
Maybe with a second packet sequence number that is only increased for large 
packets ?

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...

I personally like the idea to get the rate control data of the mac80211 stack 
in linux, unfortunately that only solves the problem for a very special case, 
and only for unicast traffic.

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.

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized


-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized