Subject: [manet] RE: draft-ietf-manet-jitter-02

From: [email-masked]
Date: Mon, 29 Oct 2007 10:11:08 -0500

1.  I agree with Christopher Deerlove (email to MANET list on Fri, 26 Oct 
2007 09:35:42 +0100) that jitter should not be compulsory.  Whether it is 
needed or not depends upon the media access control (MAC) protocol that is 
used.  In particular, it is useful for most (if not all) single 
transceiver contention based MACs (like IEEE 802.11 MACs), but not 
necessarily needed for all MACs. For example, it may not be needed for 
some time division multiple access (TDMA) MACs.  Thus, I recommend the 
following changes:

* Add "often" in front of undesirable in first paragraph to 1. 
Introduction to show that it is not always undesirable

   In a wireless network, simultaneous packet transmission by nearby
   nodes is __often__ undesirable as, depending on the medium access 
control and
   other lower layer mechanisms, the interference between these
   transmissions may cause at best increased delay, and at worst
   complete packet loss.

* Thus in section 5. Jitter, "SHOULD" or "MAY" are acceptable, but "MUST" 
is not acceptable.

   In order to prevent nodes in a MANET from simultaneous transmission,
   whilst retaining the MANET characteristic of maximum node autonomy, a
   randomization of the transmission time of packets by nodes, known as
   jitter, MAY be employed.

2.  There are several examples of the words "may/MAY" and "should/SHOULD" 
that appear to be in an incorrect case.

Recommend replacing "may" with "MAY" or "should" with "SHOULD" in 
following places:

1st paragraph of 5.3
   When a node forwards a message, it may __MAY__be jittered by delaying 
it by
   a random duration. 

last 3 paragraphs of 5.3
   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 __SHOULD__ be 
appropriate to
      those mechanisms.

   o  As jitter is intended to reduce collisions, greater jitter, i.e.
      an increased value of MAXJITTER, is appropriate when the chance of
      collisions is greater.  This is particularly the case with
      increased node density, where node density should __SHOULD__ be 
considered
      relative to (the square of) the interference range rather than
      useful signal range.

   o  The choice of MAXJITTER used when forwarding messages may __MAY__ 
also
      take into account the expected number of times that the message
      may be sequentially forwarded, up to the network diameter in hops.

Recommend replacing "MAY" with "may" in following places:

1st paragraph of 5.2
   An internal or external condition or event MAY __may__ trigger message
   generation by a node.  Depending upon the protocol, this condition
   MAY __may__ trigger generation of a single message, initiation of a new
   periodic message schedule, or rescheduling of existing periodic
   messaging.  Collision between externally triggered messages is made
   more likely if more than one node is likely to respond to the same
   event.

Recommend reviewing last 4 paragraphs of 5.3 to determine whether "may" or 
"MAY" and "should" or "SHOULD" should be used.

3.  Section 5 discusses the 3 cases where jitter may be applied:

   o  Periodic message generation;

   o  Externally triggered message generation;

   o  Message forwarding.

The first and second cases appear to be related to the generation of 
control messages while the third case would apply to traffic as well as 
forwarded control messages.  This appears to be two different things:  the 
first two relate to network control processes while the third relate to 
network forwarding.  By including all three cases, this draft protocol 
appears to go beyond the issues arising from synchronization of MANET 
routing protocol messages and address the more general problem of 
mitigating against synchronization problems in general that can occur with 
some channel access protocols.  Is that the intent of this Internet Draft?

Similarly the discussion in section 5.3 about combining multiple packets 
into one transmission seems more relevant to a MAC discussion than a 
network layer discussion. 

Since some MANETS are used for process control with very low latency 
constraints and have MACs that support simultaneous transmission and 
receptions (e.g. are not sensitive to simultaneous transmissions), I would 
prefer that the word "MAY" stay with respect to Message forwarding (e.g. 
in section 5.3).  In fact, I would even like to insert some sort of text 
to discuss the difference between the first 2 cases and the third case. 

For example, the following paragraph in section 5.4 on whether to use 
jitter could also mention application for case 3 as well as MAC and lower 
layers:

   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.  ___The decision on using jitter for 
      Message Forwarding should also be appropriate to the application.___

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 29 Oct 2007 15:34:21 -0000

Thank you for your comments. Some responses below,
indicated with >>.

________________________________

From: [email-masked] [mailto:[email-masked]]

Sent: 29 October 2007 15:11
To: [email-masked]
Cc: [email-masked]; Dearlove, Christopher (UK);
[email-masked]
Subject: RE: draft-ietf-manet-jitter-02

*** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
Keep this in mind if you answer this message. 

