Re: comments on draft-mbelshe-httpbis-spdy-00

As a general principle I suggest:

* HTTP/2.0 discovery MUST be at least as good at establishing a
connection as the current protocol in every network situation
including cases where access is restricted by intermediaries and the
server only supports HTTP/1.1 or 1.0.

* HTTP/2.0 SHOULD be at least as fast in the overwhelming majority of
cases but MAY be less performant in corner case situations, provided
the performance penalty is not too great.


We are NOT going for Pareto optimal here. It is quite OK for some
connections to be slower, provided that this is not a constant issue.

On Wed, Aug 15, 2012 at 7:40 PM, Adrien W. de Croy <adrien@qbik.com> wrote:
>
> ------ Original Message ------
> From: "Patrick McManus" <pmcmanus@mozilla.com>
>>
>> sorry - too much shorthand. This is for http:// urls of course..
>> https:// can just use npn on the A address.
>>
>> race A and SRV queries.. make best practice to bundle SRV answers as
>> additional information in responses to A queries. Best experience
>> returns an A bundled with SRV.
>>
> problem with this, is that now you need to wait for your DNS server vendor
> to give you a new DNS server you can use to do this.
>
> I think making an additional requirement to deploy a new DNS server will be
> a bit of a show-stopper.
>
> I think it would be easier to just request both, and wait for both
> responses.  That's if we decide SRV is the way to go.
>
> But like Elliot, I'm not convinced SRV is right for this problem.  It
> provides a port number and a weight.  There may be some use for the weight,
> but the port number is problematic, since we're talking about using 80/443.
> Which port number is used?  What if the URL contains a port number etc?
>
> Maybe it would be simpler to just do an optimistic A record lookup.  E.g.
> prepend some well-known token, such as
> _http2.www.example.org.
>
> if you get a record back, you know it supports http 2.  If you don't you
> just look up www.example.org.  these 2 requests can be fired off in
> parallel.
>
> That makes it a lot easier to deploy on the server and client side as well,
> since the domain operator only needs to publish additional A records, and
> client doesn't need to do SRV lookups.
>
> I'm pretty sure most people will hate that idea though.
>
> Adrien
>
>
>> But if you get an A without a bundled SRV
>> then go ahead and use it immediately for HTTP/1 and allow a
>> upgrade/alternate-protocol to do the bootstrapping that less ideal way.
>>
>> So its just an optimization.
>>
>> On Wed, 2012-08-15 at 10:19 -0700, William Chan (陈智昌) wrote:
>>
>>>
>>> Can you elaborate how SRV would work here from a client perspective?
>>> Do you propose making the client block on the SRV lookup? Or are you
>>> proposing doing this out of band and switching to HTTP/2.0 if we
>>> discover support?
>>>
>>>
>>> http://code.google.com/p/chromium/issues/detail?id=22423#c9 has some
>>> of our thoughts on SRV in Chromium.
>>>
>>>
>>>
>>> On Wed, Aug 15, 2012 at 6:00 AM, Patrick McManus
>>> <pmcmanus@mozilla.com> wrote:
>>>        On Tue, 2012-08-14 at 12:24 -0400, Phillip Hallam-Baker wrote:
>>>
>>>        > If we take architecture seriously, the primary signaling
>>>        mechanism for
>>>        > HTTP/2.0 should be some form of statement in a DNS record to
>>>        tell the
>>>        > client 'I do HTTP 2.0'. We might also have some sort of
>>>        upgrade
>>>        > mechanism for use when the DNS records are blocked but that
>>>        should be
>>>        > a fallback.
>>>
>>>
>>>        This is my current thinking as well though I'm not tied to
>>>        it.. srv in
>>>        the base case (with the possibility of dnssec) and something
>>>        like
>>>        upgrade/alternate-protocol over HTTP/1 as a slower fallback.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>



-- 
Website: http://hallambaker.com/

Received on Wednesday, 15 August 2012 23:50:30 UTC