[olsr-dev] Improvements in the algorithm

[sebastian]

hiya,

not sure if this is completely on topic, but atleast related.
I'm not sure how olsr handles route switching, but  this could be a
solution if it is a problem such a described below:
 
  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?)

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)

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.