A test suite for exploring delay-throughput tradeoffs.

This test suite illustrates the space of tradeoffs between
delay, throughput, and packet drop rates that characterize a particular
congestion control mechanism. 

The test suite use a dumbbell topology, with three access links on
each side.

There are K sets of scenarios, one for each link bandwidth in the list
of bandwidths for the congested link.  Each congested link has
a fixed propagation delay (normally 10 ms, except for the scenarios
for tranoceanic links and satellite links).  There are six different
propagation delays for the six access links, to give a realistic
range of round-trip times for that congested link.

For each Drop-Tail scenario set, five tests are run, with buffer sizes
of 10%, 20%, 50%, 100%, and 200% of the Bandwidth Delay Product
(BDP) for a 100 ms flow.  For each AQM scenario (if used), five tests
are run, with a target average queue size of 2.5%, 5%, 10%, 20%,
and 50% of the BDP, with a buffer equal to the BDP.

A realistic traffic generator is used.  The level of traffic should
be picked so that when a buffer size of 100% of the BDP is used
with Drop Tail queue management, there is a moderate level of
congestion (e.g., 1-2% packet drop rates when Standard TCP is used).
Alternately, a range of traffic levels could be chosen, with a
scenario set run for each traffic level (as in the examples
cited below).

For each test, three figures are kept, the average throughput, the
average packet drop rate, and the average queueing delay over the
second half of the test.

For each set of scenarios, the output is two graphs.  For the
delay/bandwidth graph, the x-axis shows the average queueing delay,
and the y-axis shows the average throughput.  For the drop-rate
graph, the x-axis shows the average packet drop rate, and the y-axis
shows the average packet drop rate.  Each pair of graphs illustrates the
delay/throughput/drop-rate tradeoffs for this congestion control
mechanism.  For an AQM mechanism, each pair of graphs also illustrates
how the throughput and average queue size vary (or don't vary) as a 
function of the traffic load.

Example:  Figures 1, 2, and 3 in "Adaptive RED: An Algorithm for
Increasing the Robustness of RED's Active Queue Management",
"http://www.icir.org/floyd/papers/adaptiveRed.pdf", show the
delay/throughput tradeoffs for TCP for a set of RED mechanisms.
Figures 4 and 5 show the loss-rate/tradeoff tradeoffs for TCP for
a set of RED mechanisms.  Instead of having a single line in each
graph, there are 11 lines in each graph, one for each traffic
intensity (represented by the number of long-lived flows, in scenarios
that also include web traffic and reverse-path traffic).
(Other citations that show delay-throughput tradeoffs?)

Conjecture:  It is clear that different queue management mechanisms
can have different delay-throughput tradeoffs.  E.g., Adaptive Virtual
Queue would allow quite low delay, at the expense of lower throughput.
I would conjecture that different congestion control mechanisms also
have different delay-throughput tradeoffs, both in Drop-Tail and in
AQM worlds.