Re: multiplexing -- don't do it

On Mar 31, 2012, at 4:11 AM, Mike Belshe wrote:
> On Sat, Mar 31, 2012 at 8:57 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2012-03-31 01:53, Mike Belshe wrote:
> ...
> 
> Before thinking this way we should look at how well other mandatory but
> optional to use features have turned out.
> 
> One such example is pipelining.  Mandatory for a decade, but optional to
> implement. We still can't turn it on.
> ...
> 
> But then many people have it turned on, and it seems to be on by default in Safari mobile. Maybe the situation is much better than you think.
> 
> The data is overwhelming that it doesn't work.

It works just fine.  The data shows only that a general-purpose browser,
that doesn't even bother to report the nature of network protocol errors,
encounters a small percentage of network problems that exceed its users'
tolerance for failure conditions because its users have no control over
their network.  That might indicate that the browser cannot deploy it, or
it might indicate that there was a protocol bug on the browser that failed
on edge cases (just like Netscape 1-3 had a buffer reading bug that would
only trigger if the blank line CRLF occurred on a 256 byte buffer boundary).

It doesn't indicate anything about whether the feature works in HTTP for
clients that are not browsers or for networks where the administrators
do control their own deployment of intermediaries.

> Data points:
> a) chrome study showing connectivity results on port 80, 443, and 61xxx for websockets showed >10% failures on port 80 for non HTTP protocols.

Unrelated to pipelining.

> b) no major browser has deployed pipelining.  It's not like we don't want to.  We all want to!  Ask Patrick McManus for details - to think this works is just wishful thinking. If all we had to do was turn on pipelining 3 years ago, we would have done it.

Major browsers care about all networks and all customers. Most of the clients
on the Web are not major browsers.  Most of the systems on the Web that use HTTP
pipelining deploy it within environments wherein they do control the network
and can rubbish the stupid intermediaries that fail to implement it correctly.
The rest can and do tolerate 5% failure rates because they actually report
errors to the user and then the user fixes their own network problem.

> For the record - nobody wants to avoid using port 80 for new protocols.  I'd love to!  There is no religious reason that we don't - its just that we know, for a fact, that we can't do it without subjecting a non-trivial number of users to hangs, data corruption, and other errors.  You might think its ok for someone else's browser to throw reliability out the window, but nobody at Microsoft, Google, or Mozilla has been willing to do that...
> 
> As for mobile safari - I mentioned this in my talk the other day - its a bit of a conundrum.  Android's browser (not chrome) also turns on pipelining.  But I know that neither Apple nor the Android team have produced data or analyzed the success or failures of pipelining.  Mobile browsing is downright awful (due to bad content, networking errors, and other things).  It could be that mobile networks have fewer interfering proxies, or it could be that these errors are just getting blamed on other mobile network glitches.  I honestly don't know.  I'd love to see data on the matter.

Mobile networks use proxies that are owned by the mobile network.
That is why they can and do implement pipelining.

We have to realize that HTTP is used everywhere.  The problems you
have encountered while writing a general-purpose browser are not the
same problems that I encounter while writing a spider and a content
management system, what Samsung encounters when writing a TV and a
refrigerator, what Willy encounters while writing a proxy, etc.
There is no universal set of features for HTTP.

I have seen dozens of systems over the years deploy products that are
entirely dependent on chunked requests and never see a single problem
with them because they are interacting with an Apache module that uses
the chunked parser that I wrote.  They don't give a rat's ass about your
experience with a general-purpose browser making use of general Internet
access without any control over the intermediaries.  That is not a problem
they share.

They still need a standard for HTTP that includes the features they use.

> Either way - until someone produces data to contradict the current major browser data - we need to stop dreaming that port 80 is viable for anything other than pure HTTP.  The data we have says its not.

You must be thinking of some other thread.  An exchange over port 80 will
either work or it will not -- the trick is to design the protocol so that
it can succeed, or fails in a safe and recognizable way.

> Either produce new data or admit you don't know and trust what the browser developers are telling you.

Hah!  That's a good one.

Regardless, I consider some form of multiplexing to be a requirement for
whatever replaces HTTP/1.1, since there is no better reason to replace
HTTP/1.1 (tokenizing or compression are hardly worth the bother given how
quickly mobile is catching up to PCs).  I'd rather just replace TCP;
I expect that we'll need a protocol that can operate over multiple mux
and non-mux transports, because HTTP/1.1 works right now over many more
transports than just TCP and TLS.  But mux over TCP is a reasonable start.

....Roy