Network Working Group D. Lopez Pacheco Internet-Draft University Nice Sophia Antipolis Expires: March 26, 2012 E. Lochin ISAE A. Sathiaseelan University of Aberdeen September 23, 2011 An architecture to support explicit rate signaling over End-to-End paths draft-lopez-ietf-tsvwg-ipern-00 Abstract This memo introduces an architecture, called IP-ERN, which allows Explicit Rate Notification (ERN) protocols to be inter-operable with current IP-based networks. IP-ERN is based on the execution of both End-to-End (E2E) and ERN protocols at the end hosts. The resulting E2E-ERN protocol provides inter and intra protocol fairness and benefits from all ERN advantages when possible. We detail the principle of this novel architecture, which is compliant with every TCP feature, as well as IP-in-IP tunneling solutions. In particular, IP-ERN is an alternative to splitting Performance Enhancement Proxies. 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 March 26, 2012. 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 Lopez Pacheco, et al. Expires March 26, 2012 [Page 1] Internet-Draft IP-ERN September 2011 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. Lopez Pacheco, et al. Expires March 26, 2012 [Page 2] Internet-Draft IP-ERN September 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The IP-ERN architecture . . . . . . . . . . . . . . . . . . . 6 2.1. Concepts used in this document . . . . . . . . . . . . . . 6 2.2. At the sender side . . . . . . . . . . . . . . . . . . . . 7 2.3. At the forwarding devices . . . . . . . . . . . . . . . . 9 2.4. At the destination side . . . . . . . . . . . . . . . . . 10 3. Benefits of the proposed IP-ERN architecture and use case . . 11 3.1. First scenario: the bottleneck is not IP-ERN capable . . . 11 3.2. Second scenario: the bottleneck is IP-ERN capable and only E2E-ERN flows share the resources . . . . . . . . . . 11 3.3. Third scenario: the bottleneck is IP-ERN capable and both TCP and E2E-ERN flows share the resources . . . . . . 11 3.4. Substituting PEPs with IP-ERN Proxies in Satellite-based IP networks . . . . . . . . . . . . . . . 12 4. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. IP-ERN and TCP extensions . . . . . . . . . . . . . . . . 13 4.2. IP-ERN and Explicit Rate Notification protocols . . . . . 13 4.3. Internetworking with IPsec tunnels . . . . . . . . . . . . 13 4.4. Security concern . . . . . . . . . . . . . . . . . . . . . 13 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Lopez Pacheco, et al. Expires March 26, 2012 [Page 3] Internet-Draft IP-ERN September 2011 1. Introduction TCP New Reno (denoted standard TCP or simply TCP in the rest of this draft) is the dominant protocol in charge of providing congestion control, fair share and full utilization of the network resources [RFC2582]. However TCP's additive increase multiplicative decrease (AIMD) behaviour is known to obtain poor performance in large bandwidth delay product (LBDP) networks such as high speed gigabit links or large delay links such as satellite [RFC3649]. There have been several proposals to solve the problem of standard TCP over LBDP networks. Several variants to TCP have been proposed such as CUBIC [XR05] (currently enabled by default in GNU/Linux systems), Compound TCP [TSZS06] (deployed in some Microsofts' operating systems like Windows Vista), High Speed TCP [RFC3649] or more specialized TCP version for LBDP networks that are characterized by long delay such as Hybla TCP [CF04], specially designed to fit the needs of satellite networks. However, it has been shown in [HKLRX06] that the aggressiveness of high speed TCP variants can lead to congestion events, and their convergence time can be potentially large, increasing the intra/inter-protocol unfairness. Other high speed TCP variants, such as FAST TCP [JWL04], monitor the round-trip time (RTT) at the sender side. Such delay-based protocols considers an increase of the RTT as a congestion indicator following a more proactive approach to prevent congestion. However, delay-based protocols do not solve the problem of intra/inter-fairness [HKLRX06] [LAQSL04]. In the case of networks with very large delay, such as GEO satellite- based networks, the use of Performance Enhancing Proxies (PEPs) [RFC3135] is a commonly used solution that improves the performance of standard TCP. However PEPs break the end-to-end (E2E) semantics of TCP, and prevents the use of security protocols such as IPsec [RFC3135]. In addition, PEPs might require both high memory capacity to keep connection states and complex fault tolerant mechanisms. To achieve the goals of congestion control (i.e. achieve the capacity of links and converge as fast as possible) is a difficult task for E2E transport methods. E2E transport do not know the state of the network, where the problems actually happen, since they are strictly confined to the end hosts. An alternative to the E2E congestion control protocols is the use of an Explicit Rate Notification protocol where capable ERN forwarding devices inform the sender of the optimal sending rate (the so-called feedback). Some examples of ERN protocols are XCP (eXplicit Control Protocol) [KHR02]), QuickStart [RFC4782], RCP (Rate Control Protocol) [DMF06], JetMax [ZLL08], CADPC [W05] and TCP MaxNet [SWW05]. These Lopez Pacheco, et al. Expires March 26, 2012 [Page 4] Internet-Draft IP-ERN September 2011 kind of protocols demonstrate high performance and intra-protocol fairness in fully ERN-capable networks [KHR02] (i.e. where all routers support ERN capabilities). The major problem to the deployment of such a concept is that, at the exception of QuickStart, ERN protocols do not implement any mechanisms to deal with networks where non-ERN protocols (e.g., standard TCP) and non-ERN equipments (e.g., DropTail routers) are present. It has been proved that ERN protocols can perform worse than every TCP variant in non-full ERN networks [LPL06] [LPL07]. Therefore, ERN protocols cannot be used in heterogeneous networks and cannot be gradually deployed in the current Internet. Despite several efforts to enable an incremental deployment of ERN protocols over heterogeneous networks, these solutions do not (or only partially) solve the problems related to the interaction between ERN protocols with non-ERN protocols and non- ERN devices. In this document, we propose an architecture that allows incremental deployment of ERN protocols over heterogeneous networks. We term this architecture as IP-ERN. This architecture has been designed to be used with those ERN protocol that do not possess any mechanism to correctly co-exist with non-ERN protocols and non-ERN equipment, which is not the case of QuickStart. Hence, IP-ERN and QuickStart are not compatible as we will explain it later. In this architecture, a sender uses an hybrid E2E-ERN protocol which is capable of adapting its congestion window as a function of a DropTail or an ERN-capable bottleneck (we call an ERN-capable bottleneck, a bottleneck where the forwarding device implements the ERN protocol). When the sender receives an ERN feedback, it uses the minimum between the ERN and E2E congestion windows. Thus, IP-ERN can correctly handle congestion events whether the bottleneck is ERN-capable or not. The main goal of this document is therefore to provide the guidelines to allow co-existance of both E2E and an ERN protocol in a single host and explain how to: (i) create an E2E-ERN connection; (ii) update the congestion window by taking into account the E2E congestion control algorithm and the ERN feedbacks. However, this document will not provide any recommendation for any particular ERN protocol to be used with the IP-ERN architecture. Lopez Pacheco, et al. Expires March 26, 2012 [Page 5] Internet-Draft IP-ERN September 2011 2. The IP-ERN architecture ERN protocols provide both high link usage and intra-fairness while minimizing the buffer occupancy. As the buffer occupancy decreases the probability of loosing packets also decreases. When the bottleneck is ERN-capable, ERN protocols can compute the optimal congestion window. However, when the bottleneck is not ERN capable, E2E protocols provide a more adaptive congestion window. Therefore, the IP-ERN architecture executes both an E2E and an ERN protocols in a single sender, and use the minimum between the E2E and ERN congestion windows size. Consequently, an hybrid E2E-ERN source is able to use the congestion window computed by IP-ERN capable routers, but will never be more aggressive than the E2E protocol. The figure below gives a general view of the proposed IP-ERN architecture. Note that we introduce a Congestion Aware Layer (denoted CAL) which takes place between the IP and the transport layers. We detail in the following the internal mechanism of this additional layer. Sender Receiver ---------------- ---------------- | Upper Layers | | Upper Layers | ---------------- Forwarding node ---------------- | TCP | | TCP | ---------------- ---------------- ---------------- | CAL | | CAL | | CAL | ---------------- ---------------- ---------------- | IP | | IP | | IP | ---------------- ---------------- ---------------- | Lower Layers | | Lower Layers | | Lower Layers | ---------------- ---------------- ---------------- | | | ----------------------------------------- The following subsections define the concepts that are used in this document and describe the modifications at the sources, destinations and forwarding IP-ERN capable devices. 2.1. Concepts used in this document The following terms are introduced in this draft. Lopez Pacheco, et al. Expires March 26, 2012 [Page 6] Internet-Draft IP-ERN September 2011 1. IP-ERN traffic: traffic (paquets) sent by IP-ERN hosts. 2. E2E-ERN connections: connections whose congestion window can be handled by E2E congestion control protocols or ERN protocols thanks to the IP-ERN architecture. 3. IP-ERN hosts: end hosts implementing the IP-ERN architecture 4. IP-ERN forwarding devices: any forwarding device implementing the IP-ERN architecture. 2.2. At the sender side The sender implements both a transport layer and the Congestion Awareness Layer (CAL). The transport layer hosts the core of the TCP-based congestion control protocol, while the CAL layer hosts the core of the ERN protocol. In comparison to a classical IP sender, an IP-ERN sender additionally executes the following operations: (i) fill in the ERN header and insert it into the packet to be sent, (ii) extract the feedback from Acknowledgments (ACKs) and add this value to the ERN congestion window size. The IP-ERN routers (or proxies) will implement the operations required by the chosen ERN protocol. To establish an E2E-ERN connection, the CAL layer of a sender MUST insert a 2-bytes TCP option in the TCP option field in the SYN to indicate it is an IP-ERN capable sender. The first byte of this TCP option indicates the option length and the second byte, the chosen code to indicate an IP-ERN end host. This is done at the CAL layer. At the reception of a SYN-ACK, the CAL layer MUST search through the TCP option field the same 2-bytes TCP option. If the TCP option which indicates and IP-ERN capable end host is present, an E2E-ERN connection is established. Otherwise, a standard E2E connection is created. Once the E2E-ERN connection is established, a cwnd_ern_ variable is initialized with the current value of the cwnd_ variable of the TCP layer. Later, in every data packet to send, an ERN header MUST be inserted, which will be filled in according to the principles of the chosen ERN protocol. To carry up an ERN header in a packet, three different options are possible: 1) in IPv6 networks, a new Extension Header (EH) which belongs to the upper-layer group SHOULD carry up the ERN parameters. Then, CAL places such an EH according to the IPv6 principles. To get an identifier for our protocol will require important discussions at the Internet Engineering Task Force (IETF). Moreover, without Lopez Pacheco, et al. Expires March 26, 2012 [Page 7] Internet-Draft IP-ERN September 2011 such an identifier, IPv6 routers may process the packets by software, and not only by hardware (tha packets will pass through the so-called slow-path) [RFC2113], which will potentially delay the packets in the network; 2) in current IPv4 networks, one possibility is to encapsulate the ERN header in a TCP packet, that is why we call this ERN-over-TCP. The main objective being to re-use as much as possible the idea behind DCCP-over-UDP [PFP11]. Hence, a server supporting the IP- ERN architecture, will accept E2E-ERN connections through a given TCP port, which may not correspond to the ERN port. Also, the first TCP option will be the same as inserted in the SYN packet in order to signal to IP-ERN routers that this packet comes from an E2E-ERN capable node. We will not detail this proposition that are more related to a technical aspect; 3) in current IPv4 networks, it is also possible to place the ERN header between the IP header and the TCP header (as suggested in [KHR02]). This should allow routers to quickly find the ERN parameters. However, this solution requires to signal at the IP header different to TCP and UDP, which may cause packets to be dropped by middle boxes or processed by software in legacy routers. Concerning incoming packets, upon reception of an ACK, CAL MUST extract the ERN feedback to compute the ERN congestion window (cwnd_ern_). The way to extract the feedback from the ACK depend on the way the ERN header is inserted in the packets. Once the feedback is extracted, the cwnd_ern_ variable MUST be updated according to the principles of the chosen ERN protocol. Finally, immediately after updating the congestion window of the TCP layer (cwnd_), CAL modifies the cwnd_ variable according to the following equation: cwnd_ = min (cwnd_, cwnd_ern_) (1) By taking the minimum value between cwnd_ and cwnd_ern_, this architecture does not require any explicit mechanism to detect whether there are non IP-ERN capable routers in the network. Additionally, the time needed to switch from E2E to ERN capabilities (or reverse) is not longer than one RTT (time to detect a loss when going from ERN to E2E or time to receive the signaling from routers when going from E2E to ERN). The figure below presents this new architecture at the sender side. Lopez Pacheco, et al. Expires March 26, 2012 [Page 8] Internet-Draft IP-ERN September 2011 +------------------------------------------------------------------+ | | | TCP data ack | | | | | +------------------------------------------------------------------+ | CAL | | | | | | | | +-----------------------------+ | | | | | when cwnd_ is modified | | | | | | cwnd_= min(cwnd_,cwnd_ern_) | | | | | +-----------------------------+ | +-----------+ | | | | | compute | | | | +------------+ | cwnd_ern_ | | | | | Create ERN | +-----------+ | | | | header | | | | | +------------+ +--------------------+ | | | | get ERN parameters | | | | | remove ERN header | | | | +--------------------+ | +---------------------------------|-------------------|------------+ | | data ack 2.3. At the forwarding devices At the reception of a packet, the CAL of a forwarding device MUST check if this is an IP-ERN packet. The forwarding device will know if such a packet is sent by an IP-ERN capacle end hosts by looking at the next protocol (next EH) code in IPv4 (IPv6) networks or by looking at the source or destination port of a TCP packet (assuming one of the strategies listed in Subsection 2.1 is used). If the forwarding device concludes that a given packet is an IP-ERN packet, then the a feedback is computed and the ERN header can be updated according to the chosen ERN protocol's rules. Otherwise, packets are treated as default IP packets. Since IP-ERN forwarding devices can only influence the behavior of E2E-ERN sources, each forwarding node MUST compute a feedback by taking into account the E2E-ERN traffic only. In order to compute a feedback, an ERN router usually needs to compute the input traffic rate (which MUST corresponds to the E2E-ERN input traffic rate) and the buffer occupancy (which MUST corresponds to the buffer used by IP-ERN sources). Calculating the buffer occupancy without differentiation between E2E-ERN and pure E2E traffic might decrease IP-ERN senders' rate to drain packets from pure E2E flows. Note that in this proposition, IP-ERN routers do not attempt to provide fairness (such as in [TZD08] [LPL07]). Inter and intra Lopez Pacheco, et al. Expires March 26, 2012 [Page 9] Internet-Draft IP-ERN September 2011 fairness are ensured by E2E and ERN capabilities of IP-ERN senders. 2.4. At the destination side The Transport Layer at the receiver side implements the same layers as the sender side (i.e. TCP and CAL layers). When a SYN is received, CAL looks at the TCP option field to know if the sender is IP-ERN capable. If so, CAL sends back a SYN-ACK packet with the same 2-bytes TCP option in the TCP option field used by the IP-ERN sender to indicate it is an IP-ERN capable receiver. During the connection, upon reception of a data packet, CAL MUST copy the feedback from the data packet to the acknowledgment. CAL adds the ERN header to the outgoing ACK in the same way the sender does with a data packet. Lopez Pacheco, et al. Expires March 26, 2012 [Page 10] Internet-Draft IP-ERN September 2011 3. Benefits of the proposed IP-ERN architecture and use case In the previous section, we detailed the IP-ERN architecture which allows a partial deployment of ERN protocols and eliminates the problems of inter fairness that can appear in non fully ERN networks [LTLA10]. Hence, the following scenarios are possible: (i) the bottleneck is not IP-ERN capable, (ii) only E2E-ERN flows share an IP-ERN capable bottleneck and, (iii) both pure E2E and E2E-ERN flows share an IP-ERN capable bottleneck. 3.1. First scenario: the bottleneck is not IP-ERN capable IP-ERN hosts should not benefit from the ERN capabilities but they should fully benefit from TCP capabilities. Considering the following simple link topology: sender ----------- R1 --------------- R2 ------------ receiver If router R1 is IP-ERN capable, but not R2, then the feedback will reflect the network state at router R1. Assuming that the capacity of R1 is much higher than the capacity of R2, then the ERN congestion window of an E2E-ERN flow will be higher than the TCP congestion window. Thus, according to (1), the congestion window cwnd_ will follow the TCP behavior. 3.2. Second scenario: the bottleneck is IP-ERN capable and only E2E-ERN flows share the resources Each host implementing the IP-ERN architecture should fully benefit from ERN capabilities. Although this scenario does not correspond to what we usually call an incremental deployment (we consider here only E2E-ERN flows), there are some cases where network administrators might consider this solution to improve the performance of some portions of the network (e.g., in some parts of a Data Center). If router R2 from the topology described above is also IP-ERN capable, then the feedback will reflect the state at the bottleneck link. Therefore, when TCP will send above the bottleneck capacity, the ERN congestion window will be smaller than the TCP congestion window and the congestion window of the E2E-ERN flow will behave like a pure ERN protocol. 3.3. Third scenario: the bottleneck is IP-ERN capable and both TCP and E2E-ERN flows share the resources In this case, IP-ERN hosts will use their TCP capabilities to compete against pure TCP flows. When an IP-ERN router is shared between Lopez Pacheco, et al. Expires March 26, 2012 [Page 11] Internet-Draft IP-ERN September 2011 standard TCP and E2E-ERN flows, the feedback will be calculated taking into account only the E2E-ERN traffic and the optimal rate targeted by the router will be the maximal output link capacity. However, since E2E-ERN flows will be unable to reach the maximal output link capacity due to the presence of pure TCP flows, the router will persistently send positive feedbacks that will inflate the congestion window size of the E2E-ERN flows. Thus, the congestion window of the CAL layer (cwnd_ern_) will tend to infinity and according to (1), the congestion window of E2E-ERN flows will be handled by TCP and it will behave like any other TCP source. 3.4. Substituting PEPs with IP-ERN Proxies in Satellite-based IP networks The PEP architecture optimizes the transfer by using a transport protocol specially designed for links with large propagation delay (e.g., SCPS-TP [SCPS06], TCP-Hybla [CF04]), and maybe performing the retransmissions of packets lost to avoid as much as possible retransmission from the source. However, this architecture splits the connection and, as explained in the introduction, this splitting prevents the use of privacy protection protocols like IPSec. Also, splitting PEPs require complex fault tolerant mechanisms and enough resources (i.e. CPU and memory) to efficiently map the state and data of the sender at the splitting proxy. PEPs can be replaced with IP-ERN capable forwarding nodes to improve the performance of TCP, avoiding congestion and packet losses in cases where the satellite links represent the bottleneck. Lopez Pacheco, et al. Expires March 26, 2012 [Page 12] Internet-Draft IP-ERN September 2011 4. Discussions 4.1. IP-ERN and TCP extensions We want to point out that IP-ERN do not modify in any case the TCP algorithm. Consequently, any TCP congestion control algorithm and TCP feature can be safely used in the IP-ERN architecture. Hence, senders can still benefit from E2E protocols like CUBIC [XR05], Compound TCP [TSZS06], High Speed TCP [RFC3649], etc. in combination with ECN [RFC3168], F-RTO [RFC4138], larger congestion window strategies, between others. SACK [RFC2883] can also be used with IP- ERN, moreover, receivers MUST aggregate the feedback from several data packets to be sent in only one SACK packet. IP-ERN can also be used with Lower-than-Best-Effort Transport Protocols [RFC6297]. 4.2. IP-ERN and Explicit Rate Notification protocols IP-ERN is compatible with several Explicit Rate Notification protocols, like XCP, TCP MaxNet, JetMax, etc. The chosen ERN protocol, to be deployed at the Congestion Awareness sub-Layer, SHOULD follow the advises given in this document to handle the interaction between the TCP and ERN protocols. However, Quickstart SHOULD NOT be used with the IP-ERN architecture. The main reason is that Quickstart aims at directly jumping to a higher congestion window ignoring the steps that TCP should execute before, which can be against the IP-ERN's rules. Indeed, IP-ERN favors the TCP congestion control algorithm when its congestion window is smaller than the one computed by the chosen ERN protocol, and this is the base for a safe cohabitation with non IP-ERN capable sources. 4.3. Internetworking with IPsec tunnels The IP-ERN architecture is fully compatible with IPsec tunnels. Indeed, the encryption and/or authentication of the whole or partial IP datagram by legacy IPsec boxes makes IP-ERN senders to behave like a pure TCP sender. 4.4. Security concern Todo Lopez Pacheco, et al. Expires March 26, 2012 [Page 13] Internet-Draft IP-ERN September 2011 5. References [XR05] Rhee, I. and L. Xu, "CUBIC: a new TCP-friendly high-speed variant", PFLDNet , February 2005. [TSZS06] Tan, K., Song, J., Zhang, Q., and M. Shridaran, "Coumpound TCP: A scalable and TCP-friendly congestion control for high-speed networks", IEEE Infocom , April 2006. [CF04] Caini, C. and R. Firrincieli, "TCP hybla: a TCP enhancement for heterogeneous networks", International Journal of Satellite Communications and Networking 22, 2004. [JWL04] Jing, C., Wei, D., and S. Low, "FAST TCP: Motivation, Architecture, Algortihms, Performance", IEEE Infocom , March 2004. [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4138] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)", RFC 4138, August 2005. [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort Transport Protocols", RFC 6297, June 2011. [TZD08] Tai, C., Zhu, J., and N. Dukkipati, "Making Large Scale Deployment of RCP Practical for Real Networks", IEEE Infocom , April 2008. [KHR02] Katabi, D., Handley, M., and C. Rohrs, "Congestion control for high bandwidth-delay product networks", ACM SIGCOMM , 2002. [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A step toward realistic performance evaluation of high-speed TCP variants", Elsevier Computer Networks Journal , 2006. Lopez Pacheco, et al. Expires March 26, 2012 [Page 14] Internet-Draft IP-ERN September 2011 [LPL07] Lopez, D., Pham, P., and L. Lefevre, "Fairness issues when transferring large volume of data on high speed networks with router-assisted transport protocols", High Speed Networks Workshop, in conjunction with IEEE INFOCOM , 2007. [LTLA10] Lopez, D., Tran, T., Lochin, E., and A. Arnal, "Towards an incremental deployment of ERN protocols: a proposal for an E2E-ERN hybrid protocol", 8th International Workshop on Protocols for Future, Large-Scale and Diverse Network Transport PFLDNet , Nov 2010. [W05] Welzl, M., "Scalable Router Aided Congestion Avoidance for Bulk Data Transfer in High Speed Networks", 3rd International Workshop on Protocols for Future, Large- Scale and Diverse Network Transport PFLDNet , Feb 2005. [SCPS06] "Consultative Committee for Space Communications, Recommendation for Space Data System Standards, Space Communications Protocol Sspecification Transport protocol (SCPS-TP)", Technical Report CCSDS 714.0-B-2 , October 2006. [LPL06] Lopez, D., Pham, P., and L. Lefevre, "XCP-i : eXplicit Control Protocol for heterogeneous inter-networking of high-speed networks", IEEE Globecom , 2006. [LAQSL04] Leith, D., Andrew, L., Quetchenbach, T., Shorten, R., and K. Lavi, "Experimental Evaluation of Delay/Loss-based TCP Congestion Control Algorithms", PFLDNet , 2004. [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, STD 1, November 2003. [DMF06] Dukkipati, N., McKeown, N., and A. Fraser, "RCP-AC: Congestion Control to make flows complete quickly in any environment", High-Speed Networking Workshop: The Terabits Challenge (In Conjunction with IEEE Infocom , 2006. [ZLL08] Zhang, Y., Leonard, D., and D. Loguinov, "JetMax: Scalable Max-Min Congestion Control for High-Speed Heterogeneous Networks", Elsevier Computer Networks, vol. 52, no. 6 , April 2008. [SWW05] Suchara, M., Leonard, R., and B. Loguinov, "TCP MaxNet - implementation and experiments on the WAN in Lab", IEEE International conference on Networks (ICON), vol.2 pp.6. , November 2005. Lopez Pacheco, et al. Expires March 26, 2012 [Page 15] Internet-Draft IP-ERN September 2011 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- Start for TCP and IP", RFC 4782, STD 1, January 2007. [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, STD 1, April 1999. [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, STD 1, June 2001. [PFP11] Phelan, T., Fairhurst, G., and C. Perkins, "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)", IETF draft - work in progress draft-ietf-dccp-udpencap-09, STD 1, July 2011. Lopez Pacheco, et al. Expires March 26, 2012 [Page 16] Internet-Draft IP-ERN September 2011 Authors' Addresses Dino Martin Lopez Pacheco University Nice Sophia Antipolis 2000, route des Lucioles - bat. Euclide B Sophia Antipolis Cedex, 06903 France Phone: +33 (0)4 9294 2772 Email: dino.lopez@unice.fr URI: http://www.i3s.unice.fr/~lopezpac/ Emmanuel Lochin ISAE 10 avenue Edouard Belin Toulouse Cedex 4, 31055 France Phone: +33 (0)5 6133 9185 Email: emmanuel.lochin@isae.fr URI: http://manu.lochin.net/ Arjuna Sathiaseelan University of Aberdeen School of Engineering Aberdeen, Scotland AB24 3UE 1430 UK Phone: +61 8374 5206 Email: arjuna@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/arjuna Lopez Pacheco, et al. Expires March 26, 2012 [Page 17]