[Olsr-dev] Comments regarding the talk of Thomas Clausen at metalab

[Harald Geyer]

Hi Thomas!

First of all: Thanks for the really interesting and nice talk about
olsr yesterday! I had already been somewhat familiar with the protocol,
but your talk has made the reasoning behind it much clearer. 

I understand that the idea of multi point relays is kind of the heart
of olsr, so I guess you have been a bit surprised to hear that we at
funkfeuer don't use it at all. I want to comment on this now.
(Sorry for not joining the discussion yesterday, but I had to reflect
upon this a bit to figure out examples that show the point easily.)


One reason is: We don't have that much to gain as you might expect.

In our network wie have many nodes, where ALL routes go over the
same neighbor. On such nodes it is common, that some direct neighbors
are actually best reached (in the sense of ETX) via a 3 hop route.
(For a moment not taking into account broadcast vs. unicast issues 
that make things more complex.) - I think this situation arises because
in your network channel divesity, polarization, etc are very important.
(You didn't mention these things in your talk yesterday.)

With this information you will probably understand that a typical node
in our network has many two-hop-neighbors, but the prefered way to
reach them is not a two hop route. Thus, we could select MPRs for
efficient flooding, but we would need to break the olsr requirement.
In a notwork where many nodes have several interfaces (on different
channels) we have no hope to reach all of your two-hop-neighbors in
two hops without selecting almost all of them as MPR. So, if we are
flooding anyway, why not make it the default? Actually I think our
routing information is mostly spread over the links we would like
to use (but aren't allowed to by olsr) because traffic sent over
the direct (but marginal) links is mostly lost anyway ...

I think it would be very optimistic to claim, that using minimal MPR sets
would save 50% of our olsr traffic. An optimization, that doesn't give
you a factor of 2 at least, usually isn't worth the effort.

BTW: Actually the situation is even worse, than what I wrote above,
because as of now we just don't have a sane implementation of an
olsr router. - That's something that became clear to me during your
talk yesterday (although I have been tinkering about it with others
(mostly Markus Kittenberger) since last December): In funkfeuer
terminology we have funkfeuer-nodes, devices, and interfaces, while
in olsr you only have nodes and interfaces. Typically a device is
one piece of hardware with one cpu running one olsrd - in other
words: a device is an olsr node. OTOH a funkfeuer node is one
geographic location, where several devices (olsr nodes) are located,
connected together via Ethernet, that is the olsr nodes on any one
funkfeuer nodes are neighbors - typically operating on different
wifi channels.

And now you will see the really bad thing: By the olsr MPR criteria,
now ANY olsr node on ANY such funfeuer node will ALWAYS be selected
MPR by ALL its neighbors (over air) because there is no other way
to reach the 2-hop olsr nodes connected via Ethernet in 2 hops.

Actually this is not a protocol issue but an implementation issue
which basically boils down to: There is a difference between one
router board with  3 wireless interfaces and 3 linksys connected
via Ethernet, but I think there shouldn't be as the underlying
hardware is not of the routing protocols business. Unfortunately
currently people a quite fond of metrics and mostly forget about the 
topology issues - it's easier to have a mathematical modell about
metrics then about embedded devices market issues i suscpect.


Now perhaps you say: Ok, I see this MPR technology isn't too useful
to you, because you can't get it right, but why don't you use it anyway:
It would save you at least some traffic.

So just in case you haven't lost interest in my mail yet, I'll give you
a simple example on why using minimal MPR sets might turn out a bad idea:

Node S has three neighbors (A, N) and perhaps some others too. N is
some really big node with various wireless interfaces and lots of neighbors
(we call such a thing a backbone node). N is rather far away so our link
is not very well, thus our route to N (and all it's neighbors goes over
A.

  S
 /| 
A |
 \|
  N

But whom to select as MPR? If we want to obey olsr, then N must be part
of the MPR set because it has many neighbors A can't talk to. So we
only can exclude A, but if we exclude A, then all over flooding will
go over a bad link thus rarely reaching N. 

Let me state this again: If we try to use something like a minimal
MPR set, we will most part of the time fail to get any information not
part of link sensing and local topology discovery transmitted to our
DIRECT NEIGHBOR N at all! And N is a backbone node, so this guy should
really know what's going on in the mesh.

Such situations like the above one perhaps aren't very common, but I
believe that they happen often enough so that we would lose more airtime
in routing loops then we might save on protocol overhead. Perhaps it is
possible to find some algorithm which says: Ok, we might at least drop 
this node from the MPR set and still be on the safe side.
But we haven't invented it yet and I think there are more important
issues to focus on.


Conclusion:
Conclusion? - I'm not sure there is any. I think the interoperability
properties of olsr are really nice, but I'm not clear how much we
(funkfeuer) depend on it. If I reflect on RFC 3626 with your talk
in my mind, then I think we just never got it right (talking more
about the spirit than about the letter). This might mean that we
are clueless or the rfc is difficult to implement using common hardware
or that it just doesn't fit your needs - I guess it is a combination
of a little bit of all from that.

Regarding OLSRv2 it seems (after your talk but without having read it yet)
that some ideas I had when thinking about topology issues in funkfeuer
are mentioned there. But I have no idea if it would be easier to implement
without reading it in some detail.

I hope this information is useful to you,
Harald