TSVWG J. Babiarz Internet-Draft K. Chan Expires: January 16, 2005 V. Firoiu Nortel Networks July 18, 2004 Congestion Notification Process for Real-Time Traffic draft-babiarz-tsvwg-rtecn-01 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 January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo specifies the usage of Explicit Congestion Notifications (ECN) markings for real-time flows that use UDP, such as voice, video conferencing and multimedia streaming. This memo tries to reuse as much of RFC 3168, "The Addition of Explicit Congestion Notification to IP", as possible. However, we found it necessary to introduce new ECN semantics for real-time UDP flows. For real-time UDP flows, this Babiarz, et al. Expires January 16, 2005 [Page 1] Internet-Draft Document July 2004 memo describes how the network performs ECN marking 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 purpose, 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 . . . . . . . . . . . . . . . . . . 3 2. Assumptions and General Principles . . . . . . . . . . . . . . 4 3. Congestion Detection for Real-Time Traffic . . . . . . . . . . 5 4. Explicit Congestion Notification for Real-Time Traffic . . . . 6 5. Example of ECN usage for Admission Control . . . . . . . . . . 9 6. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Babiarz, et al. Expires January 16, 2005 [Page 2] Internet-Draft Document July 2004 1. Introduction This memo 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 IP, focusing on TCP flows, including ECN's use of two bits in the IP header. This memo tries to reuse as much of RFC 3168, "The Addition of Explicit Congestion Notification to IP", as possible. We take the same concepts but apply them to real-time UDP flows. However, we found it necessary to introduce a new ECN semantics that can provide two levels of congestion experienced indication for real-time inelastic UDP flows. There are applications or services that need to provide different treatment at application level based on importance of the session for given level of congestion experienced. As an example, higher importance flows may need to get access to network over regular traffic. In addition this memo specify the requirements for network nodes that are configured to provide ECN-capability. Defined in this memo are the functions that need to be performed in the network for real-time flows, specifically congestion detection through the use of flow measurement and marking of ECN bits in the IP header of real-time packets. Since real-time flows like voice and video conferencing are very delay sensitive, a different method than what is specified in RFC 3168 for determining level of congestion needs to be used. Furthermore, we redefine a new ECN semantics for bit 6 and 7 in the DS Field of the IP header to be used for real-time UDP flows compared to what is defined in RFC 3168 for TCP flows. The proposal is to use ECN as a method to notify to the application that there is a bandwidth constraint or congestion along the path in the network. Based on this information, the application may take action to reduce its sending rate in what ever means is appropriate, stop sending packets, or reduce its rate or not admit any new flows if the path is congested. The reaction or decision taken by the application to the ECN marking is not specified in this memo as it will depend on the application. It is left up to the 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 memos will be produced to explain the detailed usage of real-time ECN mechanism. For illustration purpose, a high level example of a procedure that may be used for admission of VoIP flows based on measured congestion level in the network is provided. 1.1 Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Babiarz, et al. Expires January 16, 2005 [Page 3] Internet-Draft Document July 2004 "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 the development of 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 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 routers. o Asymmetric routing is likely to be a normal occurrence within IP networks. That is the path (sequence of links and routers) taken by forward and reverse packet flows may be different. o Many routers 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 points. Different DiffServ service class is used to identify real-time flows that are ECN-capable and hence the ECT(0) or ECT(1) states 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 points are capable of understanding ECN bit marking and thus, are willing to participate in congestion control. o Further, it is desirable that traffic flows from ECN-capable and non-ECN-capable end points are not aggregated into the same DiffServ service class. Aggregating 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 Babiarz, et al. Expires January 16, 2005 [Page 4] Internet-Draft Document July 2004 real-time ECN capable traffic, the ECT(0) and ECT(1) states defined inRFC 3168 [6] are not used in the network. This is reasonable as the proposed mechanism is meant for an engineered network that is DiffServ capable as compared to the best-effort nature of the Internet at-large. o Flow measurement 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 the IP header. o ECN procedure as defined in RFC 3168 [6] may be applied to DiffServ service class(es) in the IP network that are intended for applications that use TCP. Both methods may co-exist in the network, but in different DiffServ service classes. 3. Congestion Detection for Real-Time Traffic Real-time traffic generated by applications such as voice, video conferencing, multimedia streaming have different performance requirements when compared with non-real-time applications that use 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 routers in their path through a real-time service class such as one based on the EF PHB treatment. This treatment can be provided only when the real-time service class is under-loaded (i.e., when the aggregate of input traffic never exceeds the class' capacity, and thus no congestion condition occurs). One way to ensure the under-loaded condition of a service class is through resource reservation and admission control: a (centralized or distributed) database maintains a record of available 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 under-loaded condition is maintained. 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. Babiarz, et al. Expires January 16, 2005 [Page 5] Internet-Draft Document July 2004 An alternative method for ensuring sufficient forwarding resources (bandwidth) is through flow admission control based on local traffic measurement. In this scheme, a continuous process at selected link(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 4 is then used by the application to select the action that will be taken by the application that controls the service. The action could be to admit or not admit a new flow into that real-time service class in the network, or have the sending rate of ECN marked flows reduced, stopped or terminated a flow thereby reducing level of congestion. It is desirable that the measurement process indicate congestion before any significant packet accumulates in the queue such that no significant queuing delay is added to the flows' end-to-end delay. One way to achieve this is through monitoring the aggregate rate of the specified real-time service class and to indicate congestion when a certain threshold is exceeded. 4. Explicit Congestion Notification for Real-Time Traffic This memo specifies a method for an IP network to provide congestion indication for incipient of congestion and where notification is accomplished through marking packets rather than dropping them. The marking is done through the use of the two ECN bits in the IP header. <----------- DS FIELD ----------------> 0 1 2 3 4 5 6 7 ----+----+----+----+----+----+----+---- | DSCP FIELD |ECN FIELD| ----+----+----+----+----+----+----+---- DSCP: Differentiated Services Codepoint ECN: Explicit Congestion Notification Figure 1: DSCP 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 as Currently Unused, and are specified in RFC 2780 as approved for experimental use for ECN. Finally, RFC 3168 [6] standardizes the use of the ECN bits. With this memo, we propose an additional usage of the ECN bits for indicating congestion for real-time inelastic UDP packet flows in Babiarz, et al. Expires January 16, 2005 [Page 6] Internet-Draft Document July 2004 DiffServ capable networks. The selected routers in the network are configured to measure real-time traffic that is classified and marked via a DS codepoint as requiring congestion control, i.e., EF DSCP. These flows are segregated into a network defined service class where flow metering and marking of ECN bits may be performed on selected nodes in the network. We would like to keep network element processing to be simple, without keeping states. Hence the network only perform the ECN bit markings without any state maintenance. Whereas the application may care about the semantics of the total ECN field as a whole. Figure 2 defines the new ECN semantics as they apply to real-time inelastic UDP flows. It should be noted that the definition and naming of ECN codepoints for real-time UDP flows is different than what is defined in RFC 3168. RFC 3168 only addressed ECN usage for elastic TCP flows. The ECN-Capable Transport (ECT) codepoints '10' (ECT(0)) and '01' (ECT(1)) defined in RFC 3168 that are set by the data sender to indicate that the end points of the transport are ECN-Capable are not used for real-time UDP applications, as only the real-time ECN capable traffic will be placed in a specific service class to receive the real-time ECN treatment in the network. The targeted real-time UDP applications have a requirement that the network provide transport with very low packet loss. Mixing flows from ECN-capable and non-ECN-capable end points into the same service class and using ECT codepoint for providing treatment differentiation in routers would require that every router in the network to be ECN-capable. We prefer to take a gradual or incremental approach for deployment of ECN-capable routers in the network and use DiffServ architecture for flow differentiation. Therefore, this new functionality needs only to be deployed in selected nodes. 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 for TCP traffic and as documented herein for real-time UDP traffic can co-exist in the network, using independent DiffServ service classes. The mapping of ECN bits for real-time UDP flows is defined so that routers in the path only need to set one of the ECN bits if the flow measurement criteria has been exceeded. Other approaches could be used, but for simplicity we have chosen this one. Action Performed in Router: o Bit 7 set to 1 to indicate 1st level of congestion detected o Bit 6 set to 1 to indicate 2nd level of congestion detected Nodes that are configured to support congestion notification for Babiarz, et al. Expires January 16, 2005 [Page 7] Internet-Draft Document July 2004 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). o As a minimum, one flow congestion detection mechanism is REQUIRED to be associated with a link where congestion 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 Measured rate "B" MUST be greater than rate "A". Routers in the IP network MAY be configured to support one or two congestion detection levels. Some real-time applications or services need the indication of two levels of congestion experienced, CE(0) and CE(1), for first level and second level congestion experienced respectively. Therefore we have selected the following ECN semantics as interpreted by applications for real-time UDP traffic. ECN States as Interpreted by Application: Bits 6 and 7 values 0 0 Not-CE - Congestion Not Experienced 0 1 CE(0) - Congestion Experienced only at 1st level 1 0 CE(1) - Congestion Experienced only at 2nd level 1 1 CE(2) - Congestion Experienced at 1st and 2nd level Figure 2: ECN Semantics for Real-Time UDP Flows Specific applications may take different action(s) in response to congestion being experienced in the network. Depending on the application, one possible outcome maybe for the application to stop initiating new real-time UDP flows at the 1st level of congestion and if the offered load in the selected service class where this real-time ECN marking is performed reaches 2nd level of congestion the application selectively stops sending packets on some flows. Most likely, different applications will take various independent actions. The various independent actions taken by the applications are out of scope of this memo. Babiarz, et al. Expires January 16, 2005 [Page 8] Internet-Draft Document July 2004 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. To address this issue, we propose that for real-time flows we use the metering and ECN marking method defined in this memo. 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 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 flows 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, Babiarz, et al. Expires January 16, 2005 [Page 9] Internet-Draft Document July 2004 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 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 Section 22. 7. 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 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. Babiarz, et al. Expires January 16, 2005 [Page 10] Internet-Draft Document July 2004 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, Greg Thor, Nabil Bitar, and Hadriel Kaplan. 10 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. 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 Babiarz, et al. Expires January 16, 2005 [Page 11] Internet-Draft Document July 2004 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 Victor Firoiu Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US Phone: +1-978-288-4354 Fax: +1-978-288-4690 EMail: vfiroiu@nortelnetworks.com Babiarz, et al. Expires January 16, 2005 [Page 12] Internet-Draft Document July 2004 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 (2004). 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 January 16, 2005 [Page 13]