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

[Henning Rogge]

Am Tuesday 10 February 2009 13:44:42 schrieb Markus Kittenberger:
> On Tue, Feb 10, 2009 at 12:41 PM, Henning Rogge <(spam-protected)> wrote:
> > It's a matter of mapping. We could map the raw transmission speed to a
> > value
> > between 0 and 1 and THEN combine it with the LQ from the ETX algorithm
> > with a
> > weighted sum.
>
> combine with + or with * ??
for example like this:

LQ = ETX-LQ * a + Bandwith-LQ *  (1-a)

> > Or we only use bandwith as a tie-breaker if the ETX value is smaller than
> > 1.1
> > (or something like this).
>
> way better i think, but of course this shoud be smoothed
> somthing like this
> (((ETX-1)*10)^x)/bandwidth
> x>2
Seems to be a little bit complicated for integer arithmetics.

> in fact we have no 10gbit at the moment in vienna* it was jsut a samnple
Ah okay... ^^

> but we had packetloss on fibre links, and strange packetloss due to
> incompatible switches/gbit interfaces, an packetloss due to bad
> media-converters, and i have my own stories about packetloss due to bad
> copper wires
> my point is only you can not trust ethernet,
> and if ethernet has the speed to get really low costs (an we want it to
> have low costs!!!) we have to make sure there is no packetloss, and if we
> detect one, raise the cost to values similar too bad wireless links
> cause we have no layer 2 error correction on ethernet,..
> in fact a link with ETX of 20 has same amount of unicast packetloss than a
> ethernet link with ETX of 1.1
> or to repeat it once again, i insist (*g) on layer 2 retry count to be used
> in the metric!!
> (as usually we route 99,x% unicast traffic)
> formula is simple
> uncicast_lq = 1-(1-broadcast_lq)^retry_count
> #1
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 I think we have lot's of time to experiment on linklayer aware metrics.

> if local and neighbour values are both better multiplicated or averaged,
> i`m unsure at the moment,..
> if we have a default retry_count of 1 on all interfaces not detectable as
> wireless, everything is fine
> on wireless i would prefer getting the real retry count from driver, as i
> know differtent values on different hardware/plattforms for this (i know
> vlaues of 4 and 7)
This would be included in the "bandwith" value we can get from the rate 
control algorithm. Because it includes retransmissions.

Modern drivers do NOT repeat a packet x times with the same speed, so we 
cannot just take the retry count.

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

> btw. 5ghz ptp bridges should usually also get retry_value of 1, as they
> usually have layer 2 corrections also on broadcasts!!

> and depending on the lnik cost of the links the packet came from (and go
> to) a minor update coming from a high cost link, or go over high cos tlink,
> is droppable, while it is not while there are low costs neighbours to
> inform about
Hmm... I think we have to draw some graphs on a paper to see if this idea 
really works.

> one implementation option would be to interprete ttl (below 128) as
> costtolive, and every node degrades it by the cost of the link it came over
> it, or a minimum value of 1
??

> maybe a translation function between link_cost and "ttl_cost" is needed of
> course
> this aproach may be somewhat compatible to existing fisheys, as packet with
> ttl 8 or 16 would still be somewhat meaningful, while ttl 255 would still
> travel more than 128 hops,..
> but still interoperability would be very limited, and is not very
> desireable to mix this interpretations of ttl,.. *g
yes.

Henning

*************************************************
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/4e649e29/attachment.sig>