[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                       M. Boucadair
Internet-Draft                                                  D. Binet
Intended status: Informational                              C. Jacquenet
Expires: September 3, 2015                                France Telecom
                                                            L. Contreras
                                                          Telefonica I+D
                                                           March 2, 2015


    On the Need for Transport Protocol Profiles & Investigating New
                            Evolution Tracks
                 draft-boucadair-transport-protocols-00

Abstract

   The world of Internet transport protocols is changing, after decades
   of TCP and UDP operation.  Several proposals have been submitted for
   the past years (and counting) to introduce other transport protocols
   that aim at reducing the web latency of that of TCP or avoiding the
   burden of the various middle-boxes (NATs, firewalls, for one)
   encountered along the communication path.  Such initiatives, although
   not new, are motivated by the complexity of some (non-transparent)
   networking functions.

   This document advocates for the definition of transport profiles and
   the need to document recommendations for middleboxes, including
   Performance Enhancement Proxies (PEPs) behaviors.  A collaboration
   among the involved players (service providers, vendors) is required
   to soften the current complications encountered in the Internet at
   large.

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 September 3, 2015.




Boucadair, et al.       Expires September 3, 2015               [Page 1]


Internet-Draft             Transport Profiles                 March 2015


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  On Transport Services . . . . . . . . . . . . . . . . . . . .   4
   3.  Strategies to Enhance Transport services  . . . . . . . . . .   5
   4.  Proliferation of Transport Protocols  . . . . . . . . . . . .   5
   5.  On TCP Hegemony . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Need for a Holistic View for TCP Extensions . . . . . . . . .   7
   7.  Adoption Rate of TCP Extensions . . . . . . . . . . . . . . .   8
   8.  A Network Provider's Perspective  . . . . . . . . . . . . . .   8
     8.1.  Proposed Approach . . . . . . . . . . . . . . . . . . . .   8
     8.2.  Some Risks: . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Previous IETF Works . . . . . . . . . . . . . . . . . . . . .  10
   10. What's Next?  . . . . . . . . . . . . . . . . . . . . . . . .  11
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   14. Informative References  . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The world of Internet transport protocols is changing, after decades
   of TCP and UDP operation.  Several proposals have been submitted for
   the past years (and counting) to introduce other transport protocols
   or additional features to existing protocols that aim at reducing the
   web latency of that of TCP or avoiding the burden of the various
   middle-boxes (NATs, firewalls, for one) encountered along the
   communication path.  Such initiatives, although not new, are
   motivated by the complexity of some (non-transparent) networking
   functions.  Further collateral effects (including a thorough
   identification of various network hindrances) are discussed in this




Boucadair, et al.       Expires September 3, 2015               [Page 2]


Internet-Draft             Transport Profiles                 March 2015


   document together with potential contributions from network operators
   to overcome some of the encountered issues.

   Advanced service functions (e.g., Performance Enhancement Proxies
   ([RFC3135]), NATs, firewalls, etc.) are now required to achieve
   various objectives such as IP address sharing, firewalling, to avoid
   covert channels, to detect and protect against ever increasing DDoS
   attacks, etc.  Removing those functions is not an option because they
   are used to address constraints that are often typical of the current
   yet protean Internet situation (global IPv4 address depletion comes
   to mind, but also the plethora of services with different
   QoS/security/robustness requirements, etc.), and this is even
   exacerbated by environment-specific designs (e.g., the nature and the
   number of service functions that need to be invoked at the Gi
   interface of a mobile infrastructure).  Moreover, these sophisticated
   service functions are located in the network but also in service
   platforms, or intermediate entities (e.g., CDNs).  This situation
   clearly complicates diagnostic procedures whenever service
   degradation is experienced, given That the responsibility is often
   shared among various players.

   Also, there are performance issues that are specific to some wireless
   networks [I-D.manyfolks-gaia-community-networks].

   An important effort was conducted by the IETF (e.g., BEHAVE, PCP,
   Performance Implications of Link Characteristics (pilc)), but we
   believe further work is still required to mitigate/soften some of the
   pending issues.

   Note,

   o  "Middleboxes" or advanced Flow-Aware Service Functions are here to
      stay, whatever the progress of IPv6 adoption, in particular.
   o  Several experimental TCP extensions have been defined.  These
      extensions (may) have merits when taken individually but further
      impact analysis is required when they have to co-exist in
      operational environments.
   o  HTTP/2 protocol ([I-D.ietf-httpbis-http2]) is being mostly
      implemented using TLS capabilities.
   o  More transport protocols encapsulated over TCP/UDP are being used
      by applications providers and vendors.  Having a standard
      encapsulation scheme over TCP and UDP, including transport
      encapsulation recommendations, will help Network Providers fine
      tune their engineering rules and tweak of their networks.
   o  TCP proxies are widely present in operators architectures,
      specifically in mobile networks.





Boucadair, et al.       Expires September 3, 2015               [Page 3]


Internet-Draft             Transport Profiles                 March 2015


   o  Current evolution of transport and multiplexing services impact
      traffic patterns and optimization features set up to optimize
      resources and to improve Quality of Experience (QoS).
   o  Some application agents are not strictly following the "hard"
      limits of connections as indicated for instance in [RFC2068].
   o  Proposals to relax some of the TCP features (e.g., ordering) or to
      adopt an efficient byte stuffing schemes should be investigated.
   o  Transport over some media have specific requirements.  An update
      of [RFC3150][RFC3481], for example, would be useful.
   o  Close collaboration and coordination between applications and
      networks can simplify if not improve network-inferred policy
      enforcement schemes.  Applications may express their transport
      services requirements while transport protocols can expose, via
      advanced APIs, the functionalities they are offering and tweaking
      parameters that can be customized.
   o  Having a standard notification interface between the physical/link
      layer and the transport layer is likely to improve transport
      protocol performances in some networks.

   Network Providers should be able to keep on delivering differentiated
   services as a competitive business advantage, while mastering the
   complexity of the applications, (continuously) evaluating the impacts
   on middleboxes, and enhancing customer's quality of experience.
   Because every (new) transport protocol will come with its own
   problems and perfectible features, leveraging skills and experience
   of TCP design and operation is a first major step for network
   providers.

   This document advocates for the definition of transport profiles and
   the documentation of recommendations for middleboxes, including
   Performance Enhancement Proxy (PEPs) behaviors.  A collaboration
   among the usual players is required to soften the current
   complications encountered in the Internet at large.

2.  On Transport Services

   Transport services refer to the set of features that are offered by
   protocols used to multiplex connections over IP.  Examples of
   transport services include - but are not limited to- ordering
   delivery, reliable delivery, congestion control, or full or partial
   integrity protection.

   A transport protocol can be abstracted as an implementation which
   exposes a set of transport services.  For example, TCP (Transmission
   Control Protocol, [RFC0793]), which is the universally deployed and
   implemented transport protocol, offers reliable and ordered delivery,
   flow and congestion control, as well as primitives to manage a
   connection.  Unlike TCP, UDP (User Datagram Protocol, [RFC0768]) is a



Boucadair, et al.       Expires September 3, 2015               [Page 4]


Internet-Draft             Transport Profiles                 March 2015


   connectionless protocol that supports protection against data
   corruption using a checksum field.

3.  Strategies to Enhance Transport services

   Given the hurdles induced by advanced network-located service
   functions, "Make your own protocol" is not even an option.

   "Encapsulate over your favorite existing protocol", if transported
   over TCP, has more chances to experience less session failures.

      This assumes that the remote server is also upgraded to support
      such transport scheme, while failures are likely to occur when the
      encapsulation is implemented over UDP.

      Examples of proposals that follow such mitigation strategy are
      [I-D.cheshire-tcp-over-udp], or [I-D.iyengar-minion-protocol].

      A fallback to TCP (or UDP) must be supported anyway, let alone the
      complications related to the discovery of the capabilities of the
      remote server.

      Even if protocols encapsulated over UDP can make use of NAT
      traversal techniques, these protocols are still suffering from
      issues related to the presence of NATs and firewalls.  For
      example, there is no mechanism to notify endpoints that an entry
      is no more active in the NAT/Firewall.  Immediate notification and
      state recovery can be solved by activating specific Port Control
      Protocol (PCP) feature: (PCP ANNOUNCE OPCODE, [RFC6887]).

   The strategy that consists in "extending your favorite widely
   deployed transport protocol" is more viable from a deployment
   perspective.

      TCP can be extended [Options][ExtendTCP].  For example, extensions
      have been proposed to enhance user's quality of experience when
      TCP is in use such as: TCP Fast Open ([RFC7413]), Proportional
      Rate Reduction ([RFC6937]), increase the initial window
      ([RFC6928]), TCP Extensions for high performance ([RFC7323]) ,
      unordered TCP/TLS, etc.

4.  Proliferation of Transport Protocols

   Plethora of transport protocols have been proposed by the Internet
   community to accommodate requirements raised by emerging
   applications.  Overall, these applications are either requiring more
   transport services than what is actually offered by TCP and UDP, or
   less transport services.



Boucadair, et al.       Expires September 3, 2015               [Page 5]


Internet-Draft             Transport Profiles                 March 2015


   For example, SCTP (Stream Control Transmission Protocol, [RFC4960])
   was specified to accommodate applications which need more transport
   services than what can be offered by TCP (e.g., preserve
   (application) data boundaries, support of out-of-order delivery,
   built-in support of multiple streams).

   DCCP (Datagram Congestion Control Protocol, [RFC4340]) is another
   protocol that was promoted to accommodate requirements from
   applications which need more transport services than what is offered
   by UDP (e.g., congestion control), but without suffering from the
   constraints of a connection-oriented protocol like TCP (e.g.,
   reliable delivery mechanisms).

   UDP-lite ([RFC3828]) is a light version of UDP that was designed for
   applications that need less features than what is offered by UDP
   (e.g., partial data corruption detection), whereas DTLS (Datagram
   Transport Layer Security, [RFC6347]) and TLS ([RFC5246]) were
   specified for applications requiring encryption capabilities at the
   transport layer.

   Other candidate transport protocols are currently investigated to
   reduce the delay required to invoke a resource located in the
   Internet.  Typically, this consists in retrieving some contents by
   minimizing the delay induced by TCP or SCTP handshakes required for
   establishing a connection.  Yet, such approaches can take advantage
   of the transport services provided by connection-oriented protocols.

   It is worth mentioning that reducing the delay to access a requested
   resource is not only the responsibility of transport protocols, but
   also depends on various other services such as DNS and access service
   functions.  The whole chain should be optimized!  Reduce the delay
   when invoking a service objective should be moderated with other
   considerations such as policy enforcement at the server side
   (including rate-limit and actions taken to protect against DDoS
   attacks).

5.  On TCP Hegemony

   Despite the effort made by the Internet community to specify new
   transport protocols or propose improvements of existing ones (mainly
   TCP), the deployment reality is that TCP remains hegemonic.  Even
   worse, only connections destined to some TCP port numbers are allowed
   in some networks.

   Recent studies (e.g., [Traffic]) revealed that TCP accounts for
   84.35% of the total amount of packets forwarded over the Internet and
   92% of the bytes.  DCCP and SCTP were not found in those studies.




Boucadair, et al.       Expires September 3, 2015               [Page 6]


Internet-Draft             Transport Profiles                 March 2015


   The main reasons that explain the poor adoption of new transport-
   related features at the scale of the Internet are:

   1.  The presence of advanced network-located service functions (used
       to be called "middelboxes"), and

   2.  The lack of support by OSes.

   Typical examples of service functions include: traditional NAT
   (Network Address Translation, [RFC3022]), CGN (Carrier Grade NAT;
   including IPv4-IPv4 CGN ([RFC6888]), DS-Lite AFTR ([RFC6333]) or
   NAT64 ([RFC6146])), firewall, application proxies, Performance
   Enhancement Proxies (PEP, [RFC3135]), traffic uniformizers, etc.

   Transport-related solutions that assume that the remedy to the
   problem formulated above would be to withdraw all flow-aware service
   functions are not realistic.  The presence of advanced service
   functions must be considered by solution designers as the rule rather
   than the exception.

   Obviously, this does not mean that network providers should not
   question the pertinence to maintain some of these service functions
   active.  Even if a rationalization effort is required in this area
   (still this is deployment-specific), solution designers should
   propose solutions that are robust in the presence of these functions.

6.  Need for a Holistic View for TCP Extensions

   For example, extensions have been proposed to enhance user's quality
   of experience when TCP is in use such as: TCP Fast Open ([RFC7413]),
   Proportional Rate Reduction ([RFC6937]), increase the initial window
   size ([RFC6928]), TCP Extensions for high performance ([RFC7323]) ,
   unordered TCP/TLS, etc.  More can be found in [RFC7414].

   These extensions may have merits when taken individually, but the
   question is whether those merits are still valid when co-existing
   with other features.  In addition, these merits are a function of the
   deployment context (for example in fixed or mobile networks).

   Implementing small changes at large is here to stay.  Moreover,
   changing a transport protocol stack may is subject to the
   amplification principle (See Section 2.2.1 of [RFC3439]) since
   changes may not only have local impacts but may also impact the
   stability of a network (e.g., MPTCP hosts are more aggressive than
   TCP hosts).  Assessing the impact of these extensions on legacy hosts
   is critical.





Boucadair, et al.       Expires September 3, 2015               [Page 7]


Internet-Draft             Transport Profiles                 March 2015


7.  Adoption Rate of TCP Extensions

   According to [Traffic],

   o  34% of TCP segments are data-less ACKs.
   o  94% of SYN use SACK permitted option [RFC2018].
   o  MSS option in 96% TCP SYNs: A large number of TCP SYN messages
      advertise an MSS between 1000-1301 bytes (46% announces an MSS
      between 1300 bytes and 1460 bytes).
   o  Window Scale (WS) option and the TCP Timestamps (TS) [RFC7323] in
      63.9% of TCP SYNs.
   o  39.2% uses the TCP Timestamps (TS) [RFC7323] in TCP SYNs.
   o  Zero flows requesting ECN in TCP SYNs.

   Risks of unordered delivery is often design-specific.  Indeed,
   [Traffic] also showed that disordering is deployment-specific
   (because it was observed only in some networks); means that lead to
   such behavior should be disabled in those networks.  This suggests
   reliable means to minimize such risks.

   This data shows that several of TCP advances (e.g., WS) are not
   massively deployed or not deployed at all (e.g., ECN).  More effort
   is required to evangelize recent TCP advances and their motivations.

8.  A Network Provider's Perspective

8.1.  Proposed Approach

   Fortunately, there is still an opportunity for network providers to
   contribute to the improvement of transport services.  A technical
   strategy that would focus on the root causes to properly derive
   associated recommendations should be encouraged.

   Every (new) transport protocol will come with its own problems and
   perfectible features.  Too many transport protocols are really
   painful for all actors, including for network operators (think about
   the configuration of class of services, fairness access and usage of
   network resources, and other traffic management services).

   Leveraging skills and experience of TCP design as well as operation
   is a first major step for network providers.  For example, in order
   to reduce latency for TCP-based applications, the following technical
   tracks can be investigated:

   1.  Deactivate ordering management;

   2.  Consider efficient byte stuffing schemes;




Boucadair, et al.       Expires September 3, 2015               [Page 8]


Internet-Draft             Transport Profiles                 March 2015


   3.  Get rid of the Three-Way Handshake; or

   4.  Consider persistent connections whenever suitable.

   Network Providers should be able to keep on delivering differentiated
   services as a competitive business advantage, while mastering the
   complexity of the applications and enhancing customer's quality of
   experience.  This can be achieved by exposing and communicating
   reachability information (i.e., routes to access desired contents)
   that will foster session establishment.  This can be achieved using
   dedicated interfaces that can be used by applications.

   Reduce complexity at the application level, strengthen the
   collaboration between the applications and the network layer via
   clear interfaces should also be encouraged, but this may be subject
   to agreements.  Administrative-related considerations are out of
   scope of this document.

8.2.  Some Risks:

   From a network provider perspective, the following risks need to be
   taken into account when designing solution(s) that would enhance
   current transport services:

   o  Emergence of transport-specific proxies given that vendors promote
      their own transport protocols.

   o  In addition to the support of a fallback mode to TCP (or UDP),
      some of the proposals may lead to complex clients (application
      agents).  This complexity should be avoided because this is likely
      to be a source of performance degradation, especially when other
      sophisticated features are required.

   o  Performance Enhancing Proxies are currently the rule to optimize
      TCP, especially in mobile networks.  There is a need to agree on a
      TCP Profile, including required features to be supported by TCP
      acceleration engines (a.k.a., PEPs).

   o  Offloading some of the transport functions to the upper layers may
      be suitable for some cases (e.g., error detection) but this
      approach suffers from side effects such as buffering issues at the
      application level, potential misuse of the underlying transport
      service, complexity to diagnose degradation when it occurs,
      battery consumption for mobile devices because of frequent
      keepalives, etc.).

      According to [Power], the consumption of a mobile device with a
      keep-alive interval of 20 seconds (that is the default value) is



