ietf
[Top] [All Lists]

Re: An alternative to TCP (part 1)

2001-02-06 08:10:02
On Tue, 06 Feb 2001 22:30:06 CST, jag(_at_)kw(_dot_)com(_dot_)cn (Jun'an Gao)  
said:
1. There are two annoying incompetence of TCP. One is that TCP does not
   distinguish packet loss caused by network transmission error from that
   caused by network congestion. The congestion control and avoidance 
mechanism 
   makes TCP drop its transmit window upon detecting a packet loss, thus 
lowers
   the transmit rate even if the loss is caused by physical link transmit 
error.

This may have been an issue back in the days of noisy, error-prone modems.
These days, the *right* answer is to fix the hardware.  On the other hand,
I believe much of Van Jacobsen's initial tuning work on TCP had to do with
the fact that even on noisy lossy lines, some 95% of lost packets were due
to router congestion rather than actual mangling of bits on the wire.

Yes, I know parts of the world still have poor infrastructrure.  But even
there, error-correcting modems do wonders.

And if you're in an environment such as wireless where packets literally
DO dissapear into the ether on a regular basis even when there is no
congestion, RFC2018 describes 'Selective ACK' to allow recovery without
losing your window.

   The other is that the unit of TCP sequence number is byte (octet) while the
   the sequence number is only 32 bit wide. It is not a big problem for a
   no-more-than-100Mbps network. But in a modern gigabit network, it takes 
only
   about 36 seconds to consume the whole sequence number space when 
transmitting
   at the maximum bit rate.

RFC1323 addressed this issue in May 1992.

2. There is an observation that congestion control is somewhat the obligation
   of routing system. If it were to be done by the end host, an end host
   application might exploit UDP to avoid the congestion control of TCP.

In general, a router cannot *force* an end host to not send a packet.  The
best it can do is send a notification that if a packet *is* sent, it has a
high likelyhood to be dropped on the floor.

ICMP Source Quench - although as Van Jacobsen showed, the same effect can
be gotten just by treating a dropped packet as an implicit source quench.

   In fact the video stream applications have caused some network    
congestion troubles.

Well.. Yes.  RSVP and related are still more or less experimental...

<rest of note snipped - I didn't see where anything new was proposed that
isn't already in TCP-over-IP6+IPSec.>

-- 
                                Valdis Kletnieks
                                Operating Systems Analyst
                                Virginia Tech

Attachment: pgp9jJquginAk.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>