A Mechanism for ECN Path Probing and Fallback
University of StuttgartPfaffenwaldring 4770569 StuttgartGermanymirja.kuehlewind@ikr.uni-stuttgart.de
Swiss Federal Institute of Technology Zurich
Gloriastrasse 358092 ZurichSwitzerland+41 44 632 70 13trammell@tik.ee.ethz.ch
Transport
TCPM Working GroupExplicit 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.The deployment of Explicit Congestion Notification
(ECN) 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.Recent research by the authors 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.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 . 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.A TCP sender can determine whether or not its path to the receiver is usable for ECN using the procedure detailed below.The sender attempts to negotiate ECN usage as per Section 6.1.1 of
. If ECN is not successfully negotiated, the
procedure ends, and ECN is not used for the duration of the
connection.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.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.The next three data segments sent consist of the "CE probe": these
three segments are sent with the Congestion Experienced codepoint set.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 .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.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.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 .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 .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 .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.If ECN is found to be unusable on a given flow by path capability probing
as in 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 .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.[EDITOR'S NOTE: what to do on RTO?][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.][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.][EDITOR'S NOTE: initial implementation results go here?.][FIXME: we'll have to explore attacks against this mechanism which could
affect network or connection stability, so the following is wrong...]This document has no security considerations.This document has no IANA considerations.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.On the state of ECN and TCP Options on the InternetUniversity of StuttgartUniversity of StuttgartETH Zurich(In LNCS 7799, Proceedings of PAM 2013, Hong Kong)