TSVWG                                                         J. Babiarz
Internet-Draft                                                   K. Chan
Expires: August 22, 2005                                 Nortel Networks
                                                               V. Firoiu
                                                             BAE Systems
                                                       February 18, 2005


         Congestion Notification Process for Real-Time Traffic
                      draft-babiarz-tsvwg-rtecn-03

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   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 August 22, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies the usage of Explicit Congestion Notification
   (ECN) markings for real-time inelastic flows such as voice, video
   conferencing, and multimedia streaming.  We build on the principles
   of RFC 3168, "The Addition of Explicit Congestion Notification to



Babiarz, et al.          Expires August 22, 2005                [Page 1]


Internet-Draft                  Document                   February 2005


   IP", and apply them to real-time inelastic traffic in DiffServ
   networks.  The method specified in this document has the requirement
   that these real-time inelastic flows can be distinguished from other
   flows and may receive separate treatment from the network.

   We introduce new ECN semantics that provide information for two
   levels of experienced congestion along the path for real-time
   inelastic flows.  This document describes how network nodes perform
   ECN marking for real-time inelastic flows when congestion is
   experienced, but it is left up to the application designers to define
   how end-systems should react to ECN bit marking.  For illustration
   purposes, an example is provided showing how ECN for real-time UDP
   flows can be used for admission control of VoIP flows.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Requirements Notation  . . . . . . . . . . . . . . . . . .  4
     1.2   Applicability and Operating Environment  . . . . . . . . .  4
     1.3   Network with DiffServ and Real-Time ECN Support  . . . . .  4
   2.  General Principles . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Congestion for Real-Time Traffic . . . . . . . .  6
     3.1   Avoiding Congestion for Real-Time Traffic  . . . . . . . .  7
     3.2   Congestion Detection for Real-Time Traffic . . . . . . . .  8
     3.3   Behavior of Meter and Marker . . . . . . . . . . . . . . .  9
     3.4   Marking for Congestion Notification  . . . . . . . . . . .  9
       3.4.1   Congestion Notification for Real-Time Traffic  . . . . 10
       3.4.2   ECN Marking of Real-Time Inelastic Flows . . . . . . . 11
       3.4.3   ECN Semantics for Real-Time Traffic  . . . . . . . . . 11
   4.  Detection of Inappropriate Changes to the ECN Field  . . . . . 12
   5.  Example of ECN usage for Admission Control . . . . . . . . . . 14
   6.  Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Issues List  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1  Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2  Informative References . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
   A.  Meter Example  . . . . . . . . . . . . . . . . . . . . . . . . 18
     A.1   Introduction . . . . . . . . . . . . . . . . . . . . . . . 19
     A.2   Meter Configuration  . . . . . . . . . . . . . . . . . . . 19
     A.3   Meter Behavior . . . . . . . . . . . . . . . . . . . . . . 20
     A.4   Marking  . . . . . . . . . . . . . . . . . . . . . . . . . 21
     A.5   Summary of the Behavior  . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 22




Babiarz, et al.          Expires August 22, 2005                [Page 2]


Internet-Draft                  Document                   February 2005


1.  Introduction

   This document summarizes the recommended method for providing
   end-to-end Explicit Congestion Notification (ECN) for real-time
   inelastic flows such as voice, video conferencing, and multimedia
   streaming.  RFC 3168 [6] specifies the incorporation of ECN for IP,
   including ECN's use of two bits in the IP header.  This document
   builds on the concepts of RFC 3168, "The Addition of Explicit
   Congestion Notification to IP", and applies them to real-time
   inelastic flows in DiffServ enabled networks.

   To address a wider usage of this mechanism, it is necessary to
   introduce new semantics for the ECN field of the IP header (bits 6
   and 7 of the TOS byte) that can provide two levels of congestion
   indication for real-time inelastic flows.  There are applications and
   services that need to provide different treatment at the application
   level based on the importance of the flow for a given level of
   congestion experienced.  For example, higher importance flows within
   a service class used for real-time traffic may need to get priority
   access to the network resources over regular traffic.  This document
   specifies the required behavior of network nodes that are configured
   to provide ECN-capability for real-time flows.

   The operating environment is discussed first, and then functions are
   defined that need to be performed in the network for real-time flows.
   Specifically, this includes (1) congestion detection through the use
   of flow measurement and (2) marking of ECN bits in the IP header of
   real-time packets for a given DSCP-marked service class.  Since
   real-time inelastic flows like voice and video conferencing are very
   delay sensitive, a different method than what is specified in RFC
   3168 for determining levels of congestion needs to be used.

   The proposal is to use ECN as a method to notify the application that
   packets flowing on this path are above the engineered capacity of the
   service class that is used for real-time traffic in the network.
   Based on this information, the application may take action to reduce
   its sending rate by whatever means is appropriate; for example stop
   sending packets, or reduce its rate, or not admit new flows while the
   path remains congested.  The reaction or decision taken by the
   application to the ECN marking is not specified in this document as
   it will depend on the application.  It is left up to application
   designers to define how applications in end-systems should react to
   ECN bit marking that is performed in the network.  It is expected
   that application specific documents will be produced to explain the
   application's usage of this real-time ECN mechanism.  For
   illustration purposes, a high level example of a procedure that may
   be used for admission of VoIP flows based on ECN marking within a
   service class in the network is provided.  The details of this