1.  I agree with Christopher Deerlove (email to MANET list on Fri, 26
Oct 2007 09:35:42 +0100) that jitter should not be compulsory.  Whether
it is needed or not depends upon the media access control (MAC) protocol
that is used.  In particular, it is useful for most (if not all) single
transceiver contention based MACs (like IEEE 802.11 MACs), but not
necessarily needed for all MACs. For example, it may not be needed for
some time division multiple access (TDMA) MACs.  Thus, I recommend the
following changes: 

* Thus in section 5. Jitter, "SHOULD" or "MAY" are acceptable, but
"MUST" is not acceptable. 

2.  There are several examples of the words "may/MAY" and
"should/SHOULD" that appear to be in an incorrect case. 

1st paragraph of 5.3

last 3 paragraphs of 5.3 

1st paragraph of 5.2 
   An internal or external condition or event MAY __may__ trigger
message
  generation by a node.  Depending upon the protocol, this condition
  MAY __may__ trigger generation of a single message, initiation of a
new
  periodic message schedule, or rescheduling of existing periodic
  messaging.  Collision between externally triggered messages is made
  more likely if more than one node is likely to respond to the same
  event. 

Recommend reviewing last 4 paragraphs of 5.3 to determine whether "may"
or "MAY" and "should" or "SHOULD" should be used. 

  o  Message forwarding. 

The first and second cases appear to be related to the generation of
control messages while the third case would apply to traffic as well as
forwarded control messages.  This appears to be two different things:
the first two relate to network control processes while the third relate
to network forwarding.  By including all three cases, this draft
protocol appears to go beyond the issues arising from synchronization of
MANET routing protocol messages and address the more general problem of
mitigating against synchronization problems in general that can occur
with some channel access protocols.  Is that the intent of this Internet
Draft?

>> The primary purpose here is forwarding control messages,
>> not traffic (for which I wouldn't use the word messages).
>> The principal issues addressed are relevant to flooded
>> (possibly by an optimised mechanism) messages, not to
>> unicast traffic. Of course there may be circumstances you
>> might jitter traffic, but that's not what we are considering
>> here.

>> I think it's highly relevant, if you consider in the
>> context of the packetbb draft from the WG. That is
>> combining messages into packets at the network layer,
>> and has an interaction with jitter as discussed here.   

Since some MANETS are used for process control with very low latency
constraints and have MACs that support simultaneous transmission and
receptions (e.g. are not sensitive to simultaneous transmissions), I
would prefer that the word "MAY" stay with respect to Message forwarding
(e.g. in section 5.3).  In fact, I would even like to insert some sort
of text to discuss the difference between the first 2 cases and the
third case.

>> I think the difference isn't as you have indicated, because
>> traffic isn't our consideration. When considering control
>> traffic generation, this is as much a SHOULD as the other
>> cases.

For example, the following paragraph in section 5.4 on whether to use
jitter could also mention application for case 3 as well as MAC and
lower layers: 

      Message Forwarding should also be appropriate to the
application.___

>> Consequently I think that's not a distinction I would make.

Jim Stevens 

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

---

From: [email-masked]
Date: Mon, 29 Oct 2007 13:08:45 -0500

Chris, in response to your response to my comments about Message 
Forwarding in section 5.3:

Now that I understand that the Draft Internet is talking about control 
messages (e.g. like the one-hop forwarding of broadcast link control 
messages) instead of more general traffic forwarding; I agree with your 
comments to my comments on Message Forwarding (the extract of your 
response below).

Note that distinction (between control messages and general network 
traffic)  was not clear to me when I read the Internet Draft. Thus, I 
recommend that some additional clarification is needed.  Either in section 
5.3 (preferrably) but possibly as a definition of a message in section 2.

Jim

"Dearlove, Christopher (UK)" <[email-masked]> 
10/29/2007 10:34 AM

To
<[email-masked]>, <[email-masked]>
cc
<[email-masked]>, <[email-masked]>
Subject
RE: draft-ietf-manet-jitter-02

[text deleted] 

  o  Message forwarding. 

Jim Stevens

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 30 Oct 2007 09:38:22 -0000

I need to look at the draft to work out where/what to add, but some
clarification can be added (by whoever edits it next). Partly that can
be
a (non-normative) reference to packetbb, which has that organisation,
but this document is not specific to packetbb, and a wider comment
(with packetbb as an example) should work I think. Thanks again for
 the comments (the MAY/may, SHOULD/should ones as well).

Sent: 29 October 2007 18:09
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-ietf-manet-jitter-02

*** WARNING ***

Note that distinction (between control messages and general network
traffic)  was not clear to me when I read the Internet Draft. Thus, I
recommend that some additional clarification is needed.  Either in
section 5.3 (preferrably) but possibly as a definition of a message in
section 2. 

Jim 

10/29/2007 10:34 AM 
 Encrypted 

To

[text deleted] 

 o  Message forwarding. 

Jim Stevens