conex Lei. zhu Internet-Draft Huawei Technologies Intended status: Informational September 30, 2010 Expires: April 3, 2011 Requirements of Localised Congestion Notification draft-lei-ecn-localised-congestion-notification-01 Abstract This document introduces analyzes of ECN(Explicit Congestion Notification)in case of congestion of local links. 3GPP adopts and specifies shared channel for multiple user equipments in a cell. Other last mile access systems (e.g. xDSL access and Frame Relay access) have to handle congestion since bandwidth multiplexing is most likely considered for reducing unnecessary cost. Therefore, congestion in access network is to inform user equipments in case of traffic congestion utilizing congestion notification concepts and similar mechanisms. Besides the argument on the congestions of access networks, this document is also to introduce the use case of Conex which might be useful for the potential Conex proposals to notify and address the congestion of wireless access network further. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 3, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. zhu Expires April 3, 2011 [Page 1] Internet-Draft Localised ECN September 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. zhu Expires April 3, 2011 [Page 2] Internet-Draft Localised ECN September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Access Congestion . . . . . . . . . . . . . . . . . . . . . 6 5.2. Generated Traffic from Network . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 zhu Expires April 3, 2011 [Page 3] Internet-Draft Localised ECN September 2010 1. Introduction ECN [RFC3168], a proposed standard document, defines the ECN field in the IP header, and specifies the semantics for the code points for the ECN field. These are all unicast protocols which negotiate the use of ECN during the initial connection establishment handshake (supporting incremental deployment, and checking if ECN marked packets pass all middleboxes on the path). Basically, ECN is an end to end solution involving endpoints and intermediate entities in the transport path. The ECN solution requires that terminals and intermediate nodes (e.g. router and firewall) in the path to support ECN functions. Otherwise, the whole solution does not fulfill the requirements to mechanisms of ECN. The ECN also updates the definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers with optional ECN fields. The ECN mechanism originally includes the associations with congestion control and avoidance algorithms of TCP [RFC0793]. The problem is that this end to end solution highly relies on the supports of intermediate node in the path. Since, there exist some middleboxes (firewalls, load balancers, or intrusion detection systems) in the Internet that either drop a TCP SYN packet configured to negotiate ECN, or respond with a RST. Besides the congestion appears in backbones of Tier 1 or Tier 2 service providers, the most of traffic congestion seem happen in access network due to a lot of reasons. For example, the ADSL multiplexer is likely to multiplex traffic, but multiplexer would not avoid congestion in particular periods (e.g. rush hour of transportation system). Another example is 3GPP LTE architecture which specifies shared logic channel in particular cell with very high capacity. However, even though terminals use low class traffic (e.g the traffic class only insure best effort service.), the capacity of the shared channel could be exhausted by applications which generates huge number of traffic. In general, some problems could happy or have appeared in network, all indicate that the congestion of access network is likely critical issue to usages of congestion notifications in next generation networks. Changes from previous drafts (to be removed by the RFC Editor): From -00 to -01: The revision 01 is to introduce some description of use case on the issues that the Conex proposal might be useful to notify congestion of wireless access network. The use case described in this document is also expected to be considered as an input of Conex mechanism discussion and to be address in future. zhu Expires April 3, 2011 [Page 4] Internet-Draft Localised ECN September 2010 Argument in "Introduction and problem statement" part of 00 version could be kept in 01 version. The definition and particular description of congestion issues of wireless access network might be supplied based on the draft-moncaster-conex-concepts-uses-01. Those supplements are expected to be adopting in proper working group document. The use case describing Conex usage of wireless access network is added in the document. A supplied use case describe needs to consider the congestion control for Conex proposal in case that traffic is generated from network. 2. Terminology 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 [RFC2119]. 3. Definition Access Congestion: Access Congestion is due to the multiplexing function of access network, and is the congestion situation of access network which link layer resource of access network is not sufficient to transport downstream or upstream data to the endpoints. Access Congestion would be located at network ingress and egress. Mobile broadband access networks may not use RED algorithm as the criteria to detect congestion. 4. Requirements In this section, the author tries to introduce requirements of localized ECN mechanism. The goals of localized ECN are: a. Provide a locolized congestion notification mechanism extending the scope of ECN solution to notify congestion only happened in access network; b. The localized ECN mechanism should support notification of congestion at access network in spite of intermediate supports in the whole path; zhu Expires April 3, 2011 [Page 5] Internet-Draft Localised ECN September 2010 c. The localized congestion notification mechanism should be compliant with the ECN solution, and support the back compatibility to ECN solution. Therefore, the concluded requirements are, the localized ECN mechanism: a. MUST be able to notify congestion of access network to the local senders which contributes to the uplink congestion. b. MUST be able to notify congestion of access network to the local receivers which receive data contributing to the downlink congestion. c. MUST be able to notify the uplink congestion and downlink congestion of access network to senders and receivers. 5. Use case 5.1. Access Congestion Access Congestion happens in the network ingress and egress. Access Congestion is mainly due to the access network transmission capacity of transmission in a specific period of time can not satisfy the transportation needs of upstream or downstream traffic. In addition to the existing fixed access network, e.g. the different types of last mile access approaches, including xDSL, optical access, more legacy TDM, ISDN access networks, it also includes mobile broadband access network. Especially for the mobile broadband access networks, at air interface, radio resource controllers need to execute scheduling or priority handling functions to enable the flow of different users and applications in the empty transmission, with the congestion detection and discovery mechanisms different from AQM mechanisms. The Conex mechanism is to reflect the measurement of the mobile broadband network as the network ingress or egress of the conex enabled network, and might require the supports of link layer of such network. The RLC layer retransmission by HARQ mechanism and timer in the data link layer of mobile broadband network ensure reliable data transmission services. From the implementation point of view, the access network entities, such as RNC (Radio Network Controller) may support the buffering mechanism which could be able to calculate the change in the length of the buffer entry and exit that can be estimated network congestion state. So, Conex is expected to marke congestion event according to ECN RFC3168 in addition to other provisions of the RED algorithm to obtain the parameters of traffic zhu Expires April 3, 2011 [Page 6] Internet-Draft Localised ECN September 2010 congestion. Mechanism in the Conex eventually hopes to influence the application of business data generated. 5.2. Generated Traffic from Network The reasons generating more traffic congestion in the networks are complicated. But, end users get content from the network in most cases. The endpoints have rare opportunities to send huge number of traffic in real network. For example, HTTP based applications, service data are sent from the original server. In other word, the content is transferred to the end points request the traffic. According to the ECN concepts, ECN parameter in IP packet header will be sent to receiver, while the ECT flag in the TCP ACK is sent to the sender. In the example of the HTTP based applications if the source can reduce the transmission of business data is a pretty well situation. On the other hand, Conex solution hopes controlling the amount of traffic generated in the state of network congestion through economic means. In these scenarios, existing ECN solution does not completely and surely satisfy, because traffic resulting in congestion indication is always transferred to the sender. In the real networks, operators are able to monitor data flow and a user, or subscription of the user, and associate them with policy control functions. If congestion is expected to be controlled by economic means, Conex mechanism can be used to further support to the above scenarios. 6. Security Considerations TBD 7. IANA Considerations There have been no IANA considerations so far in this document. 8. Acknowledgments TBD 9. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. zhu Expires April 3, 2011 [Page 7] Internet-Draft Localised ECN September 2010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. Author's Address Lei Zhu Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China Phone: +86-10-82836301 Email: Lei.zhu@huawei.com zhu Expires April 3, 2011 [Page 8]