Re: TCP (and SCTP) sucks on high speed networks

["Steven M. Bellovin" <smb@research.att.com>]

In message <3A2756C9.EF5F252D@agilent.com>, Matt Wakeley writes:
>TCP's "congestion avoidance" algorithms are not compatible with high speed,
>long distance networks.  The "cut transmit rate in half on packet loss and
>increase the rate additively" algorithm will simply not work.
>
>Consider a 10Gbs link to a destination half way around the world.  A packet
>drop due to link errors (not congestion or infrastructure products) can be
>expected about every 20 seconds.  However, with a RTT of 100ms (not even
>across the continent), if a TCP connection is operating at 10Gbs, the packet
>drop (due to link error) will drop the rate to 5Gbs.  It will take 4 *MINUTES*
>for TCP to ramp back up to 10Gbps.
>
>Therefore, there needs to be a change to TCP's congestion avoidance algorithm
>for future high speed networks.  Since SCTP is based on the same algorithms,
>it is doomed to the same fate.

Probably correct.  And?

We, as a profession, don't know how to do better today, in the sense that 
we don't have a solution that is (a) rationally deployable, (b) solves this 
problem, (c) is "TCP-friendly", in the sense that it doesn't have undue 
negative impact on existing RFC-compliant TCP streams, and (d) is 
reasonably compliant with the Internet and the Internet philosophy.
I'd love to see such a solution, but it is a research question.  We're 
not going to solve it now, in the IPS working group.

For us, I think the challege is three-fold:  to define iSCSI et al. so 
that they can run at link speed over high-speed, local nets; to design 
them in such a way that they are compatible with TCP and the Internet 
over a broad range of networks (where, for example, you're not likely 
to get 10G bps in one flow, no matter what, if for no other reason than 
that most folks won't have access lines that are that fast); and to do 
the design in a way that is, as much as possible, transport-protocol 
independent, so that it can be rehomed to HS-TCP if and when it is 
developed.

		--Steve Bellovin