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]