ConEx G. Karagiannis Internet-Draft University of Twente Intended status: Experimental D. Papadimitriou Expires: January 8, 2012 Alcatel-Lucent July 8, 2011 Exposing Conex Throughput using non-TCP Feedback draft-karagiannis-conex-throughput-exposure-02 Abstract This draft is focusing on relaying throughput instead of congestion back into the network in-band at the IP layer, such that the total level of throughput is visible to all IP devices along the path. The 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 the throughput 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 08, 2012. Karagiannis Expires January 8, 2012 [Page 1] Internet-Draft Exposing Conex Throughput 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. DCCP based Conex Throughput Solution . . . . . . . . . . . . . 2.1. Requirements for the Conex signal . . . . .. . . . . . . . 2.2. Codepoint Encoding . . . . . . . . . . . . . . . . . . . . 2.3. Conex Throughput 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 8, 2012 [Page 2] Internet-Draft Exposing Conex Throughput July 2011 1. Introduction The ConEx working group is defining how IP packets will carry additional ConEx information. This document is focusing relaying throughput instead of congestion back into the network in-band at the IP layer, such that the total level of throughput is visible to all IP devices along the path. 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 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 focuses on the relaying throughput instead of congestion back into the network in-band at the IP layer, such that the total level of throughput is visible to all IP devices along the path. In addition to this, this draft uses another method for feedback of the congestion information back to the sender using a non-TCP protocol, such as the DCCP (Datagram Congestion Control Protocol) transport protocol instead of using the TCP transport protocol. The 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 the throughput experienced on the end-to-end path back into the network. The challenges that need to be addressed by this approach are: o) The Internet operation has to enable multi-domain information exchanges to effectively enable network-to-host information passing as detailed in this document. This condition is of particular importance for congestion control schemes that make use of explicit rate feedback. On the other hand, multi-domain environment shall be considered as non-cooperative. Karagiannis Expires January 8, 2012 [Page 3] Internet-Draft Exposing Conex Throughput July 2011 o) It is important to emphasize that network support of rate signaling suffers from the same scalability problems as identified in [RFC2208]. Indeed, in-band rate signaling or out-of-band per- flow traffic specification signaling (like in the Resource Reservation Protocol (RSVP)) results in similar scalability issues due to the per-connection state maintenance. As noticed in Section 1 of [RFC6077], due to the non-cooperative nature of multi-domain environments, it seems unlikely that network flow state could be avoided (up to a certain extend) given the network's per-packet flow rate instructions that would need to be compared against variations in the actual flow rate, which is inherently not a per- packet metric. These issues have been outstanding ever since integrated services (IntServ) was identified as unscalable in 1997 [RFC2208]. Any subsequent attempt to involve network elements in limiting flow rates (including XCP, RCP, etc.) have run up against the same scalability issues when intending deployment on the public/worldwide Internet. o) Security is a challenge for multi-domain exchange of explicit rate/congestion signals, whether in-band or out-of-band. At domain boundaries, authentication and authorization issues can arise whenever congestion control information is exchanged. 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]. In addition to the terminology specified in [draft-ietf-conex- abstract-mech-01] and [draft-ietf-conex-concepts-uses-01], [RFC5348] the following terms are used and defined in this document. O Transport path throughput calculated at the sender: The per flow transport sending rate as a function of the congestion rate, round-trip time, and segment size. The transport path throughput calculated at the sender can be realized using different methods. As example, this draft uses as example the TCP throughput equation that is specified in [RFC5348]. Note that in [RFC5348] the term congestion rate is denoted as loss event rate. According to [RFC5348] a loss event is defined as one or more lost or marked packets from a window of data, where a marked packet refers to a congestion indication (CE) from Explicit Congestion Notification (ECN) [RFC3168]; Karagiannis Expires January 8, 2012 [Page 4] Internet-Draft Exposing Conex Throughput July 2011 O Throughput exposure signal (ConEx-Throughput): a ConEx signal encoded in IP packet headers from the sender to the network to exposure the transport path throughput calculated at the sender. O Intermediate ConEx enabled device: each Conex enabled device located on a communication path between a sender and a receiver. O Measured per flow throughput at intermediate ConEx enabled devices: the per flow rate of packets that are passing through the output buffer of an intermediate Conex enabled device and are not dropped, (2) are not ECN CE marked. Each ConEx enabled device is only holding state on a flow if it first receives a Throughput exposure signal. O Throughput exposure rate at intermediate ConEx devices: the per flow rate of the received throughput exposure signals (Conex- Throughput). Each ConEx enabled device is only holding state on a flow if it first receives a Throughput exposure signal (Conex- Throughput). 2. Method of Exposing Conex Throughput using non-TCP Feedback 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, (2) feedback 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 [RFC5622] or [RFC4342] (3) calculate the sending throughput at the sender, (4) relaying the throughput 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 throughput is visible to all IP devices along the path. 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 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 for this purpose used. For a normative specification of the loss event rate see Section 5 of [RFC5348] and [RFC4828]. Karagiannis Expires January 8, 2012 [Page 5] Internet-Draft Exposing Conex Throughput July 2011 During the second step used by this method, 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]. In the third step of this method, a sender calculates the per flow transport path throughput, which describes the sending rate as a function of the congestion rate, round-trip time, and segment size. The transport path throughput calculated at the sender can be accomplished using different algorithms. As example, the TCP throughput equation specified in [RFC5348] or [RFC4828] can be applied. Using the calculated throughput, the sender generates the Conex throughput exposure signals that are encoded in IP packet headers. In the fourth step the Throughput exposure signals are relayed back into the network in-band at the IP layer, such that the total level of throughput is visible to all IP devices along the path. Each intermediate ConEx enabled device is holding per flow state to store the value of the exposed throughput rate, which is the per flow rate of the received throughput exposure signals (Conex- Throughput). Each ConEx enabled device is only holding state on a flow if it first receives a Throughput exposure signal (Conex- Throughput). It is important to note that the per flow throughput measured by intermediate ConEx enabled devices located closer to the sender can be higher than the per flow throughput measured by Conex enabled devices located closer to the receiver. Identical use cases and applications can be used as the ones described in [draft-ietf-conex-concepts-uses-01], using the same semantics related to the exposed and measured congestion. The only difference is now that the intermediate Conex enabled devices can monitor and process the "Measured per flow throughput" and the "Throughput exposure rate", instead of monitoring and processing the measured congestion rate and the signaled exposed congestion rate, respectively. An example of applying this method, is to enable each intermediate Congestion enabled device to observe whether the "Measured per flow throughput" is equal or higher than the "Throughput exposure rate" of the same flow. If that is not the case then the intermediate Conex enabled devices can react accordingly depending on the application that uses this solution. {More details will be provided in a next version of this draft} Karagiannis Expires January 8, 2012 [Page 6] Internet-Draft Exposing Conex Throughput July 2011 +---------+ +---------+ |Transport| +-----------+ |Transport| | Sender |>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver| | | | Network |>-Congestion-Signal->|---. | | | | Device | | | | | | +-----------+ | | | | | | | | | |<==Feedback=Path==============================<| | | | ,---|<--non-TCP returned Congestion Signal-- ------<|<--' | | V | | | ||-------|| | | ||Througp|| | | || || +-----------+ |Transport| ||calcul.||>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver| || |->(new)Conex->| Network |-(Throughp. signal)->| | |+-------+| | Device | (carried in data | | | | +-----------+ packet headers) | | +---------+ +---------+ Figure 1: Overview ConEx architecture, with Conex throughput Exposure 2.1. Requirements for the ConEx Signal The following requirements apply to the Conex-Throughput 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 throughput is represented accurately). Note that in case of throughput exposure timeliness and accuracy shall be bound by min;max limits in order to prevent non-significant deviations (e.g. relative variations would be worth considering in this respect). Karagiannis Expires January 8, 2012 [Page 7] Internet-Draft Exposing Conex Throughput July 2011 2.2. Codepoint Encoding This encoding involves signaling the following codepoint: Conex-Throughput: a ConEx signal encoded in IP packet headers from the sender to the network to exposure the transport path throughput calculated at the sender. 2.3. Conex Throughput Components The same Conex enabled devices can be used as the ones specified in [draft-ietf-conex-abstract-mech-01]. 2.3.1 Modified Senders The senders SHOULD support the protocol that is carrying the throughput exposure information from the receiver to the sender. Moreover, the sender should implement an algorithm that can use the feedback congestion information to calculate the throughput 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 this case, the sender MUST be able to support the following functionality: O calculates the transport path throughput: The per flow transport sending rate as a function of the congestion rate, round- trip time, and segment size. The transport path throughput calculated at the sender using the TCP throughput equation specified in [RFC5348]. Note that in [RFC5348] the term congestion rate is denoted as loss event rate. According to [RFC5348] a loss event is defined as one or more lost or marked packets from a window of data, where a marked packet refers to a congestion indication (CE) from Explicit Congestion Notification (ECN) [RFC3168]. In addition, the sender MUST be able to support the following functionality: O generates and encodes ConEx-Throughput signals in IP packet headers from the sender to the network to exposure the transport path throughput calculated at the same sender. Karagiannis Expires January 8, 2012 [Page 8] Internet-Draft Exposing Conex Throughput July 2011 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. The only difference is now that the intermediate Conex enabled devices SHOULD monitor and SHOULD process the "Measured per flow throughput" and the "Throughput exposure rate", instead of monitoring and processing the measured congestion rate and the signaled exposed congestion rate, respectively. 2.3.3 Modified Receivers 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, the receivers should be able to support the TCP-Friendly Rate Control (TFRC) based congestion control protocol, e.g., [RFC5348] (in combination with [RFC4342]) or [RFC4828] (in combination with [RFC5622]). In addition, the receiver MUST be able to support the following functionality: O Measure per flow throughput: the per flow rate of packets that are Received and (1) are not dropped, (2) are not ECN CE marked. O Measure throughput exposure rate at intermediate Conex devices: the per flow rate of the received throughput exposure signals. {More details on will be provided in a next version of this draft} 3. IANA Considerations This memo includes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Karagiannis Expires January 8, 2012 [Page 9] Internet-Draft Exposing Conex Throughput July 2011 4. Security Considerations The security consideration sections are the same as the security considerations associated with [draft-ietf-conex-abstract-mech-01]. {More details will be provided in a next version of this draft>} 5. 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 9.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. 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 8, 2012 [Page 10] Internet-Draft Exposing Conex Throughput 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. [RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997. [RFC3168] K. Ramakrishnan, S. Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [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. Karagiannis Expires January 8, 2012 [Page 11] Internet-Draft Exposing Conex Throughput July 2011 [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. [RFC6077] D.Papadimitriou (Ed.), M.Welzl, M.Scharf, B.Briscoe, Open Research Issues in Internet Congestion Control, RFC 6077, February 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 8, 2012 [Page 12]