Comparing an old flow snapshot with some packet size data

Thu Aug 8 00:47:33 UTC 1996

> 
> In message <199608072217.AA02662 at 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
~~~~~~