<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-boucadair-transport-protocols-01"
     ipr="trust200902">
  <front>
    <title abbrev="Transport Profiles">On the Need for Transport Protocol
    Profiles &amp; Investigating New Evolution Tracks</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="David Binet" initials="D." surname="Binet">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>david.binet@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <author fullname="Luis M. Contreras" initials="L." surname="Contreras">
      <organization>Telefonica I+D</organization>

      <address>
        <postal>
          <street>Ronda de la Comunicacion, s/n</street>

          <city>Madrid</city>

          <region></region>

          <code>28050</code>

          <country>Spain</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>lmcm@tid.es</email>

        <uri>http://people.tid.es/LuisM.Contreras/</uri>
      </address>
    </author>

    <author fullname="Yiu Lee" initials="Y." surname="Lee">
      <organization>Comcast</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <country>US</country>
        </postal>

        <email>Yiu_Lee@Cable.Comcast.com</email>
      </address>
    </author>

    <date />

    <abstract>
      <t>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.</t>

      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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 document together with
      potential contributions from network operators to overcome some of the
      encountered issues.</t>

      <t>Advanced service functions (e.g., Performance Enhancement Proxies
      (<xref target="RFC3135"></xref>), 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.</t>

      <t>Also, there are performance issues that are specific to some wireless
      networks <xref
      target="I-D.manyfolks-gaia-community-networks"></xref>.</t>

      <t>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.</t>

      <t>Note,<?rfc subcompact="yes" ?></t>

      <t><list style="symbols">
          <t>"Middleboxes" or advanced Flow-Aware Service Functions are here
          to stay, whatever the progress of IPv6 adoption, in particular.</t>

          <t>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.</t>

          <t>HTTP/2 protocol (<xref target="I-D.ietf-httpbis-http2"></xref>)
          is being mostly implemented using TLS capabilities.</t>

          <t>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.</t>

          <t>TCP proxies are widely present in operators architectures,
          specifically in mobile networks.</t>

          <t>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).</t>

          <t>Some application agents are not strictly following the "hard"
          limits of connections as indicated for instance in <xref
          target="RFC2068"></xref>.</t>

          <t>Proposals to relax some of the TCP features (e.g., ordering) or
          to adopt an efficient byte stuffing schemes should be
          investigated.</t>

          <t>Transport over some media have specific requirements. An update
          of <xref target="RFC3150"></xref><xref target="RFC3481"></xref>, for
          example, would be useful.</t>

          <t>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.</t>

          <t>Having a standard notification interface between the
          physical/link layer and the transport layer is likely to improve
          transport protocol performances in some networks.</t>
        </list></t>

      <t><?rfc subcompact="no" ?>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.</t>

      <t>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.</t>
    </section>

    <section title="On Transport Services">
      <t>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.</t>

      <t>A transport protocol can be abstracted as an implementation which
      exposes a set of transport services. For example, TCP (Transmission
      Control Protocol, <xref target="RFC0793"></xref>), 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, <xref
      target="RFC0768"></xref>) is a connectionless protocol that supports
      protection against data corruption using a checksum field.</t>
    </section>

    <section title="Strategies to Enhance Transport services">
      <t>Given the hurdles induced by advanced network-located service
      functions, &ldquo;Make your own protocol&rdquo; is not even an
      option.</t>

      <t>&ldquo;Encapsulate over your favorite existing protocol&rdquo;, if
      transported over TCP, has more chances to experience less session
      failures. <list style="empty">
          <t>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.</t>

          <t>Examples of proposals that follow such mitigation strategy are
          <xref target="I-D.cheshire-tcp-over-udp"></xref>, or <xref
          target="I-D.iyengar-minion-protocol"></xref>.</t>

          <t>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.</t>

          <t>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, <xref
          target="RFC6887"></xref>).</t>
        </list></t>

      <t>The strategy that consists in &ldquo;extending your favorite widely
      deployed transport protocol&rdquo; is more viable from a deployment
      perspective. <list style="empty">
          <t>TCP can be extended <xref target="Options"></xref><xref
          target="ExtendTCP"></xref>. For example, extensions have been
          proposed to enhance user's quality of experience when TCP is in use
          such as: TCP Fast Open (<xref target="RFC7413"></xref>),
          Proportional Rate Reduction (<xref target="RFC6937"></xref>),
          increase the initial window (<xref target="RFC6928"></xref>), TCP
          Extensions for high performance (<xref target="RFC7323"></xref>),
          TCP-EDO <xref target="I-D.ietf-tcpm-tcp-edo"></xref>, unordered
          TCP/TLS, etc.</t>
        </list></t>
    </section>

    <section title="Proliferation of Transport Protocols">
      <t>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.</t>

      <t>For example, SCTP (Stream Control Transmission Protocol, <xref
      target="RFC4960"></xref>) 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).</t>

      <t>DCCP (Datagram Congestion Control Protocol, <xref
      target="RFC4340"></xref>) 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).</t>

      <t>UDP-lite (<xref target="RFC3828"></xref>) 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, <xref target="RFC6347"></xref>) and
      TLS (<xref target="RFC5246"></xref>) were specified for applications
      requiring encryption capabilities at the transport layer.</t>

      <t>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.</t>

      <t>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).</t>
    </section>

    <section title="On TCP Hegemony">
      <t>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.</t>

      <t>Recent studies (e.g., <xref target="Traffic"></xref>) 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.</t>

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

      <t><list style="numbers">
          <t>The presence of advanced network-located service functions (used
          to be called &ldquo;middelboxes&rdquo;), and</t>

          <t>The lack of support by OSes.</t>
        </list></t>

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

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Need for a Holistic View for TCP Variants">
      <t>For example, variants have been proposed to enhance user's quality of
      experience when TCP is in use such as: TCP Fast Open (<xref
      target="RFC7413"></xref>), Proportional Rate Reduction (<xref
      target="RFC6937"></xref>), increase the initial window size (<xref
      target="RFC6928"></xref>), TCP Extensions for high performance (<xref
      target="RFC7323"></xref>) , unordered TCP/TLS, etc. More can be found in
      <xref target="RFC7414"></xref>.</t>

      <t>These variants 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).</t>

      <t>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 <xref target="RFC3439"></xref>) 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 variants on legacy hosts is
      critical.</t>
    </section>

    <section title="Adoption Rate of TCP Extensions">
      <t>According to <xref target="Traffic"></xref>, <?rfc subcompact="yes" ?><list
          style="symbols">
          <t>34% of TCP segments are data-less ACKs.</t>

          <t>94% of SYN use SACK permitted option <xref
          target="RFC2018"></xref>.</t>

          <t>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).</t>

          <t>Window Scale (WS) option and the TCP Timestamps (TS) <xref
          target="RFC7323"></xref> in 63.9% of TCP SYNs.</t>

          <t>39.2% uses the TCP Timestamps (TS) <xref target="RFC7323"></xref>
          in TCP SYNs.</t>

          <t>Zero flows requesting ECN in TCP SYNs.</t>
        </list></t>

      <t><?rfc subcompact="no" ?>Risks of unordered delivery is often
      design-specific. Indeed, <xref target="Traffic"></xref> 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.</t>

      <t>This data shows that several of TCP advances (e.g., WS) are not
      massively deployed or not deployed at all (e.g., ECN). A recent study
      about the support of ECN is available at <xref target="ECN"></xref>.</t>

      <t>More effort is required to evangelize recent TCP advances and their
      motivations.</t>
    </section>

    <section title="A Network Provider's Perspective">
      <t></t>

      <section title="Proposed Approach">
        <t>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.</t>

        <t>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).</t>

        <t>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: <list style="numbers">
            <t>Deactivate ordering management;</t>

            <t>Consider efficient byte stuffing schemes;</t>

            <t>Get rid of the Three-Way Handshake; or</t>

            <t>Consider persistent connections whenever suitable.</t>
          </list></t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="Some Risks: ">
        <t>From a network provider perspective, the following risks need to be
        taken into account when designing solution(s) that would enhance
        current transport services: <list style="symbols">
            <t>Emergence of transport-specific proxies given that vendors
            promote their own transport protocols.</t>

            <t>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.</t>

            <t>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).</t>

            <t>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.). <vspace blankLines="1" />According to <xref
            target="Power"></xref>, the consumption of a mobile device with a
            keep-alive interval of 20 seconds (that is the default value) is
            29 mA (2G)/34 mA (3G). When no keep-alive is issued, the
            consumption would be 5.2 mA (2G)/6.1 mA (3G).</t>

            <t>Covert channels can be made possible if encapsulation schemes
            are allowed without any security features.</t>

            <t>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.).</t>

            <t>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.<vspace blankLines="1" /> 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.</t>
          </list></t>
      </section>
    </section>

    <section title="Previous IETF Works">
      <t>Some recommendations to improve transport services have been
      documented for quite some time (e.g., <xref target="RFC4787"></xref>,
      <xref target="RFC5382"></xref>).</t>

      <t>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 (<xref target="RFC6887"></xref>) so
      that applications with referral behave with no degradation, the analysis
      of the use of the HOST_ID (<xref target="RFC6967"></xref>) to soften
      issues induced by address sharing at large (<xref
      target="RFC6269"></xref>), etc.</t>

      <t>An effort to clarify some of the behave requirements is ongoing
      (<xref target="I-D.ietf-tsvwg-behave-requirements-update"></xref>).</t>

      <t>Also, the Performance Implications of Link Characteristics (pilc) WG
      conducted an important effort which led to <xref
      target="RFC3135"></xref><xref target="RFC3150"></xref><xref
      target="RFC3155"></xref><xref target="RFC3366"></xref><xref
      target="RFC3449"></xref><xref target="RFC3481"></xref><xref
      target="RFC3819"></xref>.</t>
    </section>

    <section title="What's Next?">
      <t>The following candidate actions are proposed (non-exhaustive
      list):<list style="symbols">
          <t>Define a TCP profile for hosts. This profile can be an update of
          <xref target="RFC1122"></xref>. Or not.</t>

          <t>Update PEP recommendations. Edit a BCP document about TCP
          extensions to be supported by middleboxes vendors and activated by
          operators.<list style="empty">
              <t>E.g., Update the header compression features recommended in
              <xref target="RFC3150"></xref> to include <xref
              target="RFC4996"></xref>.</t>
            </list></t>

          <t>Specify a MPTCP Profile in network regions that are firewall- and
          NAT-free: One of the promising deployment scenario for MPTCP (<xref
          target="RFC6824"></xref>) is to aggregate the resources offered by a
          CPE that is connected to multiple networks (e.g., DSL, LTE, WLAN),
          see for example <xref target="I-D.deng-mptcp-proxy"></xref> or <xref
          target="I-D.lhwxz-hybrid-access-network-architecture"></xref>.<vspace
          blankLines="1" />This deployment scenario requires a kind of
          &ldquo;concentrator&rdquo; 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. <vspace blankLines="1" />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.</t>

          <t>Standardize encapsulation schemes over TCP and UDP.</t>
        </list></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Add some text about privacy and security.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thanks to J. Touch for the comments.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include="reference.RFC.1122"?>

      <?rfc include='reference.RFC.3135'?>

      <?rfc include='reference.RFC.0768'?>

      <?rfc include='reference.RFC.0793'?>

      <?rfc include='reference.RFC.7323'?>

      <?rfc include='reference.RFC.4996'?>

      <?rfc include='reference.RFC.5382"?>

      <?rfc include='reference.RFC.4787'?>

      <?rfc include='reference.RFC.3150'?>

      <?rfc include='reference.RFC.4340'?>

      <?rfc include='reference.RFC.3481'?>

      <?rfc include='reference.RFC.4960'?>

      <?rfc include='reference.RFC.6888'?>

      <?rfc include='reference.RFC.2068'?>

      <?rfc include='reference.RFC.2018'?>

      <?rfc include='reference.I-D.ietf-tsvwg-behave-requirements-update'?>

      <?rfc include='reference.I-D.cheshire-tcp-over-udp'?>

      <?rfc include='reference.I-D.iyengar-minion-protocol'?>

      <?rfc include='reference.I-D.deng-mptcp-proxy'?>

      <?rfc include='reference.I-D.lhwxz-hybrid-access-network-architecture'?>

      <?rfc include='reference.I-D.manyfolks-gaia-community-networks'?>

      <?rfc include='reference.RFC.3828'?>

      <?rfc include='reference.RFC.7413'?>

      <?rfc include='reference.RFC.6928'?>

      <?rfc include='reference.RFC.6269'?>

      <?rfc include='reference.RFC.6347'?>

      <?rfc include='reference.RFC.5246'?>

      <?rfc include='reference.RFC.6967'?>

      <?rfc include='reference.RFC.6937'?>

      <?rfc include='reference.RFC.3366'?>

      <?rfc include='reference.RFC.3449'?>

      <?rfc include='reference.RFC.3022'?>

      <?rfc include='reference.RFC.3155'?>

      <?rfc include='reference.RFC.6333'?>

      <?rfc include='reference.RFC.6824'?>

      <?rfc include='reference.RFC.3819'?>

      <?rfc include='reference.RFC.3439'?>

      <?rfc include='reference.RFC.6887'?>

      <?rfc include='reference.RFC.7414'?>

      <?rfc include='reference.I-D.ietf-tcpm-tcp-edo'?>

      <?rfc include='reference.I-D.ietf-httpbis-http2'?>

      <?rfc include='reference.RFC.6146'?>

      <reference anchor="ExtendTCP"
                 target="http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf">
        <front>
          <title>Is it still possible to extend TCP?</title>

          <author fullname="" initials="" surname="">
            <organization>Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
            Handley, M. and H. Tokuda,</organization>
          </author>

          <date month="November" year="2011" />
        </front>
      </reference>

      <reference anchor="Options"
                 target="http://conferences.sigcomm.org/imc/2004/papers/p336-medina.pdf">
        <front>
          <title>Measuring Interactions Between Transport Protocols and
          Middleboxes</title>

          <author fullname="" initials="" surname="">
            <organization>Alberto Medina, Mark Allman, Sally
            Floyd</organization>
          </author>

          <date year="2005" />
        </front>
      </reference>

      <reference anchor="Traffic"
                 target="http://conferences.sigcomm.org/imc/2004/papers/p336-medina.pdf">
        <front>
          <title>The State of Enterprise Network Traffic in 2012</title>

          <author fullname="" initials="" surname="">
            <organization>David Murray, Terry Koziniec</organization>
          </author>

          <date year="2012" />
        </front>
      </reference>

      <reference anchor="Power"
                 target="http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4212635">
        <front>
          <title>Energy Consumption of Always-On Applications in WCDMA
          Networks</title>

          <author fullname="Henry Haverinen" initials="H." surname="Haverinen">
            <organization>Nokia Enterprise Solutions</organization>
          </author>

          <author fullname="Jonne Siren" initials="J." surname="Siren">
            <organization>Nokia Enterprise Solutions</organization>
          </author>

          <author fullname="Pasi Eronen" initials="P." surname="Eronen">
            <organization>Nokia Research Center</organization>
          </author>

          <date day="" month="April" year="2007" />
        </front>
      </reference>

      <reference anchor="ECN" target="http://ecn.ethz.ch/ecn-pam15.pdf">
        <front>
          <title>Enabling Internet-Wide Deployment of Explicit Congestion
          Notification</title>

          <author fullname="" initials="" surname="">
            <organization>B. Trammell, M. K&uuml;hlewind, D. Boppart, I.
            Learmonth, G. Fairhurst, and R. Scheffenegger</organization>
          </author>

          <date day="" month="" year="2015" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