Boucadair, et al.       Expires September 3, 2015               [Page 9]


Internet-Draft             Transport Profiles                 March 2015


      29 mA (2G)/34 mA (3G).  When no keep-alive is issued, the
      consumption would be 5.2 mA (2G)/6.1 mA (3G).

   o  Covert channels can be made possible if encapsulation schemes are
      allowed without any security features.

   o  The accuracy of the engineering and tuning of network devices for
      an optimized service delivery may be impacted by the variety of
      traffic profiles, and, especially the change of the transport
      behavior (e.g., aggressive vs. other flows, fairness to make use
      of network resources, etc.).

   o  Path diversity (e.g., be able to establish a TCP communication
      over different paths for the sake of optimized bandwidth usage)
      becomes a typical requirement given the current adoption rate of
      multi-interfaced devices.

      Networks can cooperate with applications to help selecting the
      best path(s) but diverse transport protocols can provoke service
      disruption when the device re-connects to another network (e.g.,
      via a WLAN Hotspot, mobile, CPE, etc.), where network-assisted
      functions are hosted.

9.  Previous IETF Works

   Some recommendations to improve transport services have been
   documented for quite some time (e.g., [RFC4787], [RFC5382]).

   Such recommendations are related to the design and the operation of
   services in the presence of flow-aware devices (in particular, NATs).
   A few examples: the use of endpoint-independent NAT mapping (EIM) and
   filtering (EIF) behaviors, IP address pooling behavior of "Paired" to
   not break protocols such as RTP/RTCP, the selection of long mapping
   lifetime values to avoid breaking some applications, the preservation
   of port parity for RTP/RTCP-based applications (like VoIP), the
   preservation of port contiguity for some applications, the use of
   port randomness to avoid session hijacking, the ability to discover
   the external IP address/port/lifetime ([RFC6887]) so that
   applications with referral behave with no degradation, the analysis
   of the use of the HOST_ID ([RFC6967]) to soften issues induced by
   address sharing at large ([RFC6269]), etc.

   An effort to clarify some of the behave requirements is ongoing
   ([I-D.ietf-tsvwg-behave-requirements-update]).

   Also, the Performance Implications of Link Characteristics (pilc) WG
   conducted an important effort which led to
   [RFC3135][RFC3150][RFC3155][RFC3366][RFC3449][RFC3481][RFC3819].



