In message <199608072217.AA02662@interlock.ans.net>, "Daniel W. McRobb" writes:
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 persistent connections. 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. :-( Daniel ~~~~~~