Hello,
I know this mail comes a little bit early (metrics have not been merged into
OLSRv2 draft), but I would like to like to argue for more than "include
generic metric support in OLSRv2".
Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a
conference about military communications. There were a couple of
presentations
which used OLSR as a mesh net protocol and they can be summarized as: "OLSR
does not work well". When I tried to get some more facts about this I quickly
recognized that all of them used hopcount metrics "because it's the default
described in the RFC".
I think this was a mistake in the OLSRv1 RFC, it described a
protocol that did
not work very well in the real world because of hopcount metrics. No
amount of
great research for new metric or improved features have changed this later,
because most people USING OLSR for their research will use the stuff
described
in the default RFC. We should not do the same mistake in the OLSRv2 RFC.
My suggestion is:
include a simple version of ETX as an example metric into the OLSRv2 RFC.
Why ETX ? Why not ETT/SNR/MIC/.... ?
ETX is not the best metric out there, it's a very basic one. But it's VERY
easy to describe and implement, it's independant from the layer 1/2
below OLSR
and it allows to build much better real world networks than hopcount. I know
no other metric that can provide these three advantages.
We should add a few sentences into the chapter that this will be just the
"lowest common metric" which should work with all OLSRv2 agents and
that there
are much better and more specialized metrics described in other documents and
research papers. But if we do not put a real metric into the RFC we will have
people saying "OLSRv2 does not work well" in years, just because
they do their
comparision based on the RFC implementation (hopcount).
If there is a consensus on this I can easily write description of a simple
Hello-Message based ETX implementation with a single tuning parameter for the
draft.
What do you think ?
Henning Rogge