Babiarz, et al.          Expires August 22, 2005                [Page 3]


Internet-Draft                  Document                   February 2005


   example is provided by Admission Control Use Case for Real-time ECN
   [7].

1.1  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

1.2  Applicability and Operating Environment

   Networks that need to support real-time inelastic services may need
   to provide a controlled environment that allows for a high level of
   guarantees on the quality of service to be honored.  We suggest the
   use of DiffServ service classes to separate the real-time inelastic
   traffic from the other traffic for such a controlled environment, and
   applying the Real-Time ECN process discussed in this document.

   This document addresses the use of the ECN markings in a DiffServ
   controlled environment, with ECN marking both as defined herein and
   in RFC 3168 [6] co-existing in the same network but in different
   service classes.  As well, there may be network segments that do not
   deploy any ECN processing at all.  These operating environments are
   explored and discussed herein.  But in all cases, DiffServ separation
   of the real-time inelastic traffic from the other traffic should be
   supported.  With the basic rules of:

   o  no mixing of Real-Time ECN and RFC 3168 ECN marking in the same
      service class

   o  no mixing of traffic from Real-Time ECN capable end-systems and
      from Real-Time ECN un-capable end-systems into the same service
      class

   o  allowed mixing of traffic from ECN and non ECN capable end-systems
      at points where congestion is not possible


1.3  Network with DiffServ and Real-Time ECN Support

   The real-time ECN process requires that the real-time inelastic
   traffic is separated from the other traffic.  Within a DiffServ
   network, it is perfectly fine to deploy RFC 3168 ECN marking for
   service classes that are used for elastic TCP traffic and to deploy
   Real-Time ECN marking as defined herein for service classes that are
   used for inelastic real-time traffic.  DiffServ is used to separate
   the real-time traffic from the other traffic flows, and Real-Time ECN
   processing is applied to this separated traffic to provide control



Babiarz, et al.          Expires August 22, 2005                [Page 4]


Internet-Draft                  Document                   February 2005


   within the service class.  Under this condition, the most optimal
   deployment is to have all network segments support DiffServ, with
   Real-Time ECN marking capability on selected nodes where congestion
   within the real-time service class is likely.  Over time, as traffic
   levels within the real-time service class become complex and/or the
   network topology becomes more complex, it may be preferable that
   Real-Time ECN capability is extended to all or most network nodes.

   This notion of traffic separation into different service classes also
   applies to end-systems supporting Real-Time ECN processing.  Traffic
   from end-systems that do not support Real-Time ECN processing
   (reaction to ECN marking) should not be placed into the same DiffServ
   service class as traffic that does.  If it were, the end-systems that
   do not support the Real-Time ECN processing would not "back off" on
   onset of congestion conditions and would impact flows from
   end-systems that support Real-Time ECN processing.

   This approach allows for specific network nodes where congestion is
   very unlikely to occur not to require DiffServ or Real-Time ECN
   processing to be deployed.

2.  General Principles

   In this section, some of the important design principles and
   assumptions guiding the development of this proposal are described.

   o  Because ECN for real-time flows is likely to be adopted gradually
      and selectively in nodes, accommodating migration and selective
      deployment is essential.  Some nodes may not be able to detect
      congestion or mark the ECN bits within IP packet headers.  Also
      there may be parts of the network where congestion is very
      unlikely and therefore there is no need for an ECN function.  The
      most viable strategy is one that accommodates selective or
      incremental deployment in a network with both ECN-capable and
      non-ECN-capable nodes.

   o  Asymmetric routing is likely to be a normal occurrence within IP
      networks.  That is, the path (the sequence of links and nodes)
      taken by forward and reverse packet flows may be different.

   o  Many nodes process the "regular" header in IP packets more
      efficiently than they process the header information in IP
      options.  This suggests that the ideal approach is to keep
      "congestion experienced" information in the regular header of an
      IP packet.

   o  A specific DiffServ service class would be implemented exclusively
      for real-time traffic flows from ECN-capable end-systems.  A



Babiarz, et al.          Expires August 22, 2005                [Page 5]


