TSVWG                                                         J. Babiarz
Internet-Draft                                                   K. Chan
Expires: August 5, 2004                                  Nortel Networks
                                                        February 5, 2004


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

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 5, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This memo specifies the incorporation of Explicit Congestion
   Notifications (ECN) for real-time flows that use UDP such as voice,
   video conferencing and multimedia streaming. Defined is the marking
   of the two ECN bits in the IP header and the requirements put on
   routers that are configured to provide the ECN marking capability for
   real-time UDP flows. Also, an example is provided showing how ECN for
   real-time UDP flows can be used for admission control of VoIP flows.








Babiarz & Chan           Expires August 5, 2004                 [Page 1]


Internet-Draft                  Document                   February 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Assumptions and General Principles . . . . . . . . . . . . . .  3
   3.  Congestion Detection for Real-Time Traffic . . . . . . . . . .  4
   4.  Explicit Congestion Notification for Real-Time Traffic . . . .  5
   5.  Example of ECN usage for Admission Control . . . . . . . . . .  6
   6.  Non-compliance . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
       Normative References . . . . . . . . . . . . . . . . . . . . .  8
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . 10




































Babiarz & Chan           Expires August 5, 2004                 [Page 2]


Internet-Draft                  Document                   February 2004


1. Introduction

   This paper summarizes the recommended method for providing end-to-end
   Explicit Congestion Notifications (ECN) for real-time flows such as
   voice, video conferencing and multimedia streaming. RFC 3168 [6]
   specifies the incorporation of ECN for TCP flows using IP, including
   ECN's use of two bits in the IP header. In this document we take the
   same concepts but apply them to real-time UDP flows. Since real-time
   flows like voice and video conferencing are very delay sensitive, a
   different method then what is specified in RFC 3168 for determining
   level of congestion needs to be used. Furthermore, we redefine the
   usage of Bit 6 and 7 of DS Field of IP header as compared to what is
   defined in RFC 3168.

   The proposal is to use ECN as a method to notify end applications
   that there is a bandwidth constraint or congestion along the path.
   Based on this information, the applications may take action to reduce
   their sending rate in what ever means is appropriate, stop sending
   packets or not admit any new flows if the path is congested.

   This document defines the functions that need to be performed in the
   network for real-time flows, specifically congestion detection
   through the use of flow metering and marking of ECN bits in the IP
   header of real-time packets. This document establishes how the ECN
   bits must be marked for this purpose. The reaction or decision taken
   by the application to the ECN markings is not specified in this
   document as it will depend on the application. However, we provided
   an example of a procedure that may be used for admission of VoIP
   flows based on measured congestion level in the network. In this
   admission control example, ECN bit marking is used to convey the
   congestion status for that VoIP flow being attempted to be setup.

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

2. Assumptions and General Principles

   In this section, we describe some of the important design principles
   and assumptions that guided choices in this proposal.

   o  Because ECN for real-time flows is likely to be adopted gradually
      and selectively in routers, accommodating migration and selective
      deployment is essential. Some routers may not be able to detect
      congestion (flow meter) and mark the ECN bits of the IP packets.
      Also there maybe parts of the network that congestion is very



Babiarz & Chan           Expires August 5, 2004                 [Page 3]


Internet-Draft                  Document                   February 2004


      unlikely and therefore there is no need for ECN function. The most
      viable strategy is one that accommodates selective or incremental
      deployment without having to resort to "islands" of ECN-capable
      and non-ECN-capable environments.

   o  Asymmetric routing is likely to be a normal occurrence in the
      Internet. The path (sequence of links and routers) taken by
      forward and reverse packet flow may be different.

   o  Many routers process the "regular" headers in IP packets more
      efficiently than they process the header information in IP
      options.  This suggests keeping congestion experienced information
      in the regular headers of an IP packet.

   o  A specific DiffServ service class would be implemented exclusively
      for Real-time traffic flows from ECN-capable end points. The
      assumption is that signaling protocol (SIP, H.323, MGCP, H.248,
      RSVP, etc.) will be used to determine if end points are capable of
      understanding ECN bit marking and are willing to cooperate in
      congestion control.

   o  Metering and marking of ECN bits as defined herein is performed on
      flows that are mapped in to this service class and is performed
      only on selected router links in the network where congestion is
      likely to occur. Other traffic flows are not affected by this
      function. Routers that do not support this function, forward
      packets without modifying bit 6 and 7 in DS Field of IP header.


3. Congestion Detection for Real-Time Traffic

   Real-time traffic generated by applications such as voice, video
   conferencing, multimedia streaming have different performance
   requirements and traffic characteristics when compared with so called
   data applications that use TCP, hence in this section we describe a
   different method for detecting congestion for real-time traffic.
   Real-time traffic is generally non-bursty and inelastic and have
   end-to-end performance requirements that require the network to give
   it the lowest possible delay and variation in delay (jitter). Where
   as data applications that use TCP are elastic and generally uses some
   form of Active Queue Management (AQM) for detecting that congestion
   level has been reached when queue length exceeds a threshold of
   certain size (many packets queued). Because of the characteristic of
   real-time traffic, ideally, the service class (or queue) that is used
   for forwarding real-time traffic should be engineered so that less
   than one packet is queued on average. Hence AQM can not be used for
   real-time traffic congestion detection. For real-time traffic, we
   propose that flow metering be used to measure the aggregate flow rate



Babiarz & Chan           Expires August 5, 2004                 [Page 4]


