In message <[email protected]>, [email protected] writes:
>
> > You are arguing that the current behaviour is wrong and that if it was
> > corrected, there is a greater change of "slamming shut" which simply
> > involves repeating slow start. There is a significant chance of
> > entering slow start on a short RTT path (>=T1 capacity and not more
> > than 500 miles since lower capacity or greater distance would be over
> > 10 msec) but if RTT is that small, the penalty for slow start (a few
> > RTTs of delay) is also very small. For large RTT, particularly
> > satellite links, there chance of having to repeat slow start is very
> > small and would generally be caused by an overloaded server.
>
> We have seen, with 100ms RTT and 16 KB outstanding (1.3 Mbps end-to-end
> BW), the TCP generate a burst of 12 packets at the line rate (10 Mbps
> on the local LAN), rather than space the packets out.
>
> This will (and probably already does) cause loss at the routers
> inbetween.
(1.3 Mb/s * 0.1 sec) / 8 bit/byte => 16KB
If the path is T1 or better it should have 16-32KB of buffering
minimum. If the bottleneck is >T1 there should be much more
buffering. The routers we use have 8MB per outbound interface. I
usually like to see about 5*D*BW on something as slow as T1 to support
lots of TCP flows. Typical router defaults are ~50 packets.
I suppose this is a problem if it causes prematurely exceeding RTO on
other connections due to a step in delay if the bottleneck is T1 and
RTT has been consitent prior to this (if RTO is fairly accurate).
> > With HTTP 1.0, the transfer of an inline image *always* starts with a
> > 3 way handshake and then slow start.
> >
> > If this is an argument against HTTP 1.1 it is a very weak one.
>
> How so? HTTP 1.1's behavior is intended to benefit the user,
> but was not (I hope) intended to do so at the expense
> of anti-social behavior with respect to other connections.
>
> Bursting at line rate is antisocial. 1.1 triggers that
> phenomenon (granted - it should be fixed in TCP where
> it's broken).
Ay least we agree that we should fix the problem where the problem is,
in TCP.
Curtis
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:29 EST