Subject: RE: [manet] OLSR: RFC 3626 observations.

From: "Dearlove, Chris (UK)" <[email-masked]>
Date: Tue, 04 Nov 2003 12:26:33 +0000

> No. Node C will use the address of C0 even tough it is sending on
> interface C1. So node B will use the main address of C(C0) in 
> its HELLO message.

A HELLO message sent by node C will use C0 as its main address,
C1 will be used as its IP source address.

Then (section 7.1.1 of the RFC, page 34) a link tuple will be created
at node B with L_neighbor_iface_addr = Source Address. (Not Originator
Address.)

When node B sends a HELLO message it will use L_neighbot_iface_addr
(RFC section 6.2, page 31: "L_neighbor_iface_addr is advertised")
so B will, as I said, advertise C1 not C0 in its HELLO messages.

In other words I believe the scenario I described does occur.

********************************************************************
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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Chris (UK)" <[email-masked]>
Date: Tue, 04 Nov 2003 16:42:53 +0000

Thanks for the comments. I've snipped everything where, judging
from reply, I think I've made my point (whether regarded as
significant or not).

> In fact it seems that the connectivity is maintained when the 
> MPR selector set does not
> change even if the advertized set changes; in this case ANSN 
> is optionnal. If a non MPR link breaks,
> then there is always a path with MPR links with same length that is
> available. This should be a way to
> save some ANSN changes. Do you have a case where it should not work?

No, so perhaps it's not necessary. On the other hand it can lead to
some inefficiencies where the MPR selector set changes but (when
using a non-default TC redundancy) the advertised neighbour set
does not change. In this case you don't want to send a new TC
even though the MPR selector set has changed.

Perhaps therefore you could send only if both the MPRSS and the
ANS change (i.e. only if necessary, and not when pointless).
However sending simply when the ANS has changed seems easiest,
and maintains a constant redundancy level.

> > - Section 10 point 2 (page 48) refers to main address without
> >   specifying where to get it from. The RFC defines main address
> >   in section 5.5 (page 27) and hence that definition should be
> >   used. However in the indicated point this is a 1-hop neighbour,
> >   hence the main address is also available in the associated
> >   Neighbour Tuple. Since the 1-hop link must be established
> >   before a MID message is received and the Interface Association
> >   Set is updated, not using the Neighbour Tuple will result in
> >   an unnecessary delay. Since the procedure in Section 10 is
> >   an example, it is not necessary to change the RFC to use the
> >   Neighbour Set at this point. However there are other circumstances
> >   where this additional information may be used. The protocol could
> >   be modified to add that an entry may be added to the Interface
> >   Association Set whenever a HELLO message's originator address and
> >   source address differ (the former is the main address, the latter
> >   is the interface address).
> 
> The main address is mentioned in the originator address field 
> in the header of the HELLO. One should not need
> to wait for an MID message to get it.

I agree, in fact that's my point. However my reading of the RFC suggests
this is not strictly as it specifies. Have I missed anything (other than
that, as I note, in this particular section the algorithm is only a
suggestion and the implementer is free to make the change, as in fact
I have)?

> > Fourth an observation, without a specific suggestion here
> > (although I have considered some specifics I omit here as
> > the principles are more important).
> >
> > - OLSR timing for tuple expiry etc. is now defined using the
> >   Vtime (and for a HELLO message Htime) fields of a message,
> >   i.e. timing is based on the message originator's parameter
> >   settings. In addition to the case noted above, there are
> >   two other cases where timing is not taken from the originator
> >   and where significantly different values of parameters on
> >   different nodes could interact badly.
> >
> >   - Jitter delay, based on parameter MAXJITTER. Note that it
> >     is possible, as currently defined, for a message to be
> >     delayed by more than the interval between messages.
> >     Ideally use of the message interval would be preferable
> >     to use of the hold time (Vtime) but typically these will
> >     be related.
> 
> But the interval between hellos should not be greater than the
> neighb_hold_time.

I'll switch to TCs as they are forwarded. I think it's possible
to have

Node A runs default OLSR parameters, in particular HELLO_INTERVAL
is 2, TC_INTERVAL is 5, TOP_HOLD_TIME is 15 and MAXJITTER is 0.5.
Now node B is overclocked by a factor of 10. (Yes, that's rather
extreme, although not absolutely inconceivable.) Then TC_INTERVAL
will be 0.5 and when a node B TC message is forwarded by node A
it is completely randomised. With transmission jitter (or a factor
greater than 10) node B's TC messages could actually be reordered.

Instead suppose a message were jittered by a multiple of Vtime,
then if all OLSR parameters on a node are kept in default ratio
then that multiple could be 1/30 (by default). Of course there's
no guarantee that OLSR parameters are kept in step, but that's
another matter.

This is most interesting if adding some extension to OLSR
(a message other than HELLO, TC, MID and HNA) which may be
badly treated by a fixed jitter. (If the new message has no
use for Vtime this gives it one.)

> >   - Duplicate hold time. In this case basing hold time on Vtime
> >     would also provide greater extensibility to new message
> >     types that might be significantly more or less frequent.
> >
> That is an interesting issue, one may store duplicate ID 
> longer depending on origin.
> Notice that the duplicate hold time is a compromise on the 
> speed at which a network
> delivers all the copies of one packet and the time for a node 
> to wrap around packet
> sequence number. Processing again a packet is not damageable 
> but a packet may
> bounce several times if duplicate is not detected.

I didn't comment on wrap-around (assuming that 16 bits was
fixed) but I did think about it. I was concerned with possible
fast messages (whether from a fast node or a new message type)
and how with fixed DUP_HOLD_TIME the Duplicate Table could get
over-full.