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

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.
>
>