Jitter Considerations in Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-jitter-04

[Ballot discuss]
There has been much discussion w/ the authors, WG chairs and ADs this past week. For my part, I have been asking the authors to explain how they know that this scheme "works" and scales. The particulars for OLSR are not laid out nor is there a mathematical analysis that in larger networks reasonable jittering would occur.  In addition, I highly recommend that this draft stay INFORMATIONAL as making it BCP would preclude other design patterns for jittering control traffic in MANET protocols.

"There is no doubt that jittering should be defined for MANET protocols. This draft should be informational as "Any protocol using jitter as outlined here must specify its precise usage insofar as is necessary for interoperability." in section 4 covers where things will be standardized. The draft should be BCP if any other form of jittering is not considered viable by the MANET WG. I sincerely hope that this style of jittering is NOT mandated."

What is moderately interesting is that most other routing protocols jittering timers to avoid issues at the sender. The goal here is to attempt to avoid collisions at the receiver by coming up w/ a scheme that MAY create randomization on all nodes. It is unclear if it actually works. NOTE: jittering timers is darn simple and the scheme mentioned in the draft requires quite a bit more state maintenance that may end up being per message type per peer. Thus, there is an implicit tradeoff of queueing on the receiver vs CPU/memory on the transmitter. It is unclear why the scheme being presented wouldn't slow down convergence overall and there is no comparison between this scheme and a resend technique (used in other protocols). The particulars here are that this protocol is running over a radio network and analysis of collisions are not referenced to demonstrate the magnitude of the problem that they are trying to solve with this design pattern vs a traditional "jitter the timers on the sender" technique used universally in other routing protocols.


All of the above has been discussed w/ the authors, WG chairs, ADs, Lars, etc and they agreed to either have a -04 or take on an ed note. When a decision is made and new text is available, I'll clear. This is a placeholder to make the decision.

[Ballot comment]
I originally had a DISCUSS on whether this document should go for BCP or Experimental rather than Informational. Off-list discussion with the chairs and ADs has made it clear that this technique is too cooked for Experimental but the guidelines aren't clear enough for BCP. Hence, the desire is to stay with Informational.

I'm OK with this resolution, but would in this case strongly suggest to avoid the use of RFC2119 language, which makes it sound like this document makes standards-level recommendations without actually being able to do so.


Section 4., paragraph 1:
>    This document does not specify a protocol, nor does it mandate
>    specific node or protocol behavior.

  DISCUSS: Then its use of RFC2119 terms is confusing. Section 5 is full
  of recommendations for node and protocol behavior - example: "In order
  to prevent nodes in a MANET from simultaneous transmission, (...) a
  randomization of the transmission time of packets by nodes, known as
  jitter, SHOULD be employed." How is this not a recommendation?


Section 5.4., paragraph 2:
>    o  While jitter may resolve the problem of simultaneous
>      transmissions, the timing changes (in particular the delays) it
>      introduces will otherwise typically have a negative impact on a
>      well-designed protocol.  Thus MAXJITTER SHOULD always be
>      minimized, subject to acceptably achieving its intent.

  This doesn't give any concrete guidance on how to pick MAXJITTER. If I
  were to design a protocol, how would I know which values of MAXJITTER
  to use for my messages? (The guidelines for periodic messages below a
  bit more concrete.)


Section 5.4., paragraph 4:
>      *  it MUST NOT be greater than MESSAGE_INTERVAL/2;
>      *  it SHOULD be significantly less than MESSAGE_INTERVAL; a value
>          not greater than MESSAGE_INTERVAL/4 is RECOMMENDED.

  There is some redundancy between these bullets.


Section 5.4., paragraph 5:
>    o  If MESSAGE_MIN_INTERVAL > 0, then:

  How can MESSAGE_MIN_INTERVAL not be greater than zero?

>      *  MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL;
>      *  MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2.

  Also, there is some redundancy between these bullets and the ones
  above.


Section 5.4., paragraph 6:
>    o  As well as the decision as to whether to use jitter being
>      dependent on the medium access control and lower layers, the
>      selection of the MAXJITTER parameter SHOULD be appropriate to
>      those mechanisms.

  What is "appropriate to those mechanisms"; can you give guidelines or
  maybe just some examples?


