ConEx G. Karagiannis Internet-Draft University of Twente Intended status: Experimental D. Papadimitriou Expires: January 8, 2012 Alcatel-Lucent July 8, 2011 Non-TCP based Feedback for Congestion Exposure draft-karagiannis-conex-congestion-calculation-01 Abstract This document describes a solution used to feedback congestion information calculated at the receiver, back to the sender using non-TCP based protocols. The main advantage of this approach is that applications that are not using the TCP protocol as transport protocol could also apply the Conex concept to rely congestion experienced on the end-to-end path back into the network. 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 January, 2012. Karagiannis, Expires January 08, 2012 [Page 1] Internet-Draft Congestion exposure using non-TCP July 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2. Method of congestion exposure using non-TCP related feedback 2.1. Requirements for the Conex signal . . . . .. . . . . . . . 2.2. Codepoint Encoding . . . . . . . . . . . . . . . . . . . . 2.3. Conex Components . . . . . . . . . . . . . . . 2.3.1. Modified Senders . . . . . . . . . . . . . . . . . . . 2.3.2. Intermediate Conex Enabled Devices . . . . . . . . . 2.3.3. Modified Receivers . .. . . . . . . . . . . . . . . . 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 8. Comments Solicited 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 9.2. Informative References . . . . . . . . . . . . . . . . . . . Karagiannis, Expires January 08, 2012 [Page 2] Internet-Draft Congestion exposure using non-TCP July 2011 1. Introduction The ConEx working group is defining how IP packets will carry additional ConEx information. This document describes a solution used to feedback congestion information calculated at the receiver, back to the sender using non-TCP based protocols. In [draft-ietf-conex-abstract-mech-01] a method is described on (1) using ECN marks and packet drops to calculate the end-to-end path congestion at the receiver, (2) feedback this congestion information back to the sender using the TCP transport protocol, see also [draft- kuehlewind-conex-accurate-ecn-00] (3) relaying the congestion that has been experienced on the end-to-end path back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path. This draft specifies a solution used to feedback congestion information calculated at the receiver, back to the sender using non- TCP based protocols, instead of using the TCP transport protocol. The main advantage of this approach is that applications that are not using the TCP protocol as transport protocol could also apply the Conex concept to rely congestion experienced on the end-to-end path back into the network. This solution uses three main steps: (1) using ECN marks and packet drops to calculate the end-to-end path congestion at the receiver, (2) feedbacking congestion information calculated at the receiver, back to the sender by using non-TCP based protocols, for example DCCP (Datagram Congestion Control Protocol)(3) relaying the congestion that has been experienced on the end-to-end path back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, (identical to the same step specified in [draft-ietf-conex-abstract-mech-01]). 1.1 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 RFC 2119 [RFC2119]. The terminology specified in [draft-ietf-conex- abstract-mech-01] and [draft-ietf-conex-concepts-uses-01], [RFC5348] applies also for this document. Karagiannis, Expires January 08, 2012 [Page 3] Internet-Draft Congestion exposure using non-TCP July 2011 2. Method of using non-TCP related feedback for congestion exposure This document provides a method, see Figure 1, on (1) using ECN marks and packet drops to calculate the end-to-end path loss event rate at the receiver, which is identical to the one specified in [draft-ietf- conex-abstract-mech-01]), (2) feedbacking congestion information calculated at the receiver, back to the sender by using non-TCP based protocols, for example DCCP [RFC4340], [RFC5622], [RFC4342], (3) relaying the congestion that has been experienced on the end-to-end path back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, which identical to the one specified in [draft-ietf-conex- abstract-mech-01]). +---------+ +---------+ |Transport| +-----------+ |Transport| | Sender |>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver| | | | Network |>-Congestion-Signal->|---. | | | | Device | | | | | | +-----------+ | | | | | | | | | |<==Feedback=Path==============================<| | | | ,---|<-- returned Congestion Signal---------------<|<--' | | V | | | ||-------|| | | ||Congest|| | | ||rate || +-----------+ |Transport| ||calcul.||>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver| || |->(new)Conex->| Network |-(new)Conex signal)->| | |+-------+| | Device | (carried in data | | | | +-----------+ packet headers) | | +---------+ +---------+ Figure 1: Overview ConEx architecture, based on [draft-ietf-conex-abstract-mech-01] During the first step used by this method the end-to-end path loss event rate at the receiver is calculated using ECN marks and packet drops. This loss event rate can be calculated using different algorithms. As example we mention the use of loss event rate calculation specified in [RFC5348] (in combination with [RFC4342]) or [RFC4828] (in combination with [RFC5622]). For a normative specification of the loss event rate see (Section 5 of) [RFC5348] and [RFC4828]. Karagiannis, Expires January 08, 2012 [Page 4] Internet-Draft Congestion exposure using non-TCP July 2011 During the second step used by this method the receiver sends the calculated congestion rate to the sender using a non-TCP transport protocol. For example, if the non-TCP transport protocol is DCCP then this step can be realized by the specification given in [RFC5622] or [RFC4342]. In this case the receiver reports in DCCP-Ack packets, among others, also the number of loss event rate by using the Loss event rate option described in Section 8.5 of [RFC4342]. During the third step the congestion rate at the sender side needs to be calculated from the received congestion information carried by the feedback protocol. The description of how this congestion rate is calculated is out of the scope of this I-D. After that the congestion rate is calculated, an identical procedure is used as the one specified in [draft-ietf-conex-abstract-mech-01] to encode the Congestion exposure signals and to relay them back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, {More details will be included in a next version of this draft.} 2.1. Requirements for the ConEx Signal The following requirements apply to the Conex exposure signal, which are in line with most of the requirements presented in [draft-ietf-conex-abstract-mech-01]: o) The ConEx Signal SHOULD be visible to internetwork layer devices along the entire path from the transport sender to the transport receiver. o) The ConEx Signal SHOULD be useful under only partial deployment. o) The ConEx Signal SHOULD be timely. o) The ConEx Signal SHOULD be accurate (i.e., such that the signaled congestion is represented accurately). 2.2. Codepoint Encoding An identical encoding is used as the one specified in [draft-ietf- conex-abstract-mech-01]. 2.3. Conex Components The same Conex enabled devices can be used as the ones specified in [draft-ietf-conex-abstract-mech-01]. Karagiannis, Expires January 08, 2012 [Page 5] Internet-Draft Congestion exposure using non-TCP July 2011 2.3.1 Modified Senders The senders SHOULD support the protocol that is carrying the congestion information from the receiver to the sender. Moreover, the sender should implement an algorithm that can use the feedback congestion information to calculate the congestion rate at the sender. As example, if DCCP in combination with the TCP-Friendly Rate Control (TFRC) is used, then the solutions specified in e.g., [RFC5348] (in combination with [RFC4342]) or [RFC4828] (in combination with [RFC5622]) SHOULD be supported. In addition, the sender MUST be able to encode the calculated congestion rate at the sender into Conex Exposure Signals. This latter procedure is the same as the same procedure used by [draft- ietf-conex-abstract-mech-01]. 2.3.2 Intermediate Conex Enabled Devices The same intermediate Conex enabled devices could be used as the intermediate Conex enabled devices specified in [draft-ietf-conex- abstract-mech-01], e.g., Policer and Audit. 2.3.3 Modified Receivers The receiver SHOULD be able to calculate the congestion rate at the receiver, which needs to be forwarded at the sender. Moreover, the receivers should be able to support the same transport protocol supported by the sender used to feedback the calculated congestion information from the receiver to the sender. As example, if DCCP in combination with the TCP-Friendly Rate Control (TFRC) is used then the solutions specified in e.g., [RFC5348] (in combination with [RFC4342]) or [RFC4828] (in combination with [RFC5622]) SHOULD be applied. {More details on will be provided in a next version of this draft} 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations The security considerations described in [draft-ietf-conex-abstract-mech-01] apply also for this document. Karagiannis, Expires January 08, 2012 [Page 6] Internet-Draft Congestion exposure using non-TCP July 2011 6. Conclusions {to be done} 7. Acknowledgements We thank Richard Scheffenegger and Bob Briscoe for feedback on this document. 8. Comments Solicited Comments and questions are encouraged and very welcome. They can be addressed to the IETF Congestion Exposure (ConEx) working group mailing list , and/or to the authors. 9. References [draft-ietf-conex-abstract-mech-01] M. Mathis, B. Briscoe, "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", draft-ietf- conex-abstract-mech-01, (work in progress), March 2011. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [draft-ietf-conex-concepts-uses-01] T. Moncaster, J. Leslie, B. Briscoe, R. Woundy, D. McDysan, "ConEx Concepts and Use Cases", draft- ietf-conex-concepts-uses-01, Internet draft, (Work in progress), March 2011. Karagiannis, Expires January 08, 2012 [Page 7] Internet-Draft Congestion exposure using non-TCP July 2011 [draft-kuehlewind-conex-accurate-ecn-00] M. Kuehlewind, R. Scheffenegger, "Accurate ECN Feedback in TCP", draft-kuehlewind- conex-accurate-ecn-00, Internet draft (work in progress), July 2011. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP- Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007. [RFC5348] S. Floyd, M. Handley, J. Padhye, J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. [RFC5622] S. Floyd, E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, August 2009. Karagiannis, Expires January 08, 2012 [Page 8] Internet-Draft Congestion exposure using non-TCP July 2011 Authors' Addresses Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: g.karagiannis@ewi.utwente.nl Dimitri Papadimitriou (editor) Alcatel-Lucent Copernicuslaan, 50 2018 Antwerpen, Belgium Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.com Karagiannis, Expires January 08, 2012 [Page 9]