[Olsr-users] Sticky gateway

[Henning Rogge]

Am Wednesday 21 January 2009 21:33:57 schrieb Juliusz Chroboczek:
> Phew, a lot of reactions here.
>
> Henning:
> > Yes, theoretically this can happen if the "sticky" threshhold is too
> > large. That's the reason why we suggest a default of 0.3, which is much
> > lower than the cost of a single hop.
>
> By reducing the threshold, you reduce the likelihood of the loop happening.
> You don't reduce the time for which it persists once established, which
> remains unbounded.
Yes and no... (see below)

> Sven-Ola:
> > b) the feature minimizes _gateway switching_(*)
>
> I'm not arguing with the advantages of the feature, which I fully
> understand (as a matter of fact, I do have hysteresis in Babel).  I'm
> saying that *in a link-state framework*, it has some very significant
> issues, and hence should not be recommended unless people fully understand
> its flaws.
>
> There's no reason, by the way, why OLSR shouldn't be extended to become
> a hybrid protocol, which uses link state for internal routes and
> distance-vector for external ones.  See OSPF.
Theoretically the HNA table is a "distance vector" approach. Instead of 
communicating with the external networks themself a node says "hi, I also know 
this network".

> Aaron:
> > First of all, I want to ask you to elaborate a bit on your claim.
> > Can you give an example?
>
> Yes, I can.  But do I really need to construct an example whenever
> I express a doubt about any of the features you're introducing?  I'd expect
> the duty of proof to be on the proponent's side.
>
> Consider the following topology:
>
>               3     3     1     2     2
>    0.0.0.0/0 --- A --- B --- C --- D --- 0.0.0.0/0
>
> Both B and C go through D for reaching the Internet.  Suppose now that it
> stops raining around A, and the link costs change:
>
>               1     1     1     2     2
>    0.0.0.0/0 --- A --- B --- C --- D --- 0.0.0.0/0
>
> C, which is configured without a sticky gateway, switches to going through
> A.  However B, which is using the sticky gateway feature, sticks to going
> through D.  You have a routing loop between B and C.
>
> A few points that I make without proof:
>
>   - the routing loop will never be cleared -- it will remain until the link
>     costs change again;
>   - in the example above, I assumed that B had a sticky gateway factor of
>     3; however, by tweaking the values above, you can build a routing loop
>     whatever B's stickyness factor as long as it's > 0;
>   - in the example above, I assumed that the configuration of your nodes
>     was not uniform (B is sticky, C is not); it is possible to construct an
>     example where all nodes are configured the same.
>
> Sorry for the lack of proof for the points above, but it's been a hard day.
Your example is right in theory, but it's wrong in practice.

Our link quality values on a link are never total stable because of the ETX 
metric we use. Most times they go up and down by 0.1 or more. This means the 
ETX values of a path are never stable too, so a sticky feature with a small 
threshhold will not result in a stable routing loop.

But we are talking about both problems (the possibility or routing loops to 
the HNA 0 gateway AND the instable routing metrics) and I hope we will get 
better solutions for this problems in the next 12 months (much to do, not 
enough time to do it ;) ).

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: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. 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-users/attachments/20090122/7de629d7/attachment.sig>