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

[Cannara <cannara@attglobal.net>]

Sounds good.  Any improvement to the most common transport used today (it need
not ne TCP, of course) is welcome.  The remarks of Randall and some others
suggest that TCP's mission is congestion control, when it's both clear that
TCP does not do that accurately or completely and never has, because of how
and why it was designed and modified over the years.  

An excellent example of how "not changing TCP" is a meaningless goal or stand
is the use, every day, of TCP stacks on commercial gear that do things to
improve performance that purists would faint over -- such as ignoring the
receiver's window advertizement because the sender knows the receiver's
processor and stack are capable of doing more (this actually happens on one
well-known vendor's mirroring products).

The odd allegiance to an old piece of thinking and publicly-subsidized code
(TCP) is not surprising, but it ignores the reality that many other ways of
transporting data reliably exist, which then do not offer TCP's "congestion
control" to a network.  It's therefore clear that the network must be more
active and accurate in admitting and controlling flows for a variety of
transports, much as the telcos do with Frame Relay.  Therefore, SCTP and other
efforts are welcome.  They suggest we're thinking beyond '70s byte counting
and acknowledgment and finally realizing, after too many years, that the
network layer (e.g., IP) is where congestion needs handling -- oops, that's
the 'new' stuff on ECN for IP.  For all the public and private money that's
been spent on the Internet protocols, you'd think we'd be farther along.  But,
that's how established bureaucracies operate.  {:o]

Alex
-- 
Menlo Park, California

Kaleelazhicathu R R Kumar wrote:
> 
> hi,
>  On same lines we have proposed a change in the existing TCP stack by
> adding an additional option which will help TCP distinguish corruption
> from congestion and act accordingly. The paper has been accepted in
> INFOCOM 2001.We have found that this approach helps in improving the
> performance of TCP in higher corruption prone networks like the wireless
> to a greater extent.
>   Thanks.
>   Renjish.
> 
> It's not important to be the best, but the first.
> 
> On Thu, 30 Nov 2000, Matt Wakeley wrote:
> 
> > 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.
> >
> > -Matt
> >