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

[Markus Kittenberger]

On Tue, Feb 10, 2009 at 1:04 PM, Markus Kittenberger <
(spam-protected)> wrote:

> > Yes, I agree this is a good idea. But to trigger the issue I'm discussing
> > you don't need fluctuating links. Just two alternativ high cost links
>
> > that are both changing at low relativ rate in the same direction.
>
> hmm changes at a low rate, should not be announced, until they get relevant
> i think,..
> so we need less TCs
>
> and are u really sure that a change in a high cost link, will make
> troubles? if there is no fisheye, and no packetloss on the low-cost links,
> and no bugs?
>
> sample
>
> A-B cost 1000
> A-C cost 998
> B-C cost 1
>
> i think you are frightened, that if A-C changes to 1002 (a very small
> change compared to costs of 100 but a
>
i meant 1000

> huge one compared to cost of 1)
>
> and due to packetloss only C gets informed about,..
>
> if now C want to send somethin to A it will send to B csot of 1001 (1+1000)
> but B will send it back to C as B thinks this means costs of 999 (1+998)
>
> but: if there`s no fishey and no packetloss, C would have told B of the
> cost-change between A-C, and everything is fine
>
> of course above assumptions about no fisheye (causing packetloss at
> arbitray positions) and no packetloss on low-cost links MUST hold true, to
> have only very short lived loops,
>
and of course there has to be something done to make them extremely short
lived,..
that means forwarding speed of topology, and spf intervals!! have to be
lowered (currently 10 seconds in fff)
(imho (to repeat maysel also *g) we need a incremental spf-algo)
because such minor cost changes between 998 and 1001 as in aobe sample, well
happen all the time, and may cause a route flap
while currently now with ETX values mostly between 1 and 5 very seldomly
cost_changes occure which are big enough to cause routing to change,..
but with large metrics, this may happen regulary
of couse as already proposed in this discussion, only significant (e.g. 10%)
changes to costs shoudl be announced, to lower number of tcs in the network
cause only with not-so-much tcs an incremental spf will work efficient, and
we have less bandwidth-consumption, and cpu for parsing packets, an we can
even sign/encrypt remaining packets, and so on,..
(@Harald)
while i think it`s possible to use wide-range metrics with olsr very well
(after several changes!!)
is still expect, if one would throw in ETT into a big mesh, with enough hops
with current olsr with typical freifunk-settings, the network would reduce
itself to proper connectivity only over fast&stable links, "hiding" users on
low speed links behind always changing loops,.. (as long as they have
multiple alternatives to reach the low-cost part of network)
in fact if you sit around and wait after you thowed into a mesh, olsr +ett
would kill the mesh approach, as people not having fast links, would have to
make sure they have only one link, as having multiple ones, will kick them
offline all the time,... and so on ....
but as we already have this discussion here, and many approaches in it to
solve this issues, i expect that when everything is done, and we "throw" the
result into a mesh, everyone would be very happy getting rid of ETX+olsr,
and no catastrophes will happen with wide-range metrics (only some usual
implementation bugs *g, but no "logical" ones)

>
>
> > Sorry, I have been (too) short: What I wanted to write was: "funkfeuer
> tends
> > to have long *default* routes compared to freifunk". I don't have any
> > actual data about freifunk networks but I would be very surprised if this
>
> > was wrong. And loops in the default route is, what people usually notice
> ...
>
> Yes but actually (see my previous mail) we have the peak at 3 hops from
> main gateway (viviroof) to a node
>
> and the return path is about 0,5 hops shorter in average, as more than
> halve of 0xff nodes reach a secondary (outgoing only) gateway (kryptaroof,
> tunnelserver) one hop earlier than they would reach viviroof,
>  so we have mostly very short routes here in vienna
> but i think with multiple uplinks a freifunk-mesh should behave even
> shorter, regarding default routes
> of course routes from one node to all others nodes in a freifunk-mesh would
> tend to be longer as in veinna, as there is no usually no centralistic
> (backbone) aproach in them,..
> so i want some useful data to compare, but it not so important, there
> should be NO LOOPs
> and then whether the route has usually about 3 hops or 5 hops is quite
> unimportant,.. *g
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090210/fa5ebbc2/attachment.html>