In message <[email protected]>, [email protected] writes:
>
> > Another interesting point wrt HTTP 1.1 is that the first inline image
> > is ussually in the first TCP segment of HTML. If so, there is usually
> > a few more segments (average HTML file is 2-3KB, right?) so you don't
> > go idle. The idle occurs just after the ACK tells the sender that
> > there is no data in flight, not after the sender runs out of packets
> > to send. If the ACK is delayed (by the delayed ACK algorithm), it
>
> This is the current behavior, but not the intended (as proscribed
> in Jacobson's Sigcomm paper). The intended is 'when the sender
> goes idle', and it makes much more sense - the purpose is to avoid
> a line-rate burst at the sender. It doesn't matter when the acks
> arrive; it matters only whether the sender has accumulated more
> 'send privilege' than it has data to occupy.
>
> For restart, it appears the idle of interest is mainly between requests,
> given the relationship to RTO. There remains a possibility that slow systems,
>
> or systems that take a long time to parse requests or traverse their web
> filesystem may pause long enough for gaps, but this isn't likely on links
> over 10ms.
The bottom line is that the "slam shut problem" we've been discussing
is not a problem with current behaviour of TCP.
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.
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.
Curtis
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:29 EST