Subject: [manet] Triggered message and jitter

From: Ulrich Herberg <[email-masked]>
Date: Mon, 13 Jul 2009 13:53:04 +0200

Dear authors of NHDP/OLSRv2/RFC5148,

I have a question about jitter in NHDP/OLSRV2 when triggering a message --
which I think is not clearly explained in the NHDP/OLSRv2 drafts or in
RFC5148. RFC5148 says:

"when a (externally triggered) message is transmitted, the next message is
allowed after a time (MESSAGE_MIN_INTERVAL - jitter)"

I understand that, however, there are two cases which are not clear to me:
1) The last message has been sent longer ago than MESSAGE_MIN_INTERVAL
    In that case, how do I jitter? I would suppose to use a *positive*
jitter from 0 to MAX_JITTER in that case instead of the negative jitter in
the cited sentence from RFC5148.
2) If a message is triggered just very shortly before (last_message_sent +
MESSAGE_MIN_INTERVAL). In that case, if I simply subtract jitter from
MESSAGE_MIN_INTERVAL, I might have a negative value. Thomas told me to
choose a jitter value between the current time and MESSAGE_MIN_INTERVAL in
that case. But that leads to
   a) a non-uniform distribution between 0 and MAX_JITTER
   b) a possibly very small value of jitter; collisions might occur.

Can you explain me how to handle these cases?

Thanks
Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 13 Jul 2009 17:17:59 +0100

> I have a question about jitter in NHDP/OLSRV2 when triggering a
message
> -- which I think is not clearly explained in the NHDP/OLSRv2 drafts or
in RFC5148.
> RFC5148 says:

> "when a (externally triggered) message is transmitted, the next
message is allowed
> after a time (MESSAGE_MIN_INTERVAL - jitter)"
 
OK, that's about how long since the last message.

> In that case, how do I jitter? I would suppose to use a *positive*
jitter
> from 0 to MAX_JITTER in that case instead of the negative jitter in
the
> cited sentence from RFC5148.

You always have to use a positive jitter - if triggered you can't go
back in
time! There are two rules:
(i)  Wait between 0 and MAXJITTER. This of course depends on the reason
     this has happened. If this is something local (like changing
addresses
     for internal reasons) then there's no need to wait at all. If it's
due
     to something external (such as a received message that's likely to
     induce change is several nodes that receive the message) then
jitter.
(ii) The minimum interval. Note that this is jittered because otherwise
in
     a busy network things will become de facto periodic, which is a bad
thing.
     The reasons for the negative jitter on intervals are discussed in
RFC 5148.
     (Strictly the reasons apply to the maximum interval, but they need
to
     allow for non-responsive systems where the two are equal, hence
applying
     them to the minimum interval avoids special cases.)

You need to satisfy both. Typically one or the other will be the
limiting
factor, but you have a case where both have an effect:

> 2) If a message is triggered just very shortly before
(last_message_sent
> + MESSAGE_MIN_INTERVAL). In that case, if I simply subtract jitter
from
> choose a jitter value between the current time and
MESSAGE_MIN_INTERVAL
> in that case. But that leads to 

I would say, obey both (i) and (ii). But note that RFC 5148 does not
specify an exact algorithm. That's by intent, as there are enough
complicating factors. (One such being packetisation, which allows
scope for the clever implementor to get better performance - and we
didn't want to constrain him, as he might have a better idea than
us) And it's not essential for interworking (if it were we would
specify an algorithm).

> Can you explain me how to handle these cases?

I know I've implemented more than one timing algorithm for OLSRv1/v2.
(Note that we invented the minimum interval and jittering it here as
a proprietary extension to OLSRv1 - see the first OLSR Interop.) So
there is more than one way to do things. But right now I don't recall
exactly how I handle this case, except to note carefully.

Is this critical? Well, you point out issues if you do one thing.
Are those show-stoppers? Probably not. Are they undesirable? Probably.
(Note that handling of forwarding of messages in multi-message packets
takes care to indicate a single jitter value for all messages to
avoid exactly those issues.)

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