Re: multiplexing -- don't do it

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.

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.

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.

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.

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.

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

Mike




>  ...
>>
>> Options simply don't work - we need to make this stuff mandatory from
>> the get-go or it  is very likely to have the same result that we've seen
>> in the past.
>> ...
>>
>
> I don't think that's correct.
>
> Options do not work if and only if they are usually not switched on.
>
> For instance, if header compression is optional, but common UAs will use
> it by default, it *will* be implemented.
>
> Also, this is a feature that can trivially tested in a test suite.
>
> Best regards, Julian
>