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

Re: multiplexing -- don't do it

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 31 Mar 2012 10:17:38 -0700
Message-ID: <CAJE5ia9WNoCvtJikaeQ3zXqwx759BG+qqktYTfFDtRRr6wCAqg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Mike Belshe <mike@belshe.com>, Julian Reschke <julian.reschke@gmx.de>, "Adrien W. de Croy" <adrien@qbik.com>, Alexey Melnikov <alexey.melnikov@isode.com>, Roberto Peon <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Sat, Mar 31, 2012 at 4:54 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
> On 31/03/2012, at 1:11 PM, Mike Belshe wrote:
>
>> 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…
>
> Mike -
>
> I don't disagree on any specific point (as I think you know), but I would observe that the errors you're talking about can themselves be viewed as transient. I.e., just because they occur in experiments now, doesn't necessarily mean that they won't be fixed in the infrastructure in the future -- especially if they generate a lot of support calls, because they break a lot MORE things than they do now.
>
> Yes, there will be a period of pain, but I just wanted to highlight one of the potential differences between deploying a standard and a single-vendor effort.  It's true that we can't go too far here; if we specify a protocol that breaks horribly 50% of the time, it won't get traction. However, if we have a good base population and perhaps a good fallback story, we *can* change things.

That's not our experience as browser vendors.  If browsers offer an
HTTP/2.0 that has a bad user experience for 10% of users, then major
sites (e.g., Twitter) won't adopt it.  They don't want to punish their
users any more than we do.

Worse, if they do adopt the new protocol, users who have trouble will
try another browser (e.g., one that doesn't support HTTP/2.0 such as
IE 9), observe that it works, and blame the first browser for being
buggy.  The net result is that we lose a user and no pressure is
exerted on the intermediaries who are causing the problem in the first
place.

These are powerful market force that can't really be ignored.

Adam


> Just my .02.
>
>> 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.
>
> I tend to agree with the point you made in the meeting -- this probably falls into the noise of other errors / discomforts in the mobile world. Mobile users have low expectations.
>
> Cheers,
>
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>
>
Received on Saturday, 31 March 2012 17:18:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:57 GMT