[e2e] Open the floodgate - back to 1st principles

[Injong Rhee]

> -----Original Message-----
> From: end2end-interest-bounces at postel.org
> [mailto:end2end-interest-bounces at postel.org]On Behalf Of Guy T Almes
> Sent: Sunday, April 25, 2004 3:03 PM
> To: Jon Crowcroft; end2end-interest at postel.org
> Cc: Guy T Almes
> Subject: Re: [e2e] Open the floodgate - back to 1st principles
>
> During the last few years, it's become common to use multiple parallel
> Reno/AIMD TCP flows to move a single large file.  The idea is that, while
> one TCP stumbles, the others can proceed and make good use of the
> otherwise
> underutilized capacity.  This does not work as well as one would like,
> largely because these multiple flows tend to synchronize with each other,
> resulting in really really massive congestion/queueing periods and then
> (unless you use several dozen parallel flows) surprising periods of
> underutilization.
>

 This synchronization is exactly what we observed
in our simulation and also in some limited real network tests.
When many flows share the same end-to-end path and they are essentially
driven by
the "same" set of senders and receivers, there are a lot of synchronization.
Synchronization leads to network underutilization. Another big problem with
these multiple flows
is that it is hard to find the fair operating points with other competing
flows. Since
each flow is a TCP, the number of flows being employed for a transmission
determines
the amount of bandwidht to use -- our analysis shows the bandwidth usage
does not
increase linearly by the number of flows, but in fact by the sqaure of
that..So if we
use 3 TCP flows, it is not equalivent to AIMD with increments of 3, but of
9. However,
another thing we notice is that this increment factor also depends on the
amount of
synchronization  among these multiple flows -- a very interesting research
topic to figure
out this depedency.. Since a different user may use a different number of
TCP flows,
it is impossible to achieve fairness without some global management...(but,
I am not sure that congester manager idea can be applicable in this
context).

Then again, use of multiple flows is sometimes the only option with the
current NIC
performance. The current NIC (10Gbps) only gives around 2-3Gbps (if you are
a nice
guy, you might get 4-6Gbps :-). With this NIC performance, acheiving
something like the
full bandwidth util. of  tens of Gbps is not possible. You need to use
multiple NICs to achieve this. This end-host (NIC) bottleneck forces you to
use multiple flows anyway...now the question is back to square one...

These days, I am toying with the idea of using multiple flows, but this
time, *to emulate the behavior
of a single scalable flow*. A single scalable flow (of fast/hstcp/stcp/bic)
should give
 scalability, fairness, and stability (if their claims are right) -- so they
should give the full
utilitzation of the network (no matter how large it may be) because it is
scalable.
By emulating the flow, we retain its per-flow characteristics; if
successfully implemented,
this idea can give fairness and scalaibility and also overcome the end-host
bottleneck.
Very interesting research area, indeed.







---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.656 / Virus Database: 421 - Release Date: 4/9/2004