Internet-Draft                  Document                   February 2005


      different DiffServ service class is used to identify real-time
      flows that are not ECN-capable.  Hence, the ECT(0) or ECT(1)
      indicators defined in RFC 3168 [6] are not needed.  The assumption
      is that a signaling protocol (SIP, H.323, MGCP, H.248, etc.) will
      be used to determine if the end-systems are capable of
      understanding ECN bit marking and thus, are willing to participate
      in congestion control prior to usage of the specific ECN-enabled
      service class.

   o  Furthermore, it is desirable that real-time traffic flows from
      ECN-capable and non-ECN-capable end-systems does not use the same
      DiffServ service class.  Mixing the two may cause the flows that
      are non-ECN-capable to generate congestion and to introduce delay
      and/or packet drop to both ECN-capable and non-ECN-capable flows.

   o  The proposed real-time ECN mechanism assumes end-to-end usage of
      DiffServ in order to allow differentiation of real-time ECN
      capable traffic from all other traffic on the network.  For the
      real-time ECN capable traffic, the ECT(0) and ECT(1) states
      defined in RFC 3168 [6] are not used in the network.  This is
      reasonable as the proposed mechanism is meant for managed IP
      networks.

   o  Flow measurement and marking of ECN bits is defined herein to be
      performed on flows that are mapped to a set of ECN-enable service
      classes, and is performed only on selected node links in the
      network where congestion is likely to occur.  Other traffic flows
      are not affected by this function.  Nodes that do not support this
      function forward packets without modifying bit 6 and 7 in the ECN
      field of the IP header.

   o  ECN procedure as defined in RFC 3168 [6] may also be applied to
      DiffServ service classes in the IP network.  Both methods may
      co-exist in the network, but in different DiffServ service
      classes.


3.  Definition of Congestion for Real-Time Traffic

   Real-time traffic generated by applications such as voice, video
   conferencing, and multimedia streaming have different performance
   requirements when compared with non-real-time applications that use a
   protocol such as TCP.  One such requirement is that end-to-end delay
   be bounded by a small value, and that packets should not be dropped.

   It is generally accepted that such performance requirements can be
   achieved when the real-time flows are serviced by the nodes in their
   path through a real-time service class such as one based on the EF



Babiarz, et al.          Expires August 22, 2005                [Page 6]


Internet-Draft                  Document                   February 2005


   PHB treatment.  This treatment can be provided only when the
   real-time service class is not overloaded (i.e., when the aggregate
   of input traffic never exceeds the class' capacity, and thus no
   congestion condition occurs).  It should also be noted that when the
   overloaded condition occurs, all real-time traffic flows within the
   real-time service class at the congestion point will be affected, not
   just the offending traffic flow.  Hence, it is desirable to avoid the
   overloaded condition as much as possible.

   With the above performance requirements for real-time inelastic
   traffic in mind, "congestion of real-time inelastic traffic" is
   defined to be the network condition when aggregated packet flows
   within the service class exceed an engineered traffic level.  The
   engineering of the network is such that traffic exceeding this
   engineered traffic level by a defined and limited amount does not
   generally cause an increase in packet queuing or packet dropping
   (service class overload) in the network.  Instead, the ECN field is
   used to provide an indication that traffic is above the engineered
   traffic level.  This can be viewed as explicit notification to
   prevent congestion.  However, uncontrolled or prolonged increase in
   traffic above the defined amount may result in an increase in packet
   queuing and/or packet dropping, and therefore may cause overload of
   the real-time service class.

3.1  Avoiding Congestion for Real-Time Traffic

   Congestion (ECN) notification can be utilized in a flow admission
   control scheme to ensure sufficient forwarding resources (bandwidth).
   In this scheme, a continuous process at selected link(s)/node(s)
   measures the traffic going through a specified real-time service
   class and indicates a level of congestion (such as "not congested",
   "mildly congested" or "severely congested").  This congestion
   indication as described in Section 3.4.3 is then used by the
   application to select the action that will be taken by the
   application controlling the service.  The action could be to admit or
   not to admit a new flow into that real-time service class in the
   network, or have the sending rate of ECN marked flows reduced or
   stopped, or terminate a flow.  All with the effect of reducing level
   of offered traffic.  Based on the performance requirements of
   real-time traffic, it is desirable that the measurement process
   indicate congestion of real-time traffic before any significant
   packet accumulation in the queue occurs.  This is such that no
   significant queuing delay is added to existing real-time flows'
   end-to-end delay.

   An alternative method to avoid the overloaded condition of a service
   class is through resource reservation and admission control: a
   (centralized or distributed) database maintains a record of available



Babiarz, et al.          Expires August 22, 2005                [Page 7]


Internet-Draft                  Document                   February 2005


   resources (bandwidth) for the real-time service class on each link in
   the network and a new flow is admitted only if there are enough
   resources on the links in its path so that the overloaded condition
   is avoided.  Checking for available resources can be done with a
   reservation protocol or through a policy based protocol.  An
   important issue is that the maintenance and per-flow querying of the
   resource database in conjunction with the routing database is an
   important overhead that is undesirable in many implementations.

   The present proposal of using ECN for congestion indication on
   real-time flows enables measurement-based solutions for congestion
   avoidance that do not have such scalability problems associated with
   resource databases.

3.2  Congestion Detection for Real-Time Traffic

   One of the goals is to keep the amount of processing that is
   performed in the network to be very small and not require any other
   computations or state information to be kept in network nodes.  One
   way to achieve this is through monitoring the aggregate rate of
   traffic in the specified real-time service class and to indicate
   congestion when a certain traffic threshold is exceeded.  Hence the
   network nodes only need to perform flow measurement of packets marked
   with the defined DSCP value(s) and set the ECN bit(s) when that
   traffic rate exceeds the defined level.  The application monitors the
   ECN field, and takes an appropriate action based on the marking.

   Figure 1 below shows a block diagram of the traffic measurement and
   ECN marking function.

   The Meter meters each packet within the real-time service class and
   passes the packet and the metering result to the ECN Marker:
                         +------------+
                         |   Result   |
                         |            V
                     +-------+    +--------+
                     |       |    |  ECN   |
   Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
                     |       |    |        |
                     +-------+    +--------+

          Figure 1: Block Diagram of Meter and Marker Function

   The Marker sets the ECN bit values for each packet within the
   real-time service class based on the results of the Meter.

   The traffic rate of the specified service class may be measured with
   a simple token bucket meter, an exponentially weighted moving average



