W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: multiplexing -- don't do it

From: Mike Belshe <mike@belshe.com>
Date: Tue, 3 Apr 2012 17:19:22 -0700
Message-ID: <CABaLYCsvWkLJ0JVwdNY13HMxnvftZ1sEyhHuJEdRM2PAf=N=Tw@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Tue, Apr 3, 2012 at 3:23 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> 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.

If you've got data that shows differently, I'm happy to view it.  But, to
dismiss the only data we have measured right now doesn't seem prudent?

I would very much like to have data from multiple vendors on this issue,

> 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.

Very related to the deployability of new protocols over port 80.

> 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.

I thought a requirement of HTTP/2.0 is that we could deploy it on major
browsers on the Internet - is that not a requirement?

> 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.

You're speculating, right?  How do you know that mobile networks don't have
pipelining problems?  Have you measured?

> 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.

Dedicated networks may have different properties.  But anyone using HTTP
over the general internet will likely run into similar problems that
browsers do.  I thought we wanted this to work over the Internet?

> 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.

I'm really asking for help here; I'd love to see more data.

> 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.

I'm sure you know this, but RFC2616 does not run over arbitrary transports.
 Different transports have different features, and that means HTTP maps
onto them differently.  TCP offers a single, bidirectional stream.  SCTP
offers multiple, unidirectional streams.  In order to define how RFC2616
maps onto SCTP, a separate definition was needed:
http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01.   It's not a
complicated definition, but its not the only way to map HTTP onto SCTP.


> ....Roy
Received on Wednesday, 4 April 2012 00:19:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:59 UTC