RE: HTTP Alternative Services Best Practices?

[Mike Bishop <[e-mail]>]

Saying that “persist=false would be deleterious” is a bit simplistic.  You wouldn’t use persist=false for your scenarios, true enough.  Persist=true is intended for alternatives that aren’t derived from the user’s network location, and therefore don’t need to be flushed when the network location changes.  (For example, this host also supports QUIC.)

However, there are other scenarios where it is location-dependent – a CDN routing you to a closer node because DNS or Anycast didn’t get you close enough, for example.  If you change networks, not only is the node you were directed to no longer your closest, it might actually be prohibited from serving users on other networks.

The right answer here is that you need to know which type of Alt-Svc you’re issuing.

From: QUIC <[e-mail]> On Behalf Of Ryan Hamilton
Sent: Monday, December 16, 2019 3:24 PM
To: Lucas Pardue <[e-mail]>
Cc: QUIC WG <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: HTTP Alternative Services Best Practices?

Thanks for raising this issue! I think documenting best practices/guidance would be a great idea. I think the Google servers advertise a 30 day expiration (because 24 hours is *really* short). Further, it turns out that Chrome implicitly assumes persist = true (because Chrome incorrectly doesn't implement persist = false). We have a bunch of deployment experience with this model which I think suggests that shorter ttls and persist = false would be have a deleterious impact on performance.

On Mon, Dec 16, 2019 at 4:02 AM Lucas Pardue <[e-mail]<mailto:[e-mail]>> wrote:
Hello QUIC and HTTP members,

HTTP Alternative Services (Alt-Svc) is specified in RFC 7838 which was published in 2016 [1].. Many of us are starting to use Alt-Svc and I wonder if its appearance of simplicity might cause some unintended effects on the Internet. In the 3 or so years since it was published, have any best practices emerged that might be useful to capture.

Major uses of Alt-Svc today in no particular order: switching to gQUIC (typically on the same port), switching to HTTP/3, Opportunistic Encryption (RFC 8164) [2], Opportunistic Onion (advertising .onion [3]), and traffic management by advertising alternatives with different destination IPs or network path characteristics..

Arguably, HTTP/3 will be the largest-scale deployed use case of Alt-Svc both in terms of advertisements and clients that take them up. Alt-Svc for this can be deceptively simple, which may lead to unexpected outcomes. For example, the minimal expression:

Alt-Svc: h3-24=":443"

invokes default values for parameters, "ma" is fresh for 24 hours and "persist" is false (i.e. clear alternative cache on network changes). One could imagine how this could cause bursts of activity at regular periods, or cascades due to end-user local conditions such as flocking or hopping.

Finally, the proposal for an HTTPSVC DNS record [4] might attract a different population of operator that is less familiar with the expected behaviour of Alt-Svc implementations.

Does anyone think it would be useful to share or document some guidance?

Cheers
Lucas

[1] https://tools.ietf.org/html/rfc7838
[2] https://tools.ietf.org/html/rfc8164
[3] https://tools.ietf.org/html/rfc7686
[4] https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-01