Babiarz, et al.          Expires August 22, 2005                [Page 8]


Internet-Draft                  Document                   February 2005


   meter, or other methods.  The goals of a rate measuring method are
   simplicity and minimum or no added delay to traffic forwarding.

   The specification of the traffic measurement mechanism is outside the
   scope of this document.  The intention is that an existing traffic
   measurement mechanism may be used.  In Appendix A, an example of a
   simple token bucket method for measurement and marking is provided.

3.3  Behavior of Meter and Marker

   When the measured rate exceeds the engineered traffic level (for
   example, when token bucket runs out of tokens), the Meter sets its
   result flag and passes it to the Marker.  The Marker, sets the
   appropriate ECN value for all packets belonging to the service class
   that is measured until the result flag from the Meter is cleared.

   When the measured traffic rate is equal to, or is reduced below the
   engineered rate (the token bucket becomes full) the Meter clears the
   result flag if set.  The clearing of the result flag output from the
   Meter stops marking ECN bits by the Marker.  The metering function
   has built-in hysteresis for setting and clearing the result flag.
   The amount of hysteresis is controlled by the configuration
   parameters of the traffic measurement mechanism and should be
   configured to meet the characteristics of the real-time inelastic
   traffic that is being measured.

3.4  Marking for Congestion Notification

   Marking for Explicit Congestion Notifications is done through the use
   of the two ECN bits in the IP header.

                   0    1    2    3    4    5    6    7
                 ----+----+----+----+----+----+----+----
                |      DS FIELD, DSCP         |ECN FIELD|
                 ----+----+----+----+----+----+----+----
                 DSCP: Differentiated Services Codepoint
                 ECN: Explicit Congestion Notification

                Figure 2: DS and ECN Fields in IP Header

   Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field.
   The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6,
   and the ECN field is defined identically in both cases.  The
   definitions for the IPv4 TOS octet RFC 791 [1] and the IPv6 Traffic
   Class octet have been superseded by the six-bit Differentiated
   Services (DS) field RFC 2474 [4],  RFC 2780 [5].  Bits 6 and 7 are
   listed in RFC 2474 [4] as Currently Unused, and are specified in RFC
   2780 as approved for experimental use for ECN.  Finally, RFC 3168 [6]



Babiarz, et al.          Expires August 22, 2005                [Page 9]


Internet-Draft                  Document                   February 2005


   standardized the use of the ECN bits.

3.4.1  Congestion Notification for Real-Time Traffic

   Proposed is an usage of the ECN bits in addition to RFC 3168 [6] for
   indicating two levels of congestion for real-time inelastic packet
   flows in DiffServ capable networks.  The selected nodes in the
   network are configured to measure real-time traffic that is
   classified and marked via a DS codepoint as requiring congestion
   control.

   We would like to keep the amount of processing that is performed in
   the network elements to be minimal and not require any flow state
   information to be kept in network nodes.  The network nodes only need
   to perform flow measurement of ECN-Capable Transport (ECT) marked
   packets for  the defined DSCP value(s) and set the ECN bit to
   indicated congestion experienced when that traffic rate exceeds the
   defined level.

   Figure 3 defines the new ECN semantics for two levels of congestion
   experienced marking as they apply to real-time inelastic flows.  This
   ECN marking was selected to keep some commonality with the marking
   and naming in RFC 3168 [6].  RFC 3168 [6] defined ECN marking for a
   single level of congestion with two ECT codepoints '10' ECT(0) and
   '01' ECT(1) to provide one-bit ECN nonce for detection of cheaters.
   Since many application that posses real-time inelastic traffic
   characteristics require two levels of congestion notification, we
   have redefined ECN codepoint '01' to represent congestion experienced
   at 2nd level CE(2).  Also, ECN codepoint '11' is renamed from
   congestion experienced (CE) to congestion experienced at 1st level
   CE(1).  See Section 4 for a procedure that may be used to detect
   cheaters.

   The targeted applications have a requirement that the network provide
   real-time transport with very low packet loss and delay.  When mixing
   flows from ECN-capable and non-ECN-capable end-systems into the same
   service class and using ECT for providing treatment differentiation
   (dropping or ECN marking), policing (metering and dropping) of
   Not-ECT marked packets SHOULD be performed so that the service class
   is not oversubscribed.  Oversubscription may result in
   non-ECN-capable end-systems continuing to offer traffic at the
   current level or possibly even increase the offered rate, therefore
   causing queue buildup (delay) and eventually introducing packet loss
   to flows from ECN-capable end-systems.

   We prefer to take a gradual or incremental approach for deployment of
   ECN-capable nodes in the network and use the DiffServ architecture
   for flow differentiation.  Therefore, this new functionality needs