Boucadair, et al.       Expires September 3, 2015              [Page 10]


Internet-Draft             Transport Profiles                 March 2015


10.  What's Next?

   The following candidate actions are proposed (non-exhaustive list):

   o  Define a TCP profile for hosts.  This profile can be an update of
      [RFC1122].  Or not.

   o  Update PEP recommendations.  Edit a BCP document about TCP
      extensions to be supported by middleboxes vendors and activated by
      operators.

         E.g., Update the header compression features recommended in
         [RFC3150] to include [RFC4996].

   o  Specify a MPTCP Profile in network regions that are firewall- and
      NAT-free: One of the promising deployment scenario for MPTCP
      ([RFC6824]) is to aggregate the resources offered by a CPE that is
      connected to multiple networks (e.g., DSL, LTE, WLAN), see for
      example [I-D.deng-mptcp-proxy] or
      [I-D.lhwxz-hybrid-access-network-architecture].

      This deployment scenario requires a kind of "concentrator" at the
      network side to terminate the aggregated session before relaying
      it into a legacy TCP session.  The concentrator is needed before
      the adoption rate of MPTCP at the server side is taking.

      Because the paths between the CPE and the concentrator are
      firewall- and NAT-free, the complexity of the MPTCP specification
      that was initially induced by handling the presence of firewalls
      and the routing asymmetry, is not justified anymore.  Such context
      encourages the specification of a dedicated MPTCP profile that
      would in turn foster the adoption of MPTCP.

   o  Standardize encapsulation schemes over TCP and UDP.

