[Olsr-dev] Some reflections on link state routing and metrics

[Henning Rogge]

Am Tuesday 10 February 2009 15:59:53 schrieb Markus Kittenberger:
> > not good... ETX metric works because it does NOT try to calculate unicast
> > loss. This way we get bad LQs before unicast starts to degrade.
>
> but ignoring unicast loss completely brings us to much more unwanted
> behaviour
>
> and (btw. broadcast) loss degrades the netto bandwidth i used below for my
> complete cost function,..
And unicast loss is related to broadcast loss, so we might just continue to 
work with broadcast loss.

> > This would be included in the "bandwith" value we can get from the rate
> > control algorithm. Because it includes retransmissions.
>
> but this includes it only linear,
>
> but unicast loss behaves for sure not linear to broadcast_loss or
> netto_bandwidth!!
> of course having the number of failed retransmission would be the best, and
> i think this values is available from maclayer,..
> this would imho be the only perfect solution, ...

Just divide the througput from the ratecontrol algorithm by the unicast 
transmission rate. If you get 1.0 there is no unicast retransmissions, if you 
have 0.5 you have one retransmission for each packet. This could be a 
measurement for delay (because waiting times for retransmissions).

> > > if impossible to detect we should better use a lower one, and not 7
> > > and if we offer a value in the config file to override this
> > > retry_count, this should be flexible enough,..
> >
> > No, that's a BAD idea... either we detect it from the maclayer or we
> > don't use
> > it. Making values like this (which can change from kernel to kernel !)
> > configurable sounds like a desaster waiting to happen.
>
> there will always be interfaces where you will not be able to detect it,..
> because they are inside a different piece of hardware for example (our
> beloved/hated 5ghz bridges for example)
> the question is what is the bigger disaster:
> ignoring it, or making it possible to configure it wrong,..
> but one way out of this dilemma is just to detect unicast loss with test
> packets, at least when we can`t detect it from maclayer
See above. No need to guess this parameter. The only interesting additional 
value might be the total number of failed transmissions (failed for layer 3, 
so all retransmissions on mac layer failed).

Henning Rogge

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090210/38bcf416/attachment.sig>