Babiarz, et al.          Expires August 22, 2005               [Page 10]


Internet-Draft                  Document                   February 2005


   only to be deployed in selected nodes, where congestion is likely to
   occur.  The premise is that different traffic types are separated
   using Differentiated Services into two or more service classes with
   different polices for each traffic type.  However, both methods as
   described in RFC 3168 and as documented herein for real-time
   inelastic traffic can co-exist in the network, using independent
   DiffServ service classes.

3.4.2  ECN Marking of Real-Time Inelastic Flows

   Marking of ECN bits for real-time inelastic flows is defined so that
   nodes in the path only need to perform an ECN set function when an
   engineered rate is exceeded.  With this approach there is no need to
   perform a test of ECT marked packets to determine at what level of
   congestion experienced that packet is marked.  Other approaches could
   be used, but for simplicity we have chosen this one.

   Nodes that are configured to support congestion notification for
   real-time flows need to provide the following capabilities:

   o  Congestion detection of ECT marked packets SHOULD be performed
      using a real-time measurement mechanism (e.g., flow metering).

   o  At a minimum, one flow congestion detection mechanism is REQUIRED
      to be associated to a link where congestion measurement is
      performed.

   o  When the flow rate exceeds configured rate "A" (i.e., the first
      level of congestion), ECN bit 7 of ECT market packets is set to
      '1'.

   o  When the flow rate exceeds configured rate "B" (i.e., the second
      level of congestion), ECN bits  6 and 7 of ECT market packets are
      set to '01'.

   o  Measured rate "B" SHOULD be greater than rate "A".

   Nodes in the IP network MAY be configured to support one or two
   congestion detection levels.

3.4.3  ECN Semantics for Real-Time Traffic

   Some real-time applications or services need the indication of two
   levels of congestion experienced, CE(1) and CE(2), for first and
   second level respectively.  Other applications may only need the
   indication of a single level of congestion experienced.  To address a
   wide range of usage, we have selected the following ECN semantics for
   real-time inelastic traffic.



Babiarz, et al.          Expires August 22, 2005               [Page 11]


Internet-Draft                  Document                   February 2005


   ECN Marking:

   Bits 6 and 7 values
        0     0      Not-ECT - Endpoints are Not ECN-Capable
        0     1      CE(2)   - Congestion Experienced  at 2nd level
        1     0      ECT(0)  - Endpoints are ECN-Capable
        1     1      CE(1)   - Congestion Experienced at 1st level

              Figure 3: ECN Semantics for Real-Time Flows

   Specific applications may take different action(s) in response to
   congestion being experienced in the network.  Depending on the
   application, one possible outcome may be for the application to stop
   initiating new real-time inelastic flows at the 1st level of
   congestion, and if the offered load in the selected service class
   reaches the 2nd level of congestion, the application in the
   end-system stops sending packets.  Most likely, different
   applications will take various independent actions.  The various
   independent actions taken by the applications are out of scope of
   this document.

4.  Detection of Inappropriate Changes to the ECN Field

   This section discusses in detail possible inappropriate changes to
   the ECN field in the network, such as falsely reporting no
   congestion, by erasing the ECN congestion indication.

   In the implementation of a Real-Time ECN mechanism in the network,
   the network administrator through the use of policies or through the
   use of signaling/control protocols such as SIP can verify the
   capabilities and conformance of the end-systems.  As stated earlier,
   only end-systems that are capable and conformant to Real-Time ECN
   mechanism may use it.  End-systems that are not Real-Time ECN capable
   or conformant are mapped into a different service class (a service
   class that is configured not to use Real-Time ECN) or are not allowed
   access to the network through a deployment of a filter policy at the
   network edge.

   The Real-Time ECN mechanism provides two levels of congestion
   indication; therefore, the cheating detection mechanism as defined in
   RFC 3168 that uses ECT(0) and ECT(1) state can not be used.  Instead,
   the following procedure may be used to catch cheaters, network nodes,
   software drivers or plug-ins that are not part of the certified
   application in the end-system, altering ECN bit marking.  The
   outlined procedure may be executed under the control of the
   application prior to admission of a new real-time flow or
   periodically to verify the conformance of ECN marking.  The testing
   for conformance is between the two ECN capable and conformant



Babiarz, et al.          Expires August 22, 2005               [Page 12]


