> From [email protected] Wed Aug 13 12:41:34 1997
> To: [email protected]
> Cc: [email protected], [email protected], [email protected]
> Subject: Re: HTTP 1.1 pipelining & persistent connections query
> Date: Wed, 13 Aug 1997 15:41:24 -0400
> From: Curtis Villamizar <[email protected]>
>
>
> 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.
Yes it is. It is a problem because it is intended to occur,
and HTTP 1.1 causes it not to, because the 'optimization' -
that using the 'time since last received' was an assumption
that no longer applies.
> 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.
> 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).
Joe
----------------------------------------------------------------------
Joe Touch - [email protected] http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/
USC / Research Assistant Prof. http://www.isi.edu/lsam/
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:29 EST