Discuss.

1
Discuss.

There's this fundamental mistake in a lot of high
bandwidth TCP stuff The AIMD TCP scheme has an
average operating point lets call it 2/3W
though it varies between W and ½W, and does so
every W RTTs - so with a W of 1000 packets, and
RTT of .1 sec, you get to average your rate
over 100 sec. But the same papers that complain
about this problem, talk about TCP connections
that last "hours and send terabytes of data.
However the fact that the rate varies around the
correct operating point is really irrelevant,
unless you actually want timely delivery of
_intermediate_ data, or unless you are the sole
user of an end2end path....neither case is
consistent with GRID FTP usage in reality So as
long as losses are uncorrelated in time (i.e.
whether "congestive" due to the peak of the
AIMD, or random due to noise, so long as for
different connections, they are out of phase) I
just don't recognize this as a real problem for
most people. The measurement cases we are seeing
are for special links for early test data - if
they ran with lots of connections through the
"bottleneck", with different tailcircuits,
then we just wouldnt see the "problem".... A
rate based (ECN) driven TCP would choose the SAME
rate as the midpoint of the AIMD - its main
_real_ benefits are 1/ you dont need a
(bandwidthdelay)'s worth of buffer in the
bottleneck router to accommodate the
peak of the AIMD sawtooth 2/ you _can_
deliver intermediate data in a timely way
3/ you get to work with SACK correctly when the
random loss rate is significant compared to 1
packet per W RTTs