> > Persistant connections is a prominant feature of HTTP 1.1, now in
> > draft. Maybe someone who follows that WG can comment on its progress.
> > If on average there are 2-3 inline images per page (reasonable
> > estimate IMO, though I have no data to back this up), then the average
> > transfer size will increase. I've heard (verbal at NANOG) that
> > Netscape has promised to support persistant connections, with the only
> > caveat that they will open one connection for the page itself and
> > another for all the inlines so they can start rendering the first
> > inline while a long page is being read. They can probably avoid this
> > for short pages. This could lead to a significant improvement in the
> > ability of the Internet traffic to respond to low levels of packet
> > drop and make good use of TCP congestion control, plus it will
> > significantly improve the speed of transfer on uncongested paths where
> > currently TCP never gets out of the initial slow start.
> > Curtis
> I did some analysis of the FIX-West traces a while back and posted it to
> the nlanr mailing list. It's been so long that I don't remember what I
> posted, but I seem to recall trying to make a judgement as to how many
> packets we'd eliminate with a mass migration to HTTP 1.1 and/or HTTP
> with T/TCP. I recall a figure around 14%, but that's just from memory.
It is not a question of eliminating packets it is a question of
whether TCP ever gets out of slow start and gets to a reasonable
window size. It takes 4 RTT to send 1+2+4+1 for 8 data segments, then
you need to go through FIN handshake and SYN. If you do three images
you start with a new window for each or try to do them all at one you
can have 3 * 8 segments you have 1+2+4+1 either in sequence or at the
same time or 1+2+4+8+9 if you have a persistent connection. If the
pipe is overfull it is much easier to TCP rate limit the latter case
so you need to drop much fewer packets to keep things under control.
At 552, 8 segments is about 4K, which is about the average image size.
Of course it is one segment at FDDI MTU. Then it really pays to have
a persistant connection so you don't degrade to UDP characteristics.
I'm not discounting the importance of letting TCP get out of slow start
and to a reasonable window size. That's more important than the FIN/SYN
traffic (for the network). I _think_ what I had done with the FIX-West
traces was look at how many packets wouldn't be generated if HTTP used
T/TCP (or persistent connections... I don't remember which I did). I
did not try to account for what would happen due to a more reasonable
window size (which should happen for many (most?) WWW pages w/ HTTP 1.1)
and getting out of slow start. I only looked at how many of the packets
were setup/teardown traffic that wouldn't exist if T/TCP was used or
Of course, from what I've seen, there are some broken TCP
implementations out there, some with bizarre, nonsensical initial window
advertisements, some with overly-aggressive SYN retransmission, etc.
There also seem to be a decent number of clients with a low
advertised MSS (256), probably due to being at the end of a SLIP or PPP
connection with an MTU of 296.
This of course begs the question: just how much of a difference will
HTTP 1.1 make? I'm a tiny bit leery to answer that, since I keep seeing
stats indicating broken TCP implementations. I've even heard that
some PC WWW browsers allow the user to set the MSS and initial window
advertisement. I (for some reason) think it's unlikely that much of the
point-click crowd understands the implications.