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

+1.  In addition, there is a bad case here where adding a new level of DNS query is subject to packet loss 1% of the time which can incur a long timeout.

Thanks!!

-Robt

From: patrick.ducksong@gmail.com [mailto:patrick.ducksong@gmail.com] On Behalf Of Patrick McManus
Sent: Thursday, February 27, 2014 8:02 PM
To: William Chan (陈智昌)
Cc: Josh Goodall; IETF HTTP WG
Subject: 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<mailto:willchan@chromium.org>> wrote:
On Thu, Feb 27, 2014 at 11:15 AM, Josh Goodall <joshua.goodall@gmail.com<mailto:joshua.goodall@gmail.com>> wrote:
Hi,

On 19 Feb 2014, at 12:02 pm, William Chan (陈智昌) <willchan@chromium.org<mailto: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<http://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.