One document matched: draft-kuehlewind-tcpm-ecn-fallback-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="exp" docName="draft-kuehlewind-tcpm-ecn-fallback-01.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' month="September" day="10" />
<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 data 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 data segments sent consist of the "CE probe": these
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 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.</t>
<t>While the sender does not reduce the congestion window for the ECE
ACKS acknowledging the 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>The operation of this procedure on an ECN-usable path, with an initial window size of 3, bulk data transfer initiated by the sender, where the receiver does not perform probing, is shown in <xref target="fig-probe-yay"/>.</t>
<?rfc needLines='27' ?>
<t><vspace blankLines='66'/></t>
<figure anchor="fig-probe-yay" title="CE probing on ECN-usable path"><artwork><![CDATA[
Sender Receiver
| |
|----SYN ECE CWR----------->| connection
|<-----------SYN ACK ECE----| establishment
|----ACK------------------->|
| |
|----data 0---------------->| initial window
|<------------ECT0 ACK 1----| transmission
|----data 1---------------->|
|----data 2---------------->|
|<------------ECT0 ACK 3----|
| |
|----data 3 CE------------->| CE probe
|----data 4 CE------------->|
|----data 5 CE------------->|
|----data 6 --------------->|
|<--------ECT0 ECE ACK 7----| CE probe ACK: ECN OK
| |
|----data 7 ECT0 CWR------>| CE probe CWR
|----data 8 ECT0---------->| and transition to
|----data 9 ECT0---------->| normal ECN usage
]]></artwork></figure>
<t>Conversely, the operation of the probe and fallback procedure on an ECN-unusable path with an initial window size of 3, bulk data transfer initiated by the sender, where the receiver does not perform probing, is shown in <xref target="fig-probe-boo"/>.</t>
<?rfc needLines='24' ?>
<t><vspace blankLines='66'/></t>
<figure anchor="fig-probe-boo" title="Fallback on ECN-unusable path"><artwork><![CDATA[
Sender Receiver
| |
|----SYN ECE CWR----------->| connection
|<-----------SYN ACK ECE----| establishment
|----ACK------------------->|
| |
|----data 0---------------->| initial window
|<-----------------ACK 1----| transmission
|----data 1---------------->|
|----data 2---------------->|
|<-----------------ACK 3----|
| |
|----data 3 CE----X | CE probe
|----data 4 CE----X | (blocked)
|----data 5 CE----X |
|----data 6 --------------->|
|<-----------------ACK 3----| dupack
|----data 7 --------------->|
|----data 8---------------->|
|<-----------------ACK 3----| dupack
| |
|----data 3---------------->| retransmit without CE
|<-----------------ACK 4----|
|----data 4---------------->|
|<-----------------ACK 5----|
|----data 5---------------->|
|<-----------------ACK 9----| and fallback (no ECN)
|----data 9---------------->|
]]></artwork></figure>
<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.
TCP implementations can use socket send buffer occupancy as a signal as to
whether sufficient data is available to use the probing procedure. If
enough data is already in the buffer by the time the initial congestion
window is sent, then the probe segments SHOULD be sent. Otherwise, the
implementation can use additional heuristics, outside the scope of this
document to define, to determine if significant data is likely to be
available.</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: the general case of this algorithm is J ECT segments followed by K CE segments; we chose (J,K) = (0,3). We should justify this choice.]</t>
<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>
<section title="Acknowledgements" anchor="sec-ack">
<t>Thanks to Michael Welzl and Richard Scheffenegger for the comments and discussions. This work is partially materially supported by the European Commission under grant agreement FP7-ICT-318627 mPlane.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.3168" ?>
</references>
<references title="Informative References">
<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>| PAFTECH AB 2003-2026 | 2026-04-23 11:57:11 |