Re: #385: HTTP2 Upgrade / Negotiation

On 24/10/2012 5:51 p.m., Mark Nottingham wrote:
> On 24/10/2012, at 3:12 PM, William Chan (ι™ˆζ™Ίζ˜Œ) <willchan@chromium.org> wrote:
>>>>> Who's willing to do some experimentation? Specifically, does anyone have access to the code that was used before (IIRC, people bought some ads and inserted some Java to probe the network)?
>>>> Do you mean the Chromium HTTP upgrade experiment agl referred to in
>>>> http://www.ietf.org/mail-archive/web/tls/current/msg05593.html?
>>> No, IIRC there was also some broader experimentation using ads; I'll dig around a bit more.
>>>
>>> Of course, if Chrome (or any other browser) would be interested in running an experiment, we'd love to do that too -- provided we can have input into the design.
>> Is there anything you'd like to change about the design in
>> http://www.ietf.org/mail-archive/web/tls/current/msg05593.html? I'm in
>> general supportive of running experiments, I just don't want to waste
>> our time unless there was something deficient about the previous
>> experiment.
> Could you dig up the exact bytes-on-the-wire handshake that was used?
>
>
>> Also, I suspect a non-Google experiment would carry more
>> weight :) External validation is good.
> Agreed.
>
>
>> On that point, at Realtime Conf today, Arnout Kazemier provided a
>> bunch of data on issues with WebSockets deployment.
>> https://speakerdeck.com/3rdeden/realtimeconf-dot-oct-dot-2012. As he
>> says "tl;dl: Always use SSL".
>
> Thanks.
>
> I'd like to validate an assumption that has been discussed in-person in a meeting (forget which one) but IIRC not yet on-list.
>
> It's that if we can design an upgrade that fails fast and reliably for HTTP URLs, it's acceptable for there to be a (say) 70% success rate initially, with the idea that it will rise over time -- perhaps slowly, in terms of browser releases, but relatively quickly, in terms of the lifetime of HTTP.
>
> Can we (everyone) agree upon that?


I thought we are working from a baseline of Upgrade: being *the* 
existing defined HTTP/1.1 method for negotiation. Those Chromium 
experimentd proving it had ~67% success rate. Now just looking for ways 
to use it more efficiently and alternative methods that would improve 
that success rate faster?

> WRT WebSockets, keep in mind that the proxy/firewall/virus scanning vendors have had less than a year since it became an RFC, for a protocol that has (relatively) unproven demand and hard-to-nail-down semantics.
>
> I suspect that HTTP2, once we finish, will be get more priority from them; the demand is already proven, and the semantics of the protocol are easier to fit into their existing threat models, etc.
>


Amos

Received on Wednesday, 24 October 2012 08:40:41 UTC