Network Working Group Z. Sarker Internet-Draft I. Johansson Intended status: Standards Track Ericsson AB Expires: May 24, 2009 November 20, 2008 Usecases and Benefits of end to end ECN support in PCN Domains draft-sarker-pcn-ecn-pcn-usecases-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that 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 May 24, 2009. Abstract This document provides an informative overview of possible use cases where ECN marking can be used for inelastic traffic. It outlines benefits of preserving the ECN support in a PCN domain. As ECN provides with a simple mechanism for network nodes to inform the end points about possible upcoming congestion and resulting packet losses and delay increase, the scheme can be useful for adaptive real-time media applications, thus enabling them to adjust the transmission rate to avoid quality degradation due to congestion. By showing the benefits of ECN this memo asks the working group to consider end to end ECN support in PCN domain. Sarker & Johansson Expires May 24, 2009 [Page 1] Internet-Draft End to end ECN in PCN Domain November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Real-time conversation . . . . . . . . . . . . . . . . . . 4 3.2. Semi real-time/content based streaming . . . . . . . . . . 5 3.3. Online multiplayer gaming network control . . . . . . . . 5 3.4. 3GPP scenario/issues (cellular network) . . . . . . . . . 5 3.5. Traffic engineering and prioritized flows . . . . . . . . 7 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Downgrading to DF class . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Securitiy Considerations . . . . . . . . . . . . . . . . . . . 9 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Informative References . . . . . . . . . . . . . . . . . . 10 10.2. Normative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Sarker & Johansson Expires May 24, 2009 [Page 2] Internet-Draft End to end ECN in PCN Domain November 2008 1. Introduction ECN (Explicit Congestion Notification) described in [RFC3168] provides an alternative behavior for the routers to react on congestion. With the ECN concept, ECN capable routers with active queue management can detect congestion before the queues overflow and mark the packets in the IP header to indicate congestion to the end points of communication. The end points are expected to react on the congestion indication and take necessary actions to avoid the packet loss. ECN is an end to end schema that may be used with any traffic class that is using IP. The ECN mechanism needs transport layer support for signaling and [RFC3168] defines a mechanism that can be used with TCP. A recent study [ZVA] has shown that ECN can also be beneficial for other transport protocols such as UDP. Additionally DCCP [RFC4340] and SCTP [RFC4960] has specific support for ECN. The PCN (Pre-Congestion Notification) [I-D.ietf-pcn-architecture] concept proposes an "architecture for flow admission and termination based on aggregated (pre-) congestion information in order to protect the quality of service" in a PCN domain. PCN aims to work within a diffserv domain and current document defines an architecture for established inelastic flows within that diffserv domain. If a catastrophic failure occurs such that the available bandwidth within the PCN domain is reduced, the flow termination mechanism can be used to restrict the damage inflicted by the failing node or link. There has been discussion going on within the IETF PCN working group to use the DSCP and/or ECN field to encode the PCN marking in the IP header. Even though the current RFC [RFC3168] only defines the ECN mechanism for elastic traffic, ECN can still be useful for congestion management for inelastic traffic. The main goal of this memo is to highlight use cases where ECN can be useful for inelastic traffic classes, thus reconsidering the encoding of PCN flow marking in ECN fields of the IP header. This document neither suggests any alternative for PCN marking nor defines any fields for such marking. 2. Glossary A list of the terms used in this document. ECN - Explicit Congestion Notification PCN - (Pre-) Congestion Notification QoS - Quality of Service Sarker & Johansson Expires May 24, 2009 [Page 3] Internet-Draft End to end ECN in PCN Domain November 2008 MBR - Maximum Bit Rate GBR - Guaranteed Bit Rate eNB - Evolved Node B HSPA - High Speed Packet Access RAB - Radio Access Bearer RAN - Radio Access Network LTE - (UTRA & UTRAN) Long Term Evolution HD - High Definition 3. Use cases This section lists some use cases where support for end to end ECN over PCN domains is beneficial. 3.1. Real-time conversation High quality real-time conversational services require high bitrate and short delay. This impose high requirements on transport channels as maintaining higher bitrate and shorter delay is often expensive especially in cellular networks. For this reason, media codecs are carefully selected for real-time conversational services to ensure that high quality media can be delivered even at low bitrate and with low delay. Real-time conversational media can include text, speech and video. Video transmission requires more bandwidth than other media. In a low bitrate video stream, which usually has low intra refresh rate, packet losses can cause significant quality degradation. Similar issues apply for speech. To maintain sufficiently high quality in a real-time conversational session, the transport channels need to be close to congestion-free to prevent packet losses and to provide with short delay. In these cases ECN can play a vital role for real time traffic by reducing the likelihood of packet losses by allowing the end points to adapt to the load in the network. For real time traffic, RTP over UDP is used. Profiles like RTP/AVPF, which allows for immediate reporting of events, can be useful to use together with ECN for adaptation signaling for real time traffic. Sarker & Johansson Expires May 24, 2009 [Page 4] Internet-Draft End to end ECN in PCN Domain November 2008 3.2. Semi real-time/content based streaming Semi real-time services like streaming, a.k.a content services are services like Video on Demand (VoD), IPTV, Mobile TV etc. The user subscribes to the content provided by content providers and expects to receive high quality (e.g HD quality) media. These types of services use client/server architectures and can allow some delay in the content delivery. As users expect to receive high quality media, the need to avoid packet losses becomes significant. Here, ECN capabilities can be used to monitor network conditions and make possible to adjust the transmission rate to avoid packet losses in the network. This can ensure uninterrupted high quality content to the viewers/users. ECN could also trigger the use of application or transport layer FEC to compensate for downstream packet drop. FEC packets typically add delay and more load to the end-to-end flows, but this can be compensated for by decreasing transmission rate and constraining its operation to near-realtime streams. 3.3. Online multiplayer gaming network control Due to their timely delivery nature, UDP is the preferred transport protocol for online multi player gaming. Online multi player gaming generally uses Client/Server architecture where the server is responsible for game rules, environment change and input processing and the client is usually the player's computer or gaming device. Client and server communicate with each other using high packet rates (30-40 packets per second). As the network bandwidth is limited, keeping the latency low is a big and crucial factor in multi player online gaming. Even an extra delay in the range of milliseconds can make it difficult to hit other players or interact with moving or fast running objects. As packet losses can cause loss of information about user input, world change etc. dropping packets during congestion periods may not be a good idea for these kind of services. Rather, marking the packets as congestion experienced (CE) and letting the server and client to adjust their sending rate and even packet size is more efficient. An end to end scheme like ECN can be applicable here especially since it can be proactive and fast. 3.4. 3GPP scenario/issues (cellular network) A cellular environment is more complicated than a wireline ditto since it seeks to provide services in the context of variable available bandwidth, location dependencies, wireless link errors and user mobilities at different speeds. Here, the user may reach the Sarker & Johansson Expires May 24, 2009 [Page 5] Internet-Draft End to end ECN in PCN Domain November 2008 cell edge which may lead to a significant amount of retransmissions to deliver the data from the base station to the destination and vice versa. These network links or radio links will often act as a bottleneck for the rest of the network which will eventually lead to excess delays or packet drops. An efficient retransmission or link adaptation mechanism can reduce the packet loss probability but there will still be some packet loss and delay variations. Moreover, with increased cell load or handover to a congested cell, transport network level congestion will become even worse. Thus ensuring the maximum network utilization and providing constant level of QoS is a big challenge. Additionally, future communication applications and systems will impose higher QoS requirements than that of the current state of the art. Especially, in next generation cellular systems like LTE, call blocking and forced call termination needs to be kept at an absolute minimum. Under these circumstances, adaptive applications or services can play a vital role to provide better quality of experience. The QoS schema in LTE defines two rate specific QoS attributes; Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR). GBR denotes the bit rate on which the admission decision is based while MBR denotes the maximum bit rate which the user can utilize if available. A granted GBR confirms that the network admits one call and has reserved enough resources to provide at least the bit rate specified in GBR. The call can then use bit rates up to the MBR. GBR and MBR can be used by the adaptive application for a better utilization of resources and improved QoS. Rate adaptive codec utilization is not new within 3GPP nor are the RAB attributes GBR and MBR. Previously however, it has been deemed unsuitable to utilize the area above GBR but below MBR since that area is treated as pure best effort traffic in the mobile network. Hence, any RAB attribute setting such as targeted packet loss rate is only applicable to the GBR, not the area above GBR. In other words, the traffic going above GBR can at any moment experience severe packet losses. Loss rates high enough to render e.g. a conversational video media stream useless. The basic requirement to start to utilize the area above GBR is that the application either has some idea about the amount of losses it can expect or that it can receive some warning that congestion is imminent and that the probability of congestion related losses is high. The most future proof solution in this context is a network originated pre-warning about forthcoming congestion related packet losses. The new RAN architecture proposed for 3GPP release 8 has made it possible to access the IP layer all the way down into the LTE base Sarker & Johansson Expires May 24, 2009 [Page 6] Internet-Draft End to end ECN in PCN Domain November 2008 station, the eNB. This makes it possible to utilize IP layer functionality to signal messages from the RAN to the UE from the node in the network where the traffic bottleneck is most likely to occur. Using the IP layer to signal this kind of information also makes the schema more future proof and access technology transparent. Looking at the standards track RFCs available in IETF, the option of applying ECN to achieve this kind of pre-warning seems appropriate. Signaling in the IP layer can also be useful in other scenarios where a combination of wired and wireless interfaces is available. For example, let us consider an HSPA micro/femto basestation at home which is connected to some radio basestation. The base station can be connected to another basestation via the air interface. In this particular case nothing will be visible above the IP header at these basestations but they will still be possible to signal congestion notification to the end points via the IP header. Thus, a real need of an end to end early congestion notification mechanism like ECN can be seen for real time multimedia applications. If ECN to be used in the described scenarios then ECN marking need to be protected all the way to the endpoints. PCN domains will reside in between the end points. Any modification to ECN bits within the PCN domain without restoring them will cause definite harm to the negotiated adaptaion procedure in the applications. 3.5. Traffic engineering and prioritized flows The term prioritized traffic has been typically associated with flows that are exempt or least likely to experience packet loss during times of congestion in relation to other flows transiting the same node. Prioritized flows are either explicitly labeled in one or more layers, or they are identified by an external signaling protocol like RSVP. Given the underlying goal of ECN to reduce the load of a flow, prioritization would initially seem counter productive from both an end-to-end and local PCN perspective. However, recent work within the IETF on the subject of prioritization presents scenarios where labels or installed state via signaling can trigger specific traffic engineering techniques beneficial to PCN domains. [RFC4190] presents the case where different virtual paths may be used for prioritized traffic, thereby potentially increasing the probability of that traffic being forwarded to its destination as well as decreasing load of other flows along the previously shared path. In the case of [I-D.ietf-tsvwg-emergency-rsvp] and its Priority By-Pass Model, signaling can be used to free up resources set aside for certain types of flows. In this latter example, Sarker & Johansson Expires May 24, 2009 [Page 7] Internet-Draft End to end ECN in PCN Domain November 2008 probability is increased for certain flows to be forwarded without additional load or disruptive impact incurred on other non- prioritized flows. Within the context of ECN and PCN domains, ECN can act as an end-to- end trigger of both prioritization and subsequent traffic engineering on an as-needed basis instead of through the entire lifespan of flows considered to be important. This as-needed traffic engineering capability can be symbiotic in a PCN domain attempting to address disruptive conditions (e.g., flash crowds). 4. Benefits The benefits from considering end to end support for ECN in a PCN domain can be summarized as follows: o By signaling ECN in the IP header, adaptation can be agnostic to the underlying network technology. o End to end congestion signaling will allow adaptive applications to adjust their sending rate, packet size etc. during congestion period in a proactive, preventive way, which will eventually keep the network in a more stable state o In 3GPP cellular networks no control plane overhead is associated with ECN since it is based on user plane packet marking Additionally, when transport support for ECN signaling is available for inelastic traffic and if end points negotiate to use ECN, lack of support for end to end ECN in a PCN domain may cause malfunction in the applications. 5. Downgrading to DF class There has been some discussion in the PCN working group to downgrade ECN capable EF class traffic to DF class (best effort). This means that if the PCN ingress node captures any packet in with the ECN-CE mark set it will simply modify the DSCP and downgrade that packet to DF class. The EF class traffic certainly requires some QoS support from transport channels as they are inelastic by nature. Depending on location of PCN domain the downgraded packet might need to traverse the rest of its transmission path as DF class traffic. In this case, the downside of doing such kind of downgrading is listed below. Sarker & Johansson Expires May 24, 2009 [Page 8] Internet-Draft End to end ECN in PCN Domain November 2008 o Downgraded traffic flow will not get any QoS in the core network which might cause longer delay, more jitter and increased packet loss. o Downgraded traffic has to compete with TCP and other proprietary non QoS access traffic. o Downgraded traffic may also affect TCP performance as TCP by its nature will be generous to inelastic traffic during congestion. Thus TCP can suffer from bandwidth scarceness. 6. IANA Considerations This memo includes no request to IANA. 7. Securitiy Considerations This memo does not arise any new security issues. This document is based on [RFC3168] and security considerations discussed in [RFC3168] are also applicable while treating this document. 8. Conclusions In this draft the use cases where ECN can be beneficial for EF class traffic have been discussed. The discussion reveals some benefits of supporting ECN capabilities in PCN domain. Using an end to end scheme like ECN, adaptive real time applications will be able to provide high quality services even in hostile network conditions. ECN can help these applications to reduce packet loss and delay. As the current PCN architecture is not intended to extend down towards the end points we believe keeping the ECN support in PCN domain will make the PCN concept stronger. 9. Acknowledgements This document has been benefited from discussions with many people. The authors would like to thank all the people who gave feedback on this document especially Daniel Enstrom, Magnus Westerlund, Reiner Ludwig, Lars Westberg and Stefan Hakansson for their detailed review and comments. Thanks also to Ken Carlberg for suggested additions. 10. References Sarker & Johansson Expires May 24, 2009 [Page 9] Internet-Draft End to end ECN in PCN Domain November 2008 10.1. Informative References [I-D.ietf-tsvwg-emergency-rsvp] Faucheur, F., Polk, J., and K. Carlberg, "Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in progress), October 2008. [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [ZVA] Sarker, S., ""Adaptive Real Time Video over LTE", MS thesis, Lulea University of Technology, Sweden,November,2007. http://epubl.ltu.se/1653-0187/2007/064/index-en.html". 10.2. Normative References [I-D.ietf-pcn-architecture] Eardley, P., "Pre-Congestion Notification Architecture", draft-ietf-pcn-architecture-03 (work in progress), February 2008. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. Authors' Addresses Zaheduzzaman Sarker Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN Phone: +46 10 7173743 Email: Zaheduzzaman.Sarker@ericsson.com Sarker & Johansson Expires May 24, 2009 [Page 10] Internet-Draft End to end ECN in PCN Domain November 2008 Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN Phone: +46 73 0783289 Email: ingemar.s.johansson@ericsson.com Sarker & Johansson Expires May 24, 2009 [Page 11] Internet-Draft End to end ECN in PCN Domain November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Sarker & Johansson Expires May 24, 2009 [Page 12]