Subject: RE: [Manet-dt] OLSRv2 NHDP comments

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 18 Apr 2006 09:48:58 +0100

> 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.

> 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.

> 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.

> 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.

> 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.

> I'm going to start up another thread on security.

We ran out of time putting this in, that's not a finished section.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 18 Apr 2006 14:45:44 +0200

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

> I see the point, but HELLO messages have a long pedigree in MANET.

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

> proposed, but probably never will be.

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

NHDP, perhaps...

> 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

> getting rid of them has been a major step in making this separation

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).

>> Does the hoodBB require a link local multicast other than all MANET

Confirm ;)

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