Header bytes (was Variant IDs)

Latency, latency, latency...  In the discussion below, I'm actually
ignoring the effects of data compression, which helps somewhat
in this case (at best a factor of two or three for plain text;
realistically, I see something like a factor of 1.5 on my home circuit).  

However, all such data compression schemes do hurt latency somewhat 
(you have to buffer bytes and think about them before you can transmit
compressed representation of those bytes).

1) not everyone runs with images turned on, particularly when using
the web via a low bandwidth line.

2) The web has become a mass media.   Extrapolating  from experience
on campus networks is NOT reasonable.

Home dialup speeds today are at best 28K baud.  This is now
the bulk of Internet usage. My understanding is that POTS performance 
via modems cannot get much better than it is. Here, one byte = ~.3 milliseconds.

While we can wave our hands and claim that telecommunications companies are 
going to fix this someday, the reality is that this is quite a few years off.
For example, even trials of high bandwidth Internet access at home
are rare today; deployment to scale is 5-10 years off.  

We may see widespread ISDN at 64Kbits/second somewhat sooner.  For ISDN,
one byte == .12 milliseconds.

3) The web is beginning to be used via cellular modems and from aircraft,
both on laptops and PDA's.

Today, these systems have bandwidths between 4800 baud (telephone on
airplane, as of last week on a 757) and 9600 baud.  Cellular IP, now
reaching trial status in this area, gets you up to the 19.2Kbaud range
if memory serves me right.  

When I talked to someone who knew something
about wireless services, he pointed out that to get higher wireless
bandwidth, you had to burn more power (which is in short supply on
the transmit side, and affects cell size in cellular systems); 
but right now such systems are symmetric, so it isn't
clear downstream bandwidth will be going up anytime soon.

So here, one byte == between 2 and .5 milliseconds.    


It doesn't take many bytes at any of these bandwidths
to add up to human perceptable time (~30 milliseconds).

I don't believe we can argue that the bandwidth fairy will
get us better bandwidth quickly to the bulk of retail users
today, and that it is far from clear that wireless will improve
anytime soon.

Any scheme that uses lots of bytes will fail in the general market, 
as a result, and this is the experience already observed by Netscape,
which has had demonstrably better performance than Mosaic did (partially
because of Mosaic's incredibly stupid accept header behavior) by observing
the latency problems caused by long headers, and working to fix this.

So my argument is that for content negotiation to actually get used,
it had better be implemented with the understanding that the bulk of
the Internet market is on low bandwidth lines, where every byte counts
(and where 1K byte is anywhere between 2 seconds and .1 seconds or
so to transmit).
				- Jim

Received on Thursday, 8 February 1996 17:37:54 UTC