Re: multiplexing -- don't do it

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



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

Mike





> ....Roy
>
>