ConEx G. Karagiannis Internet-Draft University of Twente Intended status: Experimental D. Papadimitriou Expires: January 11, 2012 Alcatel-Lucent July 11, 2011 Non-TCP based Feedback for Congestion Exposure draft-karagiannis-conex-congestion-calculation-02 Abstract This document describes a procedure that allows receivers to compute the congestion from the received congestion information and to communicate this information 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 11, 2012. Karagiannis, Expires January 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 2. Method of congestion exposure using non-TCP related feedback 4 2.1. Congestion exposure method overview . . .. . . . . . . . 4 2.2. Requirements for the Conex signal . . . . .. . . . . . . 5 2.3. Codepoint Encoding . . . . . . . . . . . . . . . . . . . 6 2.4. Conex Components . . . . . . . . . . . . . . . . . . . 6 2.4.1. Modified Senders . . . . . . . . . . . . . . . . . 6 2.4.2. Intermediate Conex Enabled Devices . . . . . . . 6 2.4.3. Modified Receivers . .. . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . 8 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .8 8.1. Normative References . . . . . . . . . . . . . . . . . . .8 8.2. Informative References . . . . . . . . . . . . . . . . . .8 Karagiannis, Expires January 11, 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 procedure that allows receivers to compute the congestion from the received congestion information and to communicate this information 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. This procedure is used as part of sequence of operation where (1) the receiver using ECN marks and packet drops computes the end-to-end path loss event rate, (2) the receiver feed this end-to-end path loss event rate information back to the sender using a non-TCP transport protocol, such as the DCCP transport protocol [RFC4340] together with [RFC4342] or [RFC5622]. Subsequently, in (3) the sender computes the congestion at the sender, and (4) relays 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 Conex Enabled IP devices along the path. 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 11, 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) the sender computes the congestion at the sender, (4) 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 Conex Enabled 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->|---. (1) | | | | Device | | | | | | +-----------+ | | | | | | | | | |<==Feedback=Path==============================<| | | | ,---|<-- returned Congestion Signal---------------<|<--' | | V | (2) | | ||-------|| | | ||Congest|| | | || || +-----------+ |Transport| ||calcul.||>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver| || (3) |->(new)Conex->| Network |-(new)Conex signal)->| | |+-------+| (4) | Device | (carried in data | | | | +-----------+ packet headers) | | +---------+ +---------+ Figure 1: Overview ConEx architecture, based on [draft-ietf-conex-abstract-mech-01] 2.1. Congestion exposure method overview The following paragraphs described each of the steps of the proposed method: 1) In the first step, the end-to-end path loss event rate is calculated at the receiver using ECN marks and packet drops. This rate can be calculated using different algorithms. As example, the loss event rate calculation specified in [RFC5348] (in combination with [RFC4342]) or [RFC4828] (in combination with [RFC5622]) can be used for this purpose. For a normative specification of the loss event rate see Section 5 of [RFC5348] and [RFC4828]. Karagiannis, Expires January 11, 2012 [Page 4] Internet-Draft Congestion exposure using non-TCP July 2011 2) In the second step, the receiver sends this end-to-end path loss event rate information back to the sender using a non-TCP transport protocol, such as the DCCP transport protocol, see [RFC4340], [RFC5622] or [RFC4342]. In this case, the receiver reports using DCCP-Ack packets, among others, the number of loss event rate by using the Loss event rate option, described in Section 8.5 of [RFC4342]. 3) In the third step, the sender calculates the path congestion at the sender (to which the feedback is directed). The congestion at the sender is calculated using the congestion computed at the receiver, e.g., the loss event rate. This step can be realized using different algorithms, e.g., see [draft-ietf-conex-abstract-mech-01]). Moreover, in this step the congestion exposure signals can be encoded using the same method specified in [draft-ietf-conex-abstract-mech- 01]). 4) In the fourth step the congestion exposure signals are relayed back into the network in-band at the IP layer, such that the total level of congestion is visible to Conex Enabled IP devices along the path. This information MAY also be relayed to non co-located traffic managers. Note that steps 1 and 2 are common with the Throughput exposure approach documented in [draft-karagiannis-conex-throughput-exposure-03]. Making this approach common to both types of exposures. 2.2. 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). Karagiannis, Expires January 11, 2012 [Page 5] Internet-Draft Congestion exposure using non-TCP July 2011 2.3. Codepoint Encoding An identical encoding is used as the one specified in [draft-ietf- conex-abstract-mech-01]. 2.4. Conex Components The same Conex enabled devices can be used as the ones specified in [draft-ietf-conex-abstract-mech-01]. 2.4.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 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 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.4.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.4.3 Modified Receivers The receiver SHOULD be able to calculate the congestion 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} 3. IANA Considerations This memo includes no request to IANA. Karagiannis, Expires January 11, 2012 [Page 6] Internet-Draft Congestion exposure using non-TCP July 2011 4. Security Considerations The security considerations described in [draft-ietf-conex-abstract-mech-01] apply also for this document. 5. Conclusions This draft proposes a method of exposing Conex congestion using non- TCP Feedback. 6. Acknowledgements We thank Richard Scheffenegger and Bob Briscoe for feedback on this document. 7. 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. 8. References 8.1. Normative 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. 8.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 11, 2012 [Page 7] Internet-Draft Congestion exposure using non-TCP July 2011 [draft-karagiannis-conex-throughput-exposure-03] G. Karagiannis, D. Papadimitriou, "Exposing Conex Throughput using non-TCP Feedback", draft-karagiannis-conex-throughput- exposure-03, Internet draft (work in progress), 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 11, 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 11, 2012 [Page 9]