[Ipv6-techsig] [???] ECN uptake evaluation

[sje2 at cs.waikato.ac.nz]

Hello,

I am a Post Graduate Diploma Computer Science student at Waikato University.

Earlier this semester in a networks course, we looked at some enhancements
to the Internet, including Explicit Congestion Notification (ECN).  The
purpose of ECN is to signal congestion to TCP without dropping a packet. 
The authors of a study on this reported [1] that ECN uptake was limited
for Ipv4 in years 2000 and 2004.  On learning about these results for
Ipv4, I wondered what the situation is now in 2009 for IPv4 and IPv6. 
This motivated me to do my research study for that course on the question
of to what extent the ECN enhancement has been implemented in the
Internet, and in particular to what extent in the context of IPv6.

I started this research project by looking at how the authors of the
previous study [1] implemented their analysis of ECN, in a program they
called TBIT which analysed a variety of enhancements of TCP.  I did an
implementation of TBITs ECN test, which carried out analyses of web
servers in parallel, and inluded IPv6 testing.

The procedure is to attempt to negotiate an ECN connection.  This involves
sending a TCP SYN packet with ECN echo (ECE) and Congestion Window Reduced
(CWR) bits set.  ECE and CWR are both flags in the TCP header.  The remote
host accepts ECN by replying with a SYN ACK packet with ECE set. 
Negotiation fails if ECE is not set or both ECE and CWR are set.  The
program then sends an ACK packet containing Congestion (CE) and ECN
Capable Transport (ECT) bits set faking congestion and an HTTP request in
the payload.  The CE and ECT bits are contained in the IP header and in
IPv6 they are the two bottom bits of the traffic class field.  Typically
an immediate ACK ECE is received followed by another which contains data
in response to the HTTP request.  If no initial connection was achieved, a
normal SYN packet is sent without ECE and CWR.  The program waits for a
normal SYN ACK to confirm that a normal connection can be achieved.  The
program records information about the responses of the remote host.

TBIT Scamper was used to evaluate the ECN performance of a set of popular
websites from alexa.org, but many less than the authors of [1] used.

                2000     2004     IPv4 2009  IPv6 2009
Hosts           24030    84394    414        305
Not ECN capable 90%      93%      96%        73%
ECN capable     1.1%     2.1%     2.6%       2.6%
 no ECN echo    1.1%     1.5%     0.5%       0%
 ECN echo       0.1%     0.5%     2.2%       2.6%
Bad SYN/ACK     0.0      0.2%     2.2%       0%
No connection   9%       3.8%     1%         21.6%
 only with ECN  9%       1%       0%         0%
 without ECN    0%       2.8%     1%         21.6%
HTTP error      -        0.4%     0.2%       1.6%
No data rec.    -        0%       0%         0.6%

The ECN capable values are a little higher than in 2000 and 2004 [1].  In
the IPv6 experiment, all gave an ECN echo when presented with a packet
with CE set.  This may reflect a reduction in interference of middleboxes
with ECT and CE flag transmission in IPv6.

In all cases 'no connection' were 'without ECN'.  This indicates that the
problem with middle boxes for this aspect is not apparent as it was
previously [1], as the presence or absence of ECN negotiation makes no
difference to the ability to connect for this population.

In my experiments it continues to be the case that ECN deployment is not
prevalent, but there may now be less impediment to its implementation.

Stephen Eichler

[1] http://portal.acm.org/citation.cfm?id=1064418  Measuring the evolution
of transport protocols in the Internet.  Medina A., Allman M., Floyd S.,
ACM SIGCOMM Computer Communications Review, 2005, volume 35, number 2.
[2] http://www.wand.net.nz/scamper/