MTU of the Internet?

Sun Feb 8 19:10:58 UTC 1998

Marc Slemko writes:

> Once again, HTTP/1.1 does _not_ allow multiplexing multiple transfers
> simlultaneously in a single TCP connection.  Multiple responses are
> serialized.

I think the confusion here is due to Paul's use of the term "serial
multiplexing" where he qualified it with "serial" to indicate that
one-at-a-time situation.  When I read it I wasn't sure if "serial"
meant to be that or meant to describe a kind of multiplexing over a
serial stream.  But given the HTTP 1.1 that I knew had a persistent
connection that allowed additional requests, I suspected that he was
referring to this.  But the term "multiplexing" by itself implies
concurrency.  While at the microsecond level it is one at a time,
but each channel isn't completed in those short durations.  My worry
was that others might have assumed there was some new true multiplexing
protocol for HTTP.  I've not heard of one, but even I wondered of one
I might have not heard of (and I don't keep track of all the protocols
out there).

> As I noted before, total transfer time for all the responses that make up
> one document in the client is not the metric that client vendors are
> trying to optomize and is not what most users care about.  

If it were, we'd probably see pages with all text, like the web once used
to be before it became commercialized.

-- 
Phil Howard | stop8894 at spammer5.edu end3it71 at dumbads8.net a4b2c0d5 at spammer3.com
  phil      | end0it89 at spammer5.net ads9suck at no5where.net crash089 at lame5ads.com
    at      | ads6suck at spam4mer.com suck9it9 at spam4mer.edu w2x8y4z4 at dumbads5.net
  milepost  | stop6231 at anywhere.edu eat8this at no5place.org die4spam at dumbads6.org
    dot     | w5x5y2z8 at anywhere.com eat64me7 at no3place.net end7it94 at spam7mer.org
  com       | eat2this at anyplace.edu ads7suck at nowhere0.edu crash309 at anywhere.com