11.  IANA Considerations

   This document makes no request of IANA.

12.  Security Considerations

   Add some text about privacy and security.

13.  Acknowledgements

   TBC.





Boucadair, et al.       Expires September 3, 2015              [Page 11]


Internet-Draft             Transport Profiles                 March 2015


14.  Informative References

   [ExtendTCP]
              Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
              Handley, M. and H. Tokuda,, "Is it still possible to
              extend TCP?", November 2011,
              <http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf>.

   [I-D.cheshire-tcp-over-udp]
              Cheshire, S., Graessley, J., and R. McGuire,
              "Encapsulation of TCP and other Transport Protocols over
              UDP", draft-cheshire-tcp-over-udp-00 (work in progress),
              July 2013.

   [I-D.deng-mptcp-proxy]
              Lingli, D., Liu, D., Sun, T., Boucadair, M., and G.
              Cauchie, "Use-cases and Requirements for MPTCP Proxy in
              ISP Networks", draft-deng-mptcp-proxy-01 (work in
              progress), October 2014.

   [I-D.ietf-httpbis-http2]
              Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
              Protocol version 2", draft-ietf-httpbis-http2-17 (work in
              progress), February 2015.

   [I-D.ietf-tsvwg-behave-requirements-update]
              Penno, R., Perreault, S., Kamiset, S., Boucadair, M., and
              K. Naito, "Network Address Translation (NAT) Behavioral
              Requirements Updates", draft-ietf-tsvwg-behave-
              requirements-update-01 (work in progress), February 2015.

   [I-D.iyengar-minion-protocol]
              Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire
              Protocol", draft-iyengar-minion-protocol-02 (work in
              progress), October 2013.

   [I-D.lhwxz-hybrid-access-network-architecture]
              Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M.
              Zhang, "Hybrid Access Network Architecture", draft-lhwxz-
              hybrid-access-network-architecture-02 (work in progress),
              January 2015.

   [I-D.manyfolks-gaia-community-networks]
              Saldana, J., Arcia-Moret, A., Braem, B., Navarro, L.,
              Pietrosemoli, E., Rey-Moreno, C., Sathiaseelan, A., and M.
              Zennaro, "Alternative Network Deployments. Taxonomy and
              characterization", draft-manyfolks-gaia-community-
              networks-02 (work in progress), January 2015.



Boucadair, et al.       Expires September 3, 2015              [Page 12]


Internet-Draft             Transport Profiles                 March 2015


   [Options]  Alberto Medina, Mark Allman, Sally Floyd, "Measuring
              Interactions Between Transport Protocols and Middleboxes",
              2005, <http://conferences.sigcomm.org/imc/2004/papers/
              p336-medina.pdf>.

   [Power]    Haverinen, H., Siren, J., and P. Eronen, "Energy
              Consumption of Always-On Applications in WCDMA Networks",
              April 2007, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=4212635>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
              Selective Acknowledgment Options", RFC 2018, October 1996.

   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
              RFC 2068, January 1997.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022, January
              2001.

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135, June 2001.

   [RFC3150]  Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
              "End-to-end Performance Implications of Slow Links", BCP
              48, RFC 3150, July 2001.

   [RFC3155]  Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
              Vaidya, "End-to-end Performance Implications of Links with
              Errors", BCP 50, RFC 3155, August 2001.

   [RFC3366]  Fairhurst, G. and L. Wood, "Advice to link designers on
              link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
              August 2002.

   [RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
              Guidelines and Philosophy", RFC 3439, December 2002.



Boucadair, et al.       Expires September 3, 2015              [Page 13]


Internet-Draft             Transport Profiles                 March 2015


   [RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
              Sooriyabandara, "TCP Performance Implications of Network
              Path Asymmetry", BCP 69, RFC 3449, December 2002.

   [RFC3481]  Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and
              F. Khafizov, "TCP over Second (2.5G) and Third (3G)
              Generation Wireless Networks", BCP 71, RFC 3481, February
              2003.

   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, July 2004.

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
              G. Fairhurst, "The Lightweight User Datagram Protocol
              (UDP-Lite)", RFC 3828, July 2004.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC4996]  Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West,
              "RObust Header Compression (ROHC): A Profile for TCP/IP
              (ROHC-TCP)", RFC 4996, July 2007.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269, June
              2011.





Boucadair, et al.       Expires September 3, 2015              [Page 14]


Internet-Draft             Transport Profiles                 March 2015


   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, January 2013.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
              2013.

   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Requirements for Carrier-Grade NATs
              (CGNs)", BCP 127, RFC 6888, April 2013.

   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
              "Increasing TCP's Initial Window", RFC 6928, April 2013.

   [RFC6937]  Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional
              Rate Reduction for TCP", RFC 6937, May 2013.

   [RFC6967]  Boucadair, M., Touch, J., Levis, P., and R. Penno,
              "Analysis of Potential Solutions for Revealing a Host
              Identifier (HOST_ID) in Shared Address Deployments", RFC
              6967, June 2013.

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, "TCP Extensions for High Performance", RFC
              7323, September 2014.

   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", RFC 7413, December 2014.

   [RFC7414]  Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
              Zimmermann, "A Roadmap for Transmission Control Protocol
              (TCP) Specification Documents", RFC 7414, February 2015.

   [Traffic]  David Murray, Terry Koziniec, "The State of Enterprise
              Network Traffic in 2012", 2012,
              <http://conferences.sigcomm.org/imc/2004/papers/
              p336-medina.pdf>.






Boucadair, et al.       Expires September 3, 2015              [Page 15]


Internet-Draft             Transport Profiles                 March 2015


Authors' Addresses

   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com


   David Binet
   France Telecom
   Rennes  35000
   France

   Email: david.binet@orange.com


   Christian Jacquenet
   France Telecom
   Rennes
   France

   Email: christian.jacquenet@orange.com


   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, s/n
   Madrid  28050
   Spain

   Email: lmcm@tid.es
   URI:   http://people.tid.es/LuisM.Contreras/

















Boucadair, et al.       Expires September 3, 2015              [Page 16]