[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/