--- 1/draft-ietf-manet-jitter-03.txt 2007-12-05 02:12:06.000000000 +0100 +++ 2/draft-ietf-manet-jitter-04.txt 2007-12-05 02:12:06.000000000 +0100 @@ -1,22 +1,22 @@ Mobile Ad hoc Networking (MANET) T. Clausen Internet-Draft LIX, Ecole Polytechnique, France Intended status: Informational C. Dearlove -Expires: May 19, 2008 BAE Systems Advanced Technology +Expires: June 6, 2008 BAE Systems Advanced Technology Centre B. Adamson U.S. Naval Research Laboratory - November 16, 2007 + December 4, 2007 Jitter considerations in Mobile Ad Hoc Networks (MANETs) - draft-ietf-manet-jitter-03 + draft-ietf-manet-jitter-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -27,21 +27,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 19, 2008. + This Internet-Draft will expire on June 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of @@ -63,31 +63,36 @@ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 1. Introduction 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. In some instances these problems can be solved - in these lower layers, but in other instances some help at the - network and higher layers is necessary. This document considers the - case when that help is required, and provides recommendations for - using jitter (randomly varying timing) to provide it. It is possible - that the techniques described here could be implemented either by IP - protocols designed for wireless networks or in conjunction with - lower-layer mechanisms. + nodes is often undesirable. This is because any resulting collision + between these packets may cause a receiving node to fail to receive + some or all of these packets. This is a physical problem, which + occurs before packets can be inserted into the receiver queue. + Depending on the characteristics of the medium access control and + other lower layer mechanisms, in particular whether retransmission of + unacknowledged packets is supported, this may cause at best increased + delay, and at worst complete packet loss. In some instances these + problems can be solved in these lower layers, but in other instances + some help at the network and higher layers is necessary. + + This document considers the case when that help is required, and + provides recommendations for using jitter (randomly varying timing) + to provide it. It is possible that the techniques described here + could be implemented either by IP protocols designed for wireless + networks or in conjunction with lower-layer mechanisms. The problems of simultaneous packet transmissions are amplified if any of the following features are present in a protocol: Regularly scheduled messages - If two nodes generate packets containing regularly scheduled messages of the same type at the same time, and if, as is typical, they are using the same message interval, all further transmissions of these messages will thus also be at the same time. Note that the following mechanisms may make this a likely occurrence. @@ -188,29 +193,28 @@ Any protocol based on [7] and using the message forwarding mechanism facilitated by that structure is a particular candidate for application of at least some of these mechanisms. The document has been generalized from the jitter mechanism used in the proactive MANET routing protocol OLSR (The Optimized Link State Routing Protocol) [5]. 4. Protocol Overview and Functioning - This document does not specify a protocol, nor does it mandate - specific node or protocol behavior. Rather, it outlines mechanisms - for message transmission (and retransmission) applicable in MANET - routing protocols and other protocols employing a periodic or - triggered message schedule and running over wireless interfaces where - simultaneous transmissions from two (or more) adjacent nodes causes - delays, packet losses and other problems. Any protocol using jitter - as outlined here must specify its precise usage insofar as is - necessary for interoperability. + This document provides recommendations for message transmission (and + retransmission) which may be used by MANET routing protocols. It may + also be used by other protocols that employ a periodic or triggered + message schedule running over wireless interfaces. Using such + protocols simultaneous transmissions from two (or more) adjacent + nodes may cause delays, packet losses and other problems. Any + protocol using jitter as outlined here must specify its precise usage + insofar as is necessary for interoperability. 5. Jitter 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, SHOULD be employed. Three jitter mechanisms, which target different aspects of this problem, SHOULD be employed, with the aim of reducing the likelihood of simultaneous transmission, and, if it occurs, preventing it from continuing. @@ -280,24 +284,26 @@ reduce this likelihood, an externally-triggered message SHOULD be jittered by delaying it by a random duration; an internally triggered message MAY also be so jittered if appropriate. This delay SHOULD be generated uniformly in an interval between zero and MAXJITTER. If periodically transmitted messages are rescheduled, then this SHOULD be based on this delayed time, with subsequent messages treated as described in Section 5.1. When messages are triggered, whether or not they are also periodically transmitted, a protocol MAY impose a minimum interval - between messages of the same type, denoted MESSAGE_MIN_INTERVAL. It + between messages of the same type, denoted MESSAGE_MIN_INTERVAL. In + the case that such an interval is not required, MESSAGE_MIN_INTERVAL + is considered to be zero. When MESSAGE_MIN_INTERVAL is non-zero, it is however appropriate to also allow this interval to be reduced by - jitter, so that when a message is transmitted the next message is - allowed after a time (MESSAGE_MIN_INTERVAL - jitter), where jitter + jitter. Thus when a message is transmitted the next message is + allowed after a time (MESSAGE_MIN_INTERVAL - jitter). This jitter SHOULD be generated uniformly in an interval between zero and MAXJITTER (using a value of MAXJITTER appropriate to periodic message transmission). It might appear counterintuitive to have a defined MESSAGE_MIN_INTERVAL, yet allow this to be reduced by jittering. For periodic messages, setting MESSAGE_INTERVAL, MAXJITTER and MESSAGE_MIN_INTERVAL such that (MESSAGE_INTERVAL-MAXJITTER) > MESSAGE_MIN_INTERVAL would ensure at least MESSAGE_MIN_INTERVAL would elapse between two subsequent message transmissions. In a highly @@ -380,43 +386,45 @@ well-designed protocol. Thus MAXJITTER SHOULD always be minimized, subject to acceptably achieving its intent. o When messages are periodically generated, all of the following that are relevant apply to each instance of MAXJITTER: * it MUST NOT be negative; * 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. + * it SHOULD NOT be greater than MESSAGE_INTERVAL/4. o If MESSAGE_MIN_INTERVAL > 0, then: * MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL; * MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2. 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. + those mechanisms. For example MAXJITTER should be significantly + greater than (e.g. an order of magnitude greater than) any medium + access control frame period. 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, which is significant relative to (the square of) the interference range rather than useful signal range. 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. + may be sequentially forwarded, up to the network diameter in hops, + in order that the maximum accumulated delay is bounded. 6. IANA Considerations This document presents no IANA considerations. 7. Security Considerations This document provides recommendations for mechanisms to be used in protocols; full security considerations are to be provided by those protocols, rather than in this document. @@ -478,21 +486,21 @@ Christopher Dearlove BAE Systems Advanced Technology Centre Phone: +44 1245 242194 Email: chris.dearlove@baesystems.com URI: http://www.baesystems.com/ Brian Adamson U.S. Naval Research Laboratory - Phone: +01 202-404-1194 + Phone: +01 202 404 1194 Email: adamson@itd.nrl.navy.mil URI: http://www.nrl.navy.mil/ Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.