Re: issue 381: Discovery of the support of the HTTP2 protocol: DNS-based Upgrade

I'm with will on this one - but even more so than it being a competitive
non-starter, adding latency to existing http/1 use cases is also something
to be avoided. The interactive web is a different beast than smtp.


On Thu, Feb 27, 2014 at 7:34 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> On Thu, Feb 27, 2014 at 11:15 AM, Josh Goodall <joshua.goodall@gmail.com>wrote:
>
>> Hi,
>>
>> On 19 Feb 2014, at 12:02 pm, William Chan (陈智昌) <willchan@chromium.org>
>> wrote:
>>
>> >> A strong +1 for mandating SRV for HTTP/2.x discovery, because:
>> >
>> > I'm open to speccing out SRV for HTTP/2 and potentially using it. But
>> > I think mandating it is silly.
>>
>> Ah, yes. To clarify in standards language: I think support for SRV lookup
>> in clients is a MUST not a MAY, and for the hosting setup probably a
>> SHOULD[1].
>>
>> I also think it should be preferred, that is, the raw IPv4 and IPv6
>> address record queries should be tried only after a query for SRV records
>> has failed - and yes this means hosting providers who don’t adopt SRV in
>> their DNS will bear the burden of a triple, rather than a single lookup.
>>
>
> It'd be curious to see which client would respect this MUST and the
> preference ordering you described. Let's review the game theory behind
> moving first here. If I own a popular client and I switch to mandatory SRV
> lookup, and don't issue A and AAAA queries until the SRV lookup fails, then
> for the services and paths where SRV lookup doesn't work, user experience
> will be vastly degraded. I'm not sure how long a timeout would be, but if
> you hit the timeout, that's probably a horrible user experience. This is
> probably enough, at least for browser users, for them to switch to other
> browsers which don't feel as slow. I don't think any browser vendor would
> want to move first here. Indeed, I think the user experience cost is
> terrible enough that I don't see any browser vendor moving at all here.
>
> Note that none of what I've said necessarily applies to optionally doing
> SRV and using it when the results are available. It's mostly the MUST
> requirement and the serial behavior you've outlined that looks troubling
> from an actual deployment viewpoint.
>
>
>>
>> Note that this semantic has precedent - it is how the transition to MX
>> records for email delivery was made and is called the “implicit MX” rule. I
>> think HTTP/2.x should have a similar “implicit SRV” rule as the wise way to
>> define the behaviour. See RFC5321 s5.1.
>>
>> So the positive incentive is declarative DNS support for h2 upgrade,
>> which conveniently also supplies adequate support at last for IPv6, apex
>> naked domains, alternative ports and the other benefits of SRV[2]. And
>> performance becomes a stick to drive the adoption donkey.[3]
>>
>>
>> > It's not immediately clear to me the extent to switch you are pushing
>> > back on A record use. Do you think in-band discovery (well,
>> > advertisement) via TLS-ALPN or HTTP Upgrade are acceptable mechanisms?
>>
>> Yes. I'm not suggesting those should be out.
>>
>>
>> regards
>> Josh.
>>
>>
>>
>> [1] This is a compromise. If one were designing a new protocol with no
>> legacy concerns then I would strongly push for SRV as the only acceptable
>> DNS record type for server discovery.
>>
>> [2] Fallback server & weighted-round-robin if you want them.
>>
>> [3] I know Eliot has expressed concerns about both future-proofing for
>> h3, and for resolver performance at the <10% of sites that have zone cuts
>> at _tcp.example.com in their public DNS. However, I think those are both
>> manageable issues and do not outweigh the benefits of a DNS record that is
>> immediately supported by practically all servers & hosting providers, and
>> that solves several other lingering problems right off the bat.
>>
>>
>