Subject: [manet] Re: Manet flooding / broadcasting....

From: [email-masked]
Date: Thu, 14 Mar 2002 19:28:04 -0800

Philippe,

It is interesting to consider the discussion I had with
you in January regarding HELLOs (see below), in light of 
your new parameter REFRESH_INTERVAL.  For example, you said
"you only need to refresh al neighbors within a certain
period".  At that time, the refresh period was HELLO_INTERVAL,
since you did not yet introduce REFRESH_INTERVAL.
I was wondering why you said "a certain period" instead
of HELLO_INTERVAL, and now I know why.

This was the main point on which I never agreed with Laurent,
and I gave up arguing with him because he avoided my main
point that in OLSR (version 05) every neighbor must be reported 
in a HELLO every HELLO_INTERVAL. 

Instead of agreeing with me that something needed to be changed,
you pretended that no change was needed, and then later 
introduced the new parameter REFRESH_INTERVAL, which would have
addressed my concern.

Adding this new parameter allows OLSR to perform neighbor sensing 
similar to TBRPF, but it also adds complexity to OLSR.
In my opinion, TBRPF is designed better than OLSR in many ways,
and you are having to patch OLSR (thus making it more complex)
in order to compete with TBRPF.  Maybe next you will find a way
to make (1-hop) neighbor discovery modular, or introduce 
differential TC messages.

Richard

> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Tuesday, January 29, 2002 8:58 PM
> > Subject: Re: Manet flooding / broadcasting....
> >
> >
> > >
> > > Since HELLOs are differential in TBRPF, this can be done with a
> > > relatively small increase in overhead.  However, in OSPF and OLSR,
> > > since each HELLO contains all neighbor IDs, this would increase
> > > overhead a lot if each node has a large number of neighbors.
> > >
> > Richard, again, OLSR HELLOs can be partial, you only need to refresh all
> > neighbors within a certain period, and you can increase the hello rate for
> > fast moving node. I think Laurent mentioned this to you before.
> 
> Philippe,
> 
> Yes, I know that HELLOs can be partial and that each neighbor must be 
> included in at least one HELLO every HELLO interval, but unless there 
> are too many neighbor IDs to fit into one packet, normally OLSR uses one 
> full HELLO per HELLO interval.  (Just check the source code.)
> 
> But this does not affect my argument.  What I am saying is that OLSR 
> must include each neighbor in a HELLO every HELLO_INTERVAL, whereas 
> TBRPF includes each neighbor only in periodic topology updates, which are 
> less frequent (e.g., 10 times less frequent if the HELLO_INTERVAL is 0.5 s 
> and the update period is 5 s).
> 
> It is the HELLO_INTERVAL that determines how quickly a failed link is 
> detected, e.g., if no HELLO is received within 3 * HELLO_INTERVAL, then 
> the neighbor is declared to be lost.
> 
> I also know that OLSR can use differential HELLOs,
> since it has recently added the LOST_LINK status (which TBRPF has
> had since version 01).  *But this does not change the requirement that 
> in OLSR each neighbor ID must be included in at least one HELLO every 
> HELLO_INTERVAL.*  You can increase HELLO_INTERVAL, but then it
> would take longer to detect a lost neighbor.  OLSR could be *modified* 
> so that each neighbor ID is reported less frequently than HELLO_INTERVAL
> (as in TBRPF), but I am not sure how this would affect MPR computation.
> 
> However don't forget that even the overhead of an empty HELLO can be non 
> > negligible.  In IEEE 802.11 the MAC-PHY overhead is around 192 usec (with 
> > option to 92 usec) which at 11 Mbps corresponds to approximately 60 IPv4 
> > addresses.
> 
> Yes, this is a good point.  With the 92 usec option, this becomes about 30 
> IPv4 addresses (or router IDs).  So if a node has 30 neighbors, then a full 
> HELLO is about twice as big as an empty HELLO.  I think that's significant.
> 
> There are lots of differences between TBRPF and OLSR that can affect
> performance, and we have already discussed many of these.
> But it is difficult to predict how these differences affect performance.
> That's what simulations are for.
> 
> Regards,
> Richard
> 

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: [email-masked]
Date: Thu, 14 Mar 2002 19:28:04 -0800

Philippe,

Richard

---

From: Laurent Viennot <[email-masked]>
Date: Fri, 15 Mar 2002 11:09:03 +0100

Richard,

I do not understand why you think I have avoided your arguments. I
have just tried to promote link hysteresis advanced functioning
because it allows to detect neighbor changes quicker than 2-hop
neighbor changes. Adding REFRESH_INTERVAL is just a matter of allowing
this with basic neighbor sensing functioning.

It seems you misunderstand the introduction of REFRESH_PERIOD. The
general idea behind OLSR is to allow a certain tunability. We want to
leave enough freedom to implementors so that they can optimize their
code for their specific needs. For example, depending on the link
layer performances you may implement the protocol in different ways.

laurent

---

From: Laurent Viennot <[email-masked]>
Date: Fri, 15 Mar 2002 11:09:03 +0100

Richard,

laurent

---

From: [email-masked]
Date: Sun, 17 Mar 2002 07:00:49 -0800

Laurent,

> this with basic neighbor sensing functioning.

OK, I will be specific.
In your message dated 1/31/02 you said "Your point is doing 1 and 3 at 
a higher rate than 4", where you gave the following list:
 - 1 - detecting new neighbors
 - 2 - checking bi-directionality of links
 - 3 - detecting link breakage
 - 4 - advertising list of neighbors

No, that was not my point.  My point was more specific, that in 
OLSR (version 05) each neighbor had to be reported in a HELLO at least 
once per HELLO_INTERVAL.  (HELLO_INTERVAL has special meaning because 
making it larger can increase the time required to detect a LOST 
neighbor if link-layer notification is not used, with or without 
hysteresis.)  At that time, you and Philippe did not agree that any 
change to OLSR was needed.  Now, in OLSR version 06, each neighbor is 
no longer required to be reported every HELLO_INTERVAL, but every 
REFRESH_INTERVAL, a new parameter. This directly addresses my main 
point.  I am simply stating facts.  

> layer performances you may implement the protocol in different ways.

I understand your new parameter perfectly.  Another posssible 
reason for allowing tunability is because you are not sure what
is the best value for the new parameter and need to conduct
simulations.  In TBRPF, we have already determined that each neighbor
should be reported once per PER_UPDATE_INTERVAL, so we do not
need another parameter, thus simplifying the protocol.

Richard

---

From: [email-masked]
Date: Sun, 17 Mar 2002 07:00:49 -0800

Laurent,

OK, I will be specific.

Richard