[olsr-dev] Improvements in the algorithm

[onelektra]

hi -


>   say you(node A) can reach a node(C) through 2 other nodes(B and D), but
>   link quality differs, sometimes B is better, sometimes D. at what point
>   will this inflict a route change? as soon as one gets only slight
>   better then the other? or is there a threshold? currently switching
>   routes seems like a bad idea to me(takes up cpu and network traffic?)

yes, according to Thomas there is a threshold implemented (personally I 
call it hysteresis).

> another issue I think would be the big routing tables for big
> networks(one route per host) seems atleast to take up memory and
> increase network traffic(when you tell who you can reach)

I see olsrd as a solution for a wireless ad-hoc subnet of up to 100 - 
300 nodes. I expect olsrd to handle this quite well in the not so far 
future. It works quite nice already, but with the stability issues under 
link saturation that I described in my post from yesterday.

This is what I expect olsrd to achieve. In order to build a network that 
goes beyond that one should have a look at the way the internet already 
works. To me there is no point in reinventing RIP, BGP, OSPF. If a 
community wants to have a WAN that interconnects more than a few 
hundered nodes they should have a look at the known art :-)

If one wants to develop a protocol that is able to route 16.7 million 
nodes within one subnet - carry on ;-)

cu elektra


> now, the sugestion I have would move the resource issue from network and
> memory to cpu.
> say you have some control over how the network will look ip wise.
> ofcourse it needs to be flexible as nodes can move around but most will
> not (think city wide roof network for example). now you could choose
> that atleast -initially- you give nodes in the west an ip within
> 10.2.3.0/24 and a node in south an ip in 10.2.4.0/24, for example. doing
> this with a regular olsr setup won't gain you anything except you have
> more of an idea what ip could be where. now if you have an option or a
> plugin in olsr to let it -calculate- subnets for neighbour nodes. a node
> in the east would only need one entry to find a node in the west,
> initially.. this ofcourse could become less efficient as nodes move a
> round a bit, but if the majority will stay in place it will, certainly
> for bigger networks be quite a gain. an example to show what I mean:
> 
>   node A knowsthat it can route the ips: 10.2.3.64, 10.2.3.65, 10.2.3.66
>   and 10.2.3.67 (be it through different other nodes, or one) it then
>   puts in it's broadcast that it can reach 10.2.3.64/30. 
>   at that point it's neighbour, who has no clue about any of these
>   ips(can't see them directly) then sets the route 10.2.3.64/30 to node
>   A. saving up on 3 route antries. say he does know where to find .68 to
>   .71 it could then send he can see 10.2.3.64/29. 
>   now say that .65 decides to move his antenna a bit, and this results in
>   node B seeing it, and the link is actually pretty good. node B can
>   then decide to only accept a part of node A's subnet and set
>   10.2.3.66/31 and 10.2.3.64/32 to node A, and route 10.2.3.65 localy.
>   this is ofcourse smaller gain, but this is a small example. on ther
>   hand, in this situation he can still anounce he can reach 10.2.3.64/29.
>   and the network benefit stays.
>   now say 10.2.3.65 didn't move his antenne, but got struck by lightning.
>   at this point node A -can't- reach the whole 10.2.3.64/30 subnet, but
>   it no other machine claims a route within it.. and aslong as that's
>   true, node A has no reason to change it's behavious, until A host
>   does claim it has ip's in that range, in which case node A would need
>   to announce small subnets excluding that ip.
> 
> as for the route switching issue, I guess a threshold could solve that,
> but this would work just as fine for subnets as for single ip's. come to
> think of it, it's not really related.. awell.
> 
> this all ofcourse results in more cpu power being used by the node, 
> although I've got no idea how much.
> 
> ok, I hope the idea is clear. all comments more then welcome and I hope
> it's an idea to put in olsr.
> 
> greetings
> 
> sebastian s.
> 
> 
> 
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
> 
>