Internet-Draft                  Document                   February 2005


   applications running in the end-systems referred to as sender and
   responder.

   Prior to admission of a new real-time flow, the following procedure
   can be used to detect cheaters.  Note that this procedure is
   independent of an actual admission control procedure.

   o  Under the control of the application, the sender generates and
      sends a single test packet referred to as a Request Probe Packet.
      The packet's ECN field is distinctly marked with the value 01,
      which an ECN-capable router and the responder will perceive as
      CE(2).

   o  Upon reception of the Request Probe Packet, the responder echoes
      the received Request Probe Packet back to the sender as a Response
      Probe Packet, including the value of the ECN field in the IP
      header of the Request Probe Packet in the payload of the Response
      Probe Packet.

   o  The sender compares the received ECN marking in the payload of the
      Response Probe Packet with the value 01 originally set in the
      Request Probe Packet.  If it is 10 or 11 (ECT(0) or CE(1)), then a
      cheater is present in the network which lowered the ECN marking.

   The above procedure can optionally be used a second time, but using
   the ECN value 11, or CE(1), on the Request Probe Packet.

   Due to the nature of the Real-time ECN process described in this
   memo, it is only possible to detect for the presence of cheaters
   which lower the ECN marking.

   Also, detection of cheaters is only possible if there are no other
   ECN-capable routers down stream from the cheating device along the
   network path legitimately marking the ECN bits, masking out the
   cheating condition.  If there are one or more ECN-capable routers
   along the network path after the cheating device, then the cheater
   can only be detected if the ECN-capable router(s) after it do not
   mark the probe packets with a higher ECN value than set by the
   cheating device.

   Once a new real-time flow has been admitted, the following procedure
   can be used to detect cheaters:

   o  The two endpoints involved in a flow negotiate a value N.
      Normally, a ECN-capable endpoint uses the value 10, or ECT(0), as
      the ECN for an RTP packet in a flow.  The negotiated value N is
      used such that every Nth packet sent for the flow is initially
      marked with ECN 01, or CE(2).  Upon receipt of the RTP packets,



Babiarz, et al.          Expires August 22, 2005               [Page 13]


Internet-Draft                  Document                   February 2005


      the endpoint compares the received ECN with the expect value of
      01, or CE(2).  If a cheater is present, and is not being
      overridden by one or more ECN-capable router after it along the
      path through the network, the endpoint detects the presence of a
      cheater if the received ECN value is 10 or 11 (ECT(0) or CE(1)).


5.  Example of ECN usage for Admission Control

   Normally real-time VoIP bearer traffic is marked with EF DSCP and is
   mapped into a DiffServ service class that produces very low latency,
   jitter and packet loss when the traffic load is within the specified
   parameters.  Currently there is no method defined that can limit
   (without dropping packets) the amount of traffic that can be
   aggregated onto a link.  As a result, controlling loads to within
   engineered limits is difficult.  To address this issue, we propose
   that for real-time flows we use the metering and ECN marking method
   defined in this document.

   Here we describe how ECN can be used in real-time VoIP solution to
   provide end-to-end admission of new media flows.  This is only a
   simple example of how admission control may be implemented using rate
   metering and ECN bit marking in the network.  Different applications
   may use modified approaches to verify if there is sufficient
   bandwidth before admitting a new flow.

   Let us assume that the network is configured to mark real-time VoIP
   payload packets with EF DSCP, and only this traffic is mapped into a
   DiffServ service class referred to as Telephony service class.
   Mapping of real-time traffic marked with other DSCP values is
   possible but to keep this example simple we will only talk about EF
   marked packets.

   For example, before a session (i.e., a call) is established between
   two clients, the two endpoints involved in the call will execute a
   request/response transaction where the called party (Client B) sends
   a Request probe packet to the calling party (Client A) and the
   calling party correspondingly sends back a Response probe packet to
   the called party.  Probe packets are marked with EF DSCP and are
   mapped into the Telephony service class.

   A DiffServ style traffic meter and ECN marker are used on selected
   nodes in the network along the path to measure the aggregated
   (real-time media and probe packets) flow rate of EF marked packets.
   If the flow rate of the EF marked packets as measured by the meter is
   greater than rate "A", bit 7 in the ECN field of IP header is set to
   1 and the packet is forwarded as usual.  The metering and marking of
   ECN bit only needs to be performed on selected nodes where bandwidth



Babiarz, et al.          Expires August 22, 2005               [Page 14]


Internet-Draft                  Document                   February 2005


   constraints exist and where congestion is likely to occur.

   Upon receipt of the Request probe packet, the calling party generates
   and sends a Response probe packet to the called party, echoing the
   status of the received ECN bits in the Response probe packet.  Again,
   a DiffServ style traffic meter and ECN marker are used on selected
   nodes in the network along the reverse path to measure the aggregated
   flow rate of EF marked packets.  If the flow rate of EF marked
   packets as measured by the meter is greater than rate "A", bit 7 in
   ECN field of IP header is set to 1 and the packet is forwarded as
   usual.  On receipt of the Response probe packet, the called party
   could send a notification with the ECN Status to relay the ECN bit
   status results for the media path to a server in the network where
   call admission control is performed.  Based on the received
   congestion status (bandwidth usage) for that path, the admission
   control function will make a decision as to whether or not to
   continue with call setup and admit this new real-time flow.  Should
   bandwidth usage parameters as indicated by ECN bit marking be
   exceeded, then this new real-time flow will not be admitted.

6.  Non-compliance

   Because of the unstable history of the TOS octet, the use of the ECN
   field as specified in this document cannot be guaranteed to be
   backwards compatible with any past uses of these two bits that
   pre-date ECN.  The potential dangers of this lack of backwards
   compatibility are discussed in RFC 3168 [6] Section 22.

