Re: [Manet-dt] OLSRv2 NHDP comments

[Thomas Clausen <[e-mail]>]

I'm officially on vacation today, but I'll chime in still...

On 18 Apr 2006, at 10:48, Dearlove, Christopher (UK) wrote:

>
>> I would like to change the name of HELLO messages to something else.
>>
>> How about neighborhood message (hood message) or neighborhood
>> advertisement (NHA). Not nearly as catchy but a bit more descriptive.
>
> I see the point, but HELLO messages have a long pedigree in MANET.
>

Agree with Chris here. I have a strong preference for "HELLO".

>> As mentioned before, ND is an overloaded term. Perhaps MANET
>> neighborhood building block (hoodBB) would be a good term. What do you
>> think?
>
> I don't like hoodbb, I prefer Brian's nhdp, and also to options
> such as ndhpbb or ndhbb. I think the ideal name hasn't been
> proposed, but probably never will be.
>

Agree. "hoodbb" sounds like something you'd expect in a bad Hollywood 
movie about LA suburbs ;)

NHDP, perhaps...

>> MIN_INTERVAL. I think this should be a SHOULD. If a node knows
>> something is really important I think it should be allowed to transmit
>> faster than MIN_INTERVAL, plus it isn't required for interoperability.
>
> I would tend to agree with that. I also think MIN_INTERVAL isn't quite
> the ideal name when put into a wider context (e.g. OLSRv2) as there
> may then be other minimum intervals.
>

I feel that having an upper limit on the control traffic, which a given 
protocol is able to generate, is very useful. Without restricting the 
interval between subsequent transmissions of HELLO messages, I could 
easily envision an implementation which would NOT be doing the right 
thing and end up eating all available bandwidth in a region.

The name may need to be qualified, (HELLO_MIN_INTERVAL ?) to 
distinguish it from other such intervals, however I strongly believe 
that such MUST be imposed as a MUST.

Notice that the HELLO_INTERVAL is the "normal" interval between two 
subsequent HELLOs. If something exceptional happens, then a node MAY 
send additional HELLOs. However to prevent a node from simply eating up 
all bandwidth, a distance of  MIN_INTERVAL MUST be ensured between two 
HELLOs.

Notice that MIN_INTERVAL << HELLO_INTERVAL


>> Should we limit hoodBB to 2-hop neighborhoods? Is there something
>> fundamentally different if we allow more than 2-hop neighborhood
>> discovery?
>
> I think if anyone wants 3+ hop neighbourhoods that they could/should
> create an extension, we all have quite enough on our plates for
> something we don't need. I also think there may be some definite
> issues with >2 hops and multiple interfaces. We (some before I was
> on board) have gone through evolution steps (from OLSRv1) from
> MID messages to MA messages to using TC messages to only needing
> HELLO messages. I have a feeling (not analysed) that 3 hop
> neighbourhoods would open that whole can of worms again - and
> getting rid of them has been a major step in making this separation
> work.
>

Other than agreeing with Chris that this is unchartered territory 
entirely, I also have not seen any "reasonable" algorithms where 3+ hop 
neighborhoods have been used. By "reasonable", I mean "where the gains 
of using 3+ hop neighborhoods outweighs the costs of acquiring 3+ hop 
neighborhood information" (the cost, then, including the complexity of 
doing multi-interface support).


>> Is there any motivation behind the parameters (Section 7 Proposed
>> Values)? What happens if they aren't all set to the same value? Can
>> you elaborate a little on the various parameters interactions with
>> each other or dependence on one another too?
>
> Certainly this ought to be said somewhere. We (OLSRv2 DT) still have
> an aspiration to some sort of rationale document, but pressure of
> other stuff has pushed it down the stack. But in short, apart from C,
> different nodes can have different values of the parameters. The
> hold times must be significantly longer than the interval times,
> roughly speaking 3x (the suggested default) allows you to lose 2
> consecutive messages (though don't make a habit of it).
>
>> Does the hoodBB require a link local multicast other than all MANET
> routers?
>
> I don't think so.

Confirm ;)


--
Thomas Heide Clausen
http://www.lix.polytechnique.fr/hipercom


_______________________________________________
Manet-dt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt