One document matched: draft-kuehlewind-tcpm-ecn-fallback-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="exp" docName="draft-kuehlewind-tcpm-ecn-fallback-00.txt">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="no"?>
<?rfc symrefs="yes"?>

<front>
  <title abbrev="ECN Fallback">
    A Mechanism for ECN Path Probing and Fallback
  </title>

  <author fullname="Mirja Kuehlewind" 
          initials="M." surname="Kuehlewind">
    <organization>University of Stuttgart</organization>
    <address>
      <postal>
        <street>Pfaffenwaldring 47</street>
        <city>70569 Stuttgart</city>
        <country>Germany</country>
      </postal>
      <email>mirja.kuehlewind@ikr.uni-stuttgart.de</email>
    </address>
  </author>

  <author initials="B." surname="Trammell" fullname="Brian Trammell">
    <organization abbrev="ETH Zurich">
      Swiss Federal Institute of Technology Zurich 
    </organization>
    <address>
      <postal>
        <street>Gloriastrasse 35</street>
        <city>8092 Zurich</city>
        <country>Switzerland</country>
      </postal>
      <phone>+41 44 632 70 13</phone>
      <email>trammell@tik.ee.ethz.ch</email>
    </address>
  </author>
  <date year='2013' />
  <area>Transport</area>
  <workgroup>TCPM Working Group</workgroup>
  <abstract> 

	  <t>Explicit Congestion Notification (ECN) is a TCP/IP extension that is
	  widely implemented but hardly used due to the perceived unusablilty of ECN
	  on many paths through the Internet caused by ECN-ignorant routers and
	  middleboxes. This document specifies an ECN probing and fall-back 
      mechanism in case ECN has be successfully negotiated between two
      connection endpoints, but might not be usable on the path.</t>

  </abstract>
</front>

<middle>

<section title="Introduction" anchor="sec-intro">

  <t>The deployment of <xref target="RFC3168">Explicit Congestion Notification
  (ECN)</xref> and AQM would arguably improve end-to-end performance in the
  Internet, by providing a congestion signal to the transport layer without
  relying on queue tail drop and packet loss. However, though ECN has been
  standardized since 2000, implementation and deployment have lagged
  significantly, in part due to the perceived unusablilty of ECN on many paths
  through the Internet caused by ECN-ignorant routers and middleboxes.</t>
  
  <t>Recent research by the authors <xref target="KuNeTr13"/> has shown
  accelerating deployment of ECN-capable servers in the Internet, due to the
  deployment of TCP stacks for which ECN is enabled by default. In addition,
  ECN is usable end-to-end on the vast majority of paths measured in this
  study: that is, a Congestion Experienced mark will cause a ECN Echo on the
  associated ACK. However, there still exist a non-negligible number of paths
  on which a successfully negotiated usage of ECN will not result in a
  connection on which congestion will be correctly echoed, or worse, leads to
  the loss of packets with CE or ECE set.</t>
  
  <t>This document presents an experimental, in-band, runtime method for
  determining the usability of ECN by a given traffic flow, based on the active
  measurement method described in <xref target="KuNeTr13"/>. If ECN is
  successfully negotiated but found by this method to be unusable, it can be
  disabled on subsequent packets in the flow in order to avoid connectivity
  problems caused by ECN-unusability on the path.</t>
  
</section>

<section title="ECN Path Capability Probing" anchor="sec-probing">
  
  <t>A TCP sender can determine whether or not its path to the receiver is usable for ECN using the procedure detailed below.</t>
  
  <t><list style="numbers">

      <t>The sender attempts to negotiate ECN usage as per Section 6.1.1 of
      <xref target="RFC3168"/>. If ECN is not successfully negotiated, the
      procedure ends, and ECN is not used for the duration of the
      connection.</t>
      
      <t>The sender disables the normal usage of ECN for the duration of the
      procedure, as the ECN codepoints are used for path probing. This means
      all segments are sent with the Non-ECN-Capable codepoint during this
      procedure unless otherwise stated. Moreover, the sender will only take
      loss as a congestion signal and will not react with window reductions to
      the ECN-Echo (ECE) feedback signal from the receiver during this
      procedure.</t>

      <t>The sender sets the Non-ECN-Capable codepoint in the IP header until
      it has completed sending the first N segments, where N is the size of the
      initial congestion window. Loss is used to discover congestion for these
      segments.</t>

      <t>The next three segments sent consist of the "CE probe": three segments
      are sent with the Congestion Experienced codepoint set.</t>

      <t>If all three of the CE probe segments are lost and must be
      retransmitted, the path is deemed not ECN-usable and the sender falls
      back as in <xref target="sec-fallback"/>.</t>
      
      <t>If the ECE flag is not set on the ACK segment(s) sent by the receiver
      acknowledging the CE probe segments, the path may or may not be usable,
      as that there might be middleboxes/gateways that (arguably correctly)
      clear CE on segments from end hosts, because they assume that congestion
      can not have occurred up to this point on the path. In this case, the
      sender may continue using ECN, because while it may not work for
      detecting congestion, the use of ECN does not negatively affect
      connectivity. Note that this behavior can be more precisely detected
      using ECN Nonce <xref target="RFC3540"/>.</t>
          
      <t>While the sender does not reduce the congestion window for the ECE
      segment(s) sent for the CE probe segments, it does set CWR on the
      subsequent segment sent.</t>
          
      <t>If no fallback has occurred by the time the ACK of the final CE probe
      segment is received, the path is deemed ECN usable, and the sender ends
      the probing procedure and proceeds to use ECN normally as in <xref
      target="RFC3168"/>.</t>

    </list></t>
    
    <t>As the probing begins after all the segments in the initial
    congestion window have been sent, it requires more than an initial
    congestion window plus 6 segments (3 CE probe + 3 duplicated
    ACKs) of available data to send. As this information is only available at
    the higher layer, a configuration option per connection should be provided
    to dis/enable ECN as well as ECN probing. Otherwise, ECN should not be
    enabled for such short flows while using this procedure.</t>

</section>

<section title="ECN Fallback" anchor="sec-fallback">
  
  <t>If ECN is found to be unusable on a given flow by path capability probing
  as in <xref target="sec-probing"/> above, the sender simply stops setting any
  ECN-Capable-Transport codepoint on subsequent packets in the flow. The
  receiver MUST, however, still set ECE on any ACK for a packet with CE set.
  Note that this behavior is consistent with section 6.1.1 of <xref
  target="RFC3168"/>.</t>
  
  <t>A sender may keep a cache of paths found to be unusable for ECN and
  disable ECN for subsequent connections on a per-destination basis. In this
  case, the reciever should periodically (i.e., on the order of hours or days)
  expire these cache entries to cause re-probing to occur in order to account
  for routing changes in the network.</t>
  
  <t>[EDITOR'S NOTE: what to do on RTO?]</t>
  
</section>

<section title="Discussion" anchor="sec-discussion">
  
  <t>[EDITOR'S NOTE: need to think about how this would interact with conex; an analysis comparing the delay caused by path probing as opposed to the delay caused by ECN failure would be interesting.]</t>

  <t>[EDITOR'S NOTE: initial implementation results go here?.]</t>

</section>

<section title="Security Considerations" anchor="sec-security">

  <t>[FIXME: we'll have to explore attacks against this mechanism which could
  affect network or connection stability, so the following is wrong...]</t>

  <t>This document has no security considerations.</t>

</section>

<section title="IANA Considerations" anchor="sec-iana"> 

  <t>This document has no IANA considerations.</t>

</section>

</middle>

<back>

<references title="Normative References">
  <?rfc include="reference.RFC.3168" ?>
</references>

<references title="Informative References">

  <?rfc include="reference.RFC.3540" ?>
  <reference anchor="KuNeTr13">
    <front>
      <title>On the state of ECN and TCP Options on the Internet</title>
  
      <author initials="M." surname="Kuehlewind">
        <organization>University of Stuttgart</organization>
      </author>
      <author initials="S." surname="Neuner">
        <organization>University of Stuttgart</organization>
      </author>
      <author initials="B." surname="Trammell">
        <organization>ETH Zurich</organization>
      </author>
      <date month="Mar" year="2013"/>
    </front>
    <annotation>(In LNCS 7799, Proceedings of PAM 2013, Hong Kong)</annotation>
  </reference>
  
</references>

</back>
</rfc>