Subject: Some issues regarding TBRPF and OLSR

From: [email-masked]
Date: Thu, 13 Dec 2001 05:38:32 -0800

Since Thomas is emphasizing that OLSR is more "stable" than
TBRPF (but avoids the issue of performance), I would like
to say a few things in defense of TBRPF.  By "stable" he
means that OLSR has not changed much recently.

First, let's not forget that OLSR was originally a full topology
protocol and then changed to partial topology, between version 00
and version 01 (I believe).  TBRPF did the same between version 00
and version 01.  (This occurred more recently since TBRPF was
introduced to the WG about a year later than OLSR.)

The recent changes made to TBRPF were mostly a result of incorporating
suggestions from the WG, including those by Thomas himself.
For example, at a dinner meeting in Minneapolis, Thomas suggested to 
Fred and me that TBRPF was too complex, and that the partial topology 
and full topology modes were not interoperable.  As a result,
we have simplified TBRPF a lot, and have made the two modes
interoperable.  We appreciate Thomas' suggestions, but now he is 
criticizing TBRPF for having changed!

It is interesting that at the same meeting, Thomas also suggested
that our neighbor discovery protocol was too complex because it
had four neighbor states (including the LOST state).  
Ironically, TBRPF now has only three neighbor states, while
OLSR has four neighbor states, since it has added the LOST state.

A more recent suggestion that Thomas and Philippe have made is that 
the TBRPF draft is hard to read.  But TBRPF itself has been greatly 
simplified since the original draft, and the concept of TBRPF is easily 
understood by reading the overview.  If they or anyone else have specific 
suggestions on improving the readability of the draft, we would be
happy to incorporate them. 

We also welcome INRIA to work with us on improving TBRPF and
possibly merging ideas from OLSR if appropriate (i.e., if it
improves performance).  It does not make sense to blindly
merge parts of OLSR with parts of TBRPF without having some
idea of how this affects performance (as someone else said at 
the WG meeting regarding DSR and AODV).  That is why simulation 
experiments are needed.  We are also willing to use a new name 
(other than TBRPF or OLSR) for the merged protocol.

Richard

P.S. There are several other issues I was planning to discuss
in separate messages, but to reduce the number of messages
I will include one of them here. Comments would be appreciated.

Modularity: This issue is very important, and I am really concerned
about the fact that OLSR neighbor sensing includes things other
than neighbor sensing: i.e., finding 2-hop neighbors and selecting MPRs.
(As you know, TBRPF neighbor sensing does ONLY neighbor sensing, i.e.,
detects new neighbors and the loss of old neighbors.)
If the neighbor sensing module does ONLY neighbor sensing, then
it is easy replace the default neighbor sensing module with another one.
For example, if the link-layer already provides neighbor sensing,
then the TBRPF neighbor sensing module can be omitted, thus
saving overhead. If OLSR neighbor sensing did ONLY neighbor sensing,
then it would be easy to use TBRPF neighbor sensing with OLSR.
This seems to be a clear problem.  Does anyone agree?

---

From: [email-masked]
Date: Sat, 15 Dec 2001 16:00:15 +0100 (CET)

See comments below....

> introduced to the WG about a year later than OLSR.)

Richard, this is just not true. The first version of the olsr-draft was
not full-topology. It contained and used multipoint relays in the same way as
the current drafts. That is to say that OLSR from the beginning has been
using partial topology.

The Hiperlan protocol, from which OLSR inherits many features, also uses
MPRs and is thus a partial topology protocol.

> criticizing TBRPF for having changed!

<SNIP>

Richard, please note that I was not "criticizing" that TBRPF was evolving.
At the IETF, I was merely stating the status for the proactive work
over the past year. This included the fact that 4 radically different
versions of TBRPF had emerged. Is this not correct?

-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: [email-masked]
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------