Internet-Draft                  Document                   February 2004


   and generate a policy that when the flow rate exceeds a configured
   rate, one of the ECN bits in the DS field of the IP header is set.
   This policy is similar to policing currently being performed at
   network edges, however the difference here is that instead of
   dropping packets when configured rate is exceeded, we set one of the
   ECN bits.

4. Explicit Congestion Notification for Real-Time Traffic

   This document specifies that the Internet provide a congestion
   indication for incipient congestion and where the notification is
   through marking packets rather than dropping them. This uses an ECN
   field in the IP header with two bits, making four ECN codepoints,
   '00' to '11'. Figure 1 defines the use and meaning of the ECN
   codepoints as it applies to real-time flows defined in this document.
   It should be noted that the definition and naming of ECN codepoints
   as defined in RFC 3168 does not apply when used for controlling
   real-time UDP based flows as RFC 3168 specifically only address ECN
   usage of elastic TCP flows. However, both methods RFC 3168 for TCP
   traffic and as document herein for real-time traffic can co-exist in
   the network. The premise is that these traffic types will be
   separated using Differentiated Services into two or more service
   classes with different polices for each traffic type. The mapping of
   ECN bits in figure 1 is defined so that routers in the path only need
   to set one of the ECN bits if the metering criteria has been
   exceeded. Other approaches could be used, but for simplicity we have
   chosen this one.

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

   * Bits 6 and 7 set to 0; represents not congested
   * Bit 7 set to 1; represents 1st level of congestion detected
   * Bit 6 set to 1; represents 2nd level of congestion detected

               Figure 1: DSCP and ECN Fields in IP Header

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

   o  Congestion detection MUST be performed using a real-time
      measurement method (e.g., flow metering).




Babiarz & Chan           Expires August 5, 2004                 [Page 5]


Internet-Draft                  Document                   February 2004


   o  As a minimum, one flow congestion detection mechanisms is REQUIRED
      to be associated with a link where measurement is performed.

   o  Bit 7 of the DS Field in the IP header MUST be set to 1, when the
      flow rate exceeds the configured rate "A" (i.e., the first level
      of congestion).

   o  Bit 6 of the DS Field in the IP header MUST be set to 1, when the
      flow rate exceeds the configured rate "B" (i.e., the second level
      of congestion).

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

   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 DS (Differentiated
   Services) Field RFC 2474 [4], RFC 2780 [5].  Bits 6 and 7 are listed
   in RFC 2474 as Currently Unused, and are specified in RFC 2780 as
   approved for experimental use for ECN. Finally, RFC 3168 standardizes
   the use of the ECN bits.

   Selected router in the network are configured to meter real-time
   traffic that is classified and marked via a DS codepoint as requiring
   congestion control, i.e., EF DSCP. The EF marked packet flows are
   segregate into a network defined service class where metering and
   marking of ECN bits may be performed on selected nodes in the
   network.

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 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 on to a link, therefore controlling loads to within the
   engineered limits is difficult. We propose that for real-time flows
   we use the metering and ECN marking method to address this issue.

   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.




Babiarz & Chan           Expires August 5, 2004                 [Page 6]


Internet-Draft                  Document                   February 2004


   Lets assume that the network is configured to mark real-time VoIP
   payload packet with EF DSCP and map this traffic into a DiffServ
   service class referred to as Telephony service class herein. Further
   we state that only EF marked traffic are mapped into the Telephony
   service class in this example. Mapping of real-time traffic marked
   with other DSCP 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 Probe Request packet to the calling party (Client A) and the
   calling party correspondingly sends back a Probe Response packet to
   the called party. Probe packets are marked with EF DSCP and are
   mapped into the same service class as real-time (ECN-capable) traffic
   flows.

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

   Upon receipt of 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,
   DiffServ style traffic conditioner, meter and ECN marker are used on
   selected routers in the network along the reverse path to measure the
   aggregated flow rate of EF marked packets. If flow rate of EF marked
   packets as measured by the meter is greater than rate "A" bit 7 in DS
   Field of IP header is set to 1 and the packet is forwarded as usual.
   On receipt of Response Probe packet, the called party could sends 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, admission control function will make
   a decision as to whether or not to continue with call setup and admit
   the new real-time flow.

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 those past uses of these two bits that
   pre-date ECN. The potential dangers of this lack of backwards



Babiarz & Chan           Expires August 5, 2004                 [Page 7]


Internet-Draft                  Document                   February 2004


   compatibility are discussed in RFC 3168 Section 22.

7. Security Considerations

   This document discusses detection of congestion for real-time traffic
   and describes a common policy configuration, for the use of a ECN bit
   marking and application of. 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
   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 an unauthenticated data stream using service that
   it is not intended to use, and such is the nature of the Internet.

8. IANA Considerations

   To be completed.

9. Acknowledgements

   The authors acknowledge a great many inputs, most notably from John
   Rutledge, Francois Audet, Tony MacDonald, Mary Barnes and Victor
   Firoiu.

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



Babiarz & Chan           Expires August 5, 2004                 [Page 8]


Internet-Draft                  Document                   February 2004


        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.


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@nortelnetworks.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@nortelnetworks.com

















Babiarz & Chan           Expires August 5, 2004                 [Page 9]


Internet-Draft                  Document                   February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Babiarz & Chan           Expires August 5, 2004                [Page 10]


Internet-Draft                  Document                   February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Babiarz & Chan           Expires August 5, 2004                [Page 11]