On Tue, 06 Feb 2001 22:30:06 CST, [EMAIL PROTECTED] (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
PGP signature
