MTU of the Internet?

Patrick McManus mcmanus at AppliedTheory.com
Mon Feb 9 14:25:03 UTC 1998


In a previous episode Phil Howard said...
:: 
:: 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).

At the risk of introducing meaningful background literature:
     ftp://ds.internic.net/rfc/rfc2068.txt

I direct folks to 14.36.1 "Byte Ranges" which when interleaved with
pipelined requests comes very close to achieving client-driven
multiplexing that I'd suggest from a UI pov will behave much better
than the multiple connections method (eliminating the cost of tcp
congestion control but at the cost of some application protocol
overhead). 

-P



More information about the NANOG mailing list