[15168] in North American Network Operators' Group
Re: MTU of the Internet?
daemon@ATHENA.MIT.EDU (Patrick McManus)
Mon Feb 9 12:21:21 1998
From: Patrick McManus <mcmanus@AppliedTheory.com>
To: phil@charon.milepost.com (Phil Howard)
Date: Mon, 9 Feb 1998 09:25:03 -0500 (EST)
Cc: marcs@znep.com, nanog@merit.edu
Reply-To: mcmanus@AppliedTheory.com
In-Reply-To: <199802081910.NAA31300@charon.milepost.com> from "Phil Howard" at Feb 8, 98 01:10:58 pm
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
