Notes on Evaluating ECN:

* Sack TCP:
Use SACK TCP, not Reno TCP.  Reno TCP is known to have serious
performance problems with multiple packets are dropped from a window
of data, and this could unnecessarily skew the results (showing
benefits of ECN that might be less pronounced with SACK instead of
Reno TCP).

* Rich traffic scenarios:
Whether in simulations or experiments, it is useful to use reverse-path
traffic (with TCP connections in both the forward and reverse
directions), and to use connections with a range of round-trip
times.

* Bursty traffic:
Increasing the burstiness of the aggregate traffic (e.g., by including
congestion on the reverse path, and by including traffic from a web
traffic generator, and by including traffic with a wide range of
round-trip times) will change the traffic dynamics, and will change
the relative benefit (or lack of benefit) in using ECN.

* Per-packet delay:
One metric of interest is per-packet delay, even in the absence of
real-time traffic (if only for the user who likes to see steady
progress reported in the downloading of a file).

* The distribution of download times:
Another metric of interest is the overall distribution of download
times for small files.  In many cases the use of ECN might not make
a big difference in the *average* download time of small files, but
might make a significant difference in the upper tail of the
distribution (that is, the fraction of small files that have
uncomfortably large download times).  This metric is more likely
to be interesting in a scenario with moderate to large round-trip
times.

* Consider moderate packet drop rates: 
With large packet drop rates (e.g., 10% or more), I would assume that in
practice routers would switch from marking to dropping packets.  Thus,
the benefit or lack of benefit of ECN with extremely large packet drop
rates might be of purely academic interest.

With small packet drop rates (e.g., less than 1%), I would assume that
the difference in performance between ECN and non-ECN is also rather
small.

* Run multiple simulations:

It is good to run multiple simulations, to see how the performance
varies between two simulations using the same simulation scenario.

- Sally Floyd, April 2002