Internet DRAFT - draft-lopez-ietf-tsvwg-ipern
draft-lopez-ietf-tsvwg-ipern
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]