Section 5.4., paragraph 8:
>    o  The choice of MAXJITTER used when forwarding messages MAY also
>      take into account the expected number of times that the message
>      may be sequentially forwarded, up to the network diameter in hops.

  How would one take this into account? Would I lengthen or shorten
  MAXJITTER? Guidelines?

[Ballot comment]
Section 5.4., paragraph 2:
>    o  While jitter may resolve the problem of simultaneous
>      transmissions, the timing changes (in particular the delays) it
>      introduces will otherwise typically have a negative impact on a
>      well-designed protocol.  Thus MAXJITTER SHOULD always be
>      minimized, subject to acceptably achieving its intent.

  This doesn't give any concrete guidance on how to pick MAXJITTER. If I
  were to design a protocol, how would I know which values of MAXJITTER
  to use for my messages? (The guidelines for periodic messages below a
  bit more concrete.)


Section 5.4., paragraph 4:
>      *  it MUST NOT be greater than MESSAGE_INTERVAL/2;
>      *  it SHOULD be significantly less than MESSAGE_INTERVAL; a value
>          not greater than MESSAGE_INTERVAL/4 is RECOMMENDED.

  There is some redundancy between these bullets.


Section 5.4., paragraph 5:
>    o  If MESSAGE_MIN_INTERVAL > 0, then:

  How can MESSAGE_MIN_INTERVAL not be greater than zero?

>      *  MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL;
>      *  MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2.

  Also, there is some redundancy between these bullets and the ones
  above.


Section 5.4., paragraph 6:
>    o  As well as the decision as to whether to use jitter being
>      dependent on the medium access control and lower layers, the
>      selection of the MAXJITTER parameter SHOULD be appropriate to
>      those mechanisms.

  What is "appropriate to those mechanisms"; can you give guidelines or
  maybe just some examples?


Section 5.4., paragraph 8:
>    o  The choice of MAXJITTER used when forwarding messages MAY also
>      take into account the expected number of times that the message
>      may be sequentially forwarded, up to the network diameter in hops.

  How would one take this into account? Would I lengthen or shorten
  MAXJITTER? Guidelines?

[Ballot discuss]
Section 4., paragraph 1:
>    This document does not specify a protocol, nor does it mandate
>    specific node or protocol behavior.

  DISCUSS: Then its use of RFC2119 terms is confusing. Section 5 is full
  of recommendations for node and protocol behavior - example: "In order
  to prevent nodes in a MANET from simultaneous transmission, (...) a
  randomization of the transmission time of packets by nodes, known as
  jitter, SHOULD be employed." How is this not a recommendation?

  Along these same lines, why isn't this protocol going for BCP or
  Experimental? BCP seems appropriate if jittering is widely viewed as
  the right thing to do for MANET protocols. If it isn't (yet) viewed as
  the right thing to do, Experimental makes sense, because that let's
  you recommend what nodes and protocols that participate in the
  experiment SHOULD or SHOULD NOT do.

PROTO Write-up

1. Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready to
forward to the IESG for publication?

YES.

2. Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

YES the ID has been reviewed. NO there is no concern about the reviews.

3. Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

NO.

4. Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document, or
have concerns whether there really is a need for it. In any event, if
your issues have been discussed in the WG and the WG has indicated it
that it still wishes to advance the document, detail those concerns in
the write-up.

NO.

5. How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

STRONG - Several other WG documents contain references to this ID.

6. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email to the Responsible Area Director.

NO.

7. Have the chairs verified that the document adheres to all of the
ID Checklist items ?

YES.

8. Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not also
ready for advancement or are otherwise in an unclear state? (note here
that the RFC editor will not publish an RFC with normative references
to IDs, it will delay publication until all such IDs are also ready
for publication as RFCs.)

YES.

9. What is the intended status of the document? (e.g., Proposed
Standard, Informational?)

Informational.

10. For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following sections:

* Technical Summary

This document provides recommendations for jittering (randomly
modifying timing) of control traffic transmissions in MANET routing
protocols to reduce the probability of packet collisions.

* Working Group Summary

This document contains information that was originally in OLSRv2. It
was pulled out and put in its own document, since it is applicable to
many MANET WG protocols (e.g. NHDP, OLSRv2, and DYMO) to avoid
collisions.

* Protocol Quality

There are a number of IETF documents/protocols that discuss introduced
jitter; these documents are cited. Though jitter is discussed in these
documents, in the context of MANET jitter should be handled in a
slightly different manner. This document goes into more details about
how jitter should be employed in MANETs.