Lack of jitter specification

[Lotterleben]

[Jiazi]

One more note: Jitter is not mentioned in the draft, which is important because the multicast messages used. I can see RFC5148 in the reference section, but didn't find where it is used.

[Vicky]

We could say "The use of jitter in an implementation is RECOMMENDED by RFC5148" in the Message Transmission section?

[Jiazi]

We need more details than that, such as in which message jitter is required, and when it should be applied. Preferably with some suggested default values. In fact, the jitter in reactive protocol should be considered even further -- we discussed the issue in the draft https://tools.ietf.org/html/draft-yi-manet-reactive-jitter-04

[Lotterleben]

See also in Ulrich's review:

• No jitter: The WG has decided to specifiy jitter in RFC5148 and use it in OLSRv2 because it is beneficial in flooding operations. But AODVv2 doesn't specify the usage of jitter (there is only an orphaned reference to RFC5148). What is the rationale for AODVv2 to not include jitter?

[charliep51]

Hello folks,

Jitter is useful when there is a chance of correlated sources of flooding. This could happen in AODV because flooding happens by "tiers" and some of the nodes in each tier might be neighbors.

However, I do not recall any observations that this tiered effect caused problems. If we do decide to specify a jitter then (a) it should be smaller than the transmission time of a packet and (b) it should be optional.

I understand jitter to be useful when large numbers of network nodes are rebooting at the same time. OLSR probably needs it because of the periodic nature of their advertisements. If AODV had some similar periodic activity I would be favorable to specifying jitter for those signals, but we do not have that.

Regards, Charlie P.

On 5/17/2016 3:04 PM, Lotte Steenbrink wrote:

See also in Ulrich's review:

  * No jitter: The WG has decided to specifiy jitter in RFC5148
    and use it in OLSRv2 because it is beneficial in flooding
    operations. But AODVv2 doesn't specify the usage of jitter
    (there is only an orphaned reference to RFC5148). What is the
    rationale for AODVv2 to not include jitter?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Lotterleben/AODVv2-Draft/issues/10#issuecomment-219868273

[Lotterleben]

I do not recall any reports of observations, so I don't tink we can use the absence of such a report as an argument currently...

That being said, your summary makes a lot of sense. I'd assume the only place where we might run into problems is during the phase where RREQs are flooded throughout the network... Especially in big, traffic-heavy networks (which are our nemesis anyway), this could be a problem, couldn't it? Adding optional jitter to RREQ transmissions sounds reasonable to me.

[charliep51]

On 5/18/2016 6:19 AM, Lotte Steenbrink wrote:

I do not recall any reports of observations, so I don't tink we can use the absence of such a report as an argument currently...

I was talking about AODV, for which the RREQ protocol dynamics are identical. You can find dozens if not hundreds of papers about this, and I have reviewed quite many of them. I still get review requests.
Would you like for me to forward some of them to you?

That being said, your summary makes a lot of sense. I'd assume the only place where we might run into problems is during the phase where RREQs are flooded throughout the network... Especially in big, traffic-heavy networks (which are our nemesis anyway), this could be a problem, couldn't it? Adding optional jitter to RREQ transmissions sounds reasonable to me.

I view this as reasonable but low priority. If someone wants to do it, then terrific.

Traffic-heavy networks are everyone's nemesis, and yet some peoples' bread and butter. I believe that AODVv2 can handle the extra traffic better than other ad-hoc routing protocols, if the proportion of transient communication pathways in the network is less than N(N-1)/2.

Regards, Charlie P.

[Lotterleben]

Note: add, but make optional