7.  Issues List

   NOTE TO RFC EDITOR: Please remove this section during the publication
   process.

   The following issues list are based on comments received.

   Issues from Sally during our discussion at San Diego IETF 8/1-6/2004
   on -01 version of the draft.

   1.    Need to resolve Receiver Cheating situations.
          In -02:
          Section on cheating was added to draft.

   2.    Need to indicate why we are not concerned with ECT usage.
          In -02:
          Explanation was added. However, we are still investigating
          scenarios where ECT may be useful
          In -03:
          Added back the usage of ECT(0).



Babiarz, et al.          Expires August 22, 2005               [Page 15]


Internet-Draft                  Document                   February 2005


          But because ECT(1) is not used, catching cheating is still different from RFC 3168.

   3.    Clarify to indicate using specific DiffServ Code Point.
          In -02:
          Added clarification in "Abstract" section and added
          "Applicability and Operating Environment" section.

   4.    Need Applicability Statement up front.
          In -02:
          Added clarification in "Abstract" section and added
          "Applicability and Operating Environment" section.

   5.    Change the draft to indicate RFC 3168 applies to UDP as well as TCP (all IP traffic).
          In -02:
          Removed mentioning of RFC3168 focusing on TCP in "Introduction"
          and bottom of "Assumptions and General Principles" sections.

   6.    Provide an explanation on situation where there is a node in
          the middle that does not understand DiffServ but can do ECN.
          In -02:
          Added "Applicability and Operating Environment" section.

   7.    Sally preferred to have the ECN bits to have:
          00=Not-CE, 01=CE(0), 10=CE(1), 11=Not-DiffServ-CE.
           In -02: Open:
           Keeping current marking as is for this version of draft.
           Investigate alternate marking approach pros and cons for two level of congestion.
           In -03:
           Adopted the use of
           00=Not-ECT, 01=CE(2), 10=ECT(0), 11=CE(1); the Alt-1 semantics in early discussions.


8.  Security Considerations

   This document discusses detection of congestion for real-time traffic
   flows and also describes a common policy configuration, for the use
   and application of ECN bit marking.  If implemented as described, it
   should require the network to do nothing that the network has not
   already allowed.  If that is the case, no new security issues should
   arise from the use of such a policy.

   It is possible for the policy to be applied incorrectly, or for a
   wrong policy to be applied in the network for the defined congestion
   detection point.  In that case, a policy issue exists that the
   network must detect, assess, and deal with.  This is a known security
   issue in any network dependent on policy-directed behavior.

   A well known flaw appears when bandwidth is reserved or enabled for a



Babiarz, et al.          Expires August 22, 2005               [Page 16]


Internet-Draft                  Document                   February 2005


   service (for example, voice transport) and another service or an
   attacking traffic stream uses it.  This possibility is inherent in
   DiffServ technology, which depends on appropriate packet markings.
   When bandwidth reservation or a priority queuing system is used in a
   vulnerable network, the use of authentication and flow admission is
   recommended.  To the author's knowledge, there is no known technical
   way to respond to or act upon a data stream that has been admitted
   for service but that it is not intended for authenticated use.

9.  IANA Considerations

   To be completed.

10.  Acknowledgements

   The authors acknowledge a great many inputs, most notably from Sally
   Floyd, Nabil Bitar, Hadriel Kaplan, David McDysan, Mike Pierce, Alia
   Atlas, John Rutledge, Francois Audet, Tony MacDonald, Mary Barnes,
   Greg Thor, Corey Alexander, Jeremy Matthews, Marvin Krym, and Stephen
   Dudley.

11.  References

11.1  Normative References

   [1]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

   [2]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", RFC 2474, December 1998.

   [5]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
        Values In the Internet Protocol and Related Headers", BCP 37,
        RFC 2780, March 2000.

   [6]  Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
        Explicit Congestion Notification (ECN) to IP", RFC 3168,
        September 2001.

11.2  Informative References

   [7]  Alexander, C., "Admission Control Use Case for Real-time ECN",



Babiarz, et al.          Expires August 22, 2005               [Page 17]


Internet-Draft                  Document                   February 2005


        Internet-Draft draft-alexander-rtecn-admission-control-use-case-00
        , February 2005.


Authors' Addresses

   Jozef Z. Babiarz
   Nortel Networks
   3500 Carling Avenue
   Ottawa, Ont.  K2H 8E9
   Canada

   Phone: +1-613-763-6098
   Fax:   +1-613-768-2231
   Email: babiarz@nortel.com


   Kwok Ho Chan
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA  01821
   US

   Phone: +1-978-288-8175
   Fax:   +1-978-288-4690
   Email: khchan@nortel.com


   Victor Firoiu
   BAE Systems
   6 New England Executive Park
   Burlington, MA  01803
   US

   Phone: +1-781-505-4677
   Fax:   +1-781-273-9345
   Email: victor.firoiu@baesystems.com

Appendix A.  Meter Example

   This appendix provides an example of Real-Time ECN capability in a
   network node.  This example uses a Single Rate Meter and ECN Marker.
   For scenarios that require to measure two traffic levels within a
   service class for congestion indications, two instances of the single
   rate meter and ECN marker can be used, one for configured rate "A"
   and one for configured rate "B".  The meter parameters should be
   selected to meet the characteristics and performance requirements of
   traffic being measured as well meters' behavior for each level.



Babiarz, et al.          Expires August 22, 2005               [Page 18]


Internet-Draft                  Document                   February 2005


Appendix A.1  Introduction

   The Single Rate Meter and ECN Marker is configured by assigning
   values to the following parameters: Committed Information Rate (CIR),
   Token Bucket Size (TBS), upper threshold m (in percentage of TBS) and
   lower threshold n (in percentage of TBS).  The Token Bucket Update
   duration (TBU) is an implementation parameter that may not be
   configurable.  We also consider the Token Bucket Drain duration (TBD)
   resulting from the first two configurable parameters, TBD=TBS/CIR.
   The meter also has an internal state "flag" which when set indicates
   a condition where the measured traffic has exceeded the CIR and token
   in the token bucket were exhausted below the n threshold, as
   described below.  CIR is measured in bytes of IP packets per second,
   i.e., it includes the IP header, but not link specific headers.

   The Meter meters each packet within the real-time service class and
   passes the packet and the metering result to the Marker:

                         +------------+
                         |   Result   |
                         |            V
                     +-------+    +--------+
                     |       |    |        |
   Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
                     |       |    |        |
                     +-------+    +--------+

          Figure 4: Block Diagram of Meter and Marker Function

   The Marker sets the ECN bit values for each packet within the
   real-time service class based on the results of the Meter.

Appendix A.2  Meter Configuration

   The Single Rate Meter and ECN Marker is configured by assigning
   values to six traffic parameters: Committed Information Rate (CIR),
   Token Bucket Size (TBS), Token Bucket Drain duration (TBD)
   TBD=TBS/CIR, Token Bucket Update duration (TBU), and two thresholds
   (m and n) in percent of TBS.  CIR is measured in bytes of IP packets
   per second, i.e., it includes the IP header, but not link specific
   headers.

   TBS is measured in bytes, and represents the variants of the rate
   being measured.  Normally, variable rate traffic will need larger
   token bucket than constant rate traffic, and the size will depend on
   the characteristics of traffic being measured.  TBS should be
   configured such that traffic variation within the specified rate as
   measured at the node should not use up all the available tokens



Babiarz, et al.          Expires August 22, 2005               [Page 19]


Internet-Draft                  Document                   February 2005


   during a single TBD duration.

   TBD and TBU are measured in seconds and TBD should be configured to
   be at least 2 times greater than TBU.  For real-time inelastic
   traffic, it is recommended that TBD be configured to be greater than
   the expected inter-packet emission time at sender for the measured
   packet stream.  For best accuracy, TBU should be a small value, as
   small as implementation practical.

Appendix A.3  Meter Behavior

   The behavior of the Meter is specified in terms of its Token Bucket
   Size (TBS) with its rates CIR and Token Bucket Update duration (TBU).

      Where TBD = TBS/CIR and

      Where TBD > 2 x TBU

   The token bucket (TBS) initially (at time 0) is full, i.e., the token
   count is represented by Tp.

      Where Tp(0) = TBS

   Thereafter, tokens (Tp) are added to the token bucket at rate of (CIR
   x TBU) per TBU.

      Every TBU; Tp = Tp(t)+(TBU x CIR)

      If Tp(t) > TBS, Set Tp = TBS

      If result flag is set and Tp(t) + (TBU x CIR) > m x TBS, clear
      result flag, and set Tp = TBS

      Where m = 1-99% of TBS

   When a packet of size B bytes arrives at time t, the following
   happens:

      If result flag is not set and Tp(t)-B < n x TBS, set result flag,
      and set Tp to zero.  (TBS empty)

      Where n = 1-99% of TBS

      else

      Decrement Tp by B.

      Where m > n; both m and n are a percentage of TBS.



Babiarz, et al.          Expires August 22, 2005               [Page 20]


Internet-Draft                  Document                   February 2005


   The actual implementation of a Meter doesn't need to be modeled
   according to the above formal specification.

Appendix A.4  Marking

   The ECN Marker reflects the result flag setting received from the
   meter.  If result flag is set, all packets serviced by the real-time
   inelastic service class have their ECN bit set.  The ECN Marker sets
   the ECN bit as long as the result flag from the meter is set.

Appendix A.5  Summary of the Behavior

   When the measured rate is exceeded (token bucket runs out of tokens)
   the meter sets the "result flag" and passes it to the ECN Marker.
   The ECN Marker, sets the ECN bit of all packets belonging to the
   service classes flowing through the interface being measured until
   the traffic rate is reduced below the measuring threshold; thereby
   the token bucket becomes full.  When the token bucket becomes full,
   the meter clears the "result flag" if set.  The clearing of the
   result flag output from the meter stops the marking of ECN bit by the
   Marker.






























Babiarz, et al.          Expires August 22, 2005               [Page 21]


Internet-Draft                  Document                   February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Babiarz, et al.          Expires August 22, 2005               [Page 22]

<x-flowed>
</x-flowed>