HTTP Alternative Services Best Practices?

[Lucas Pardue <[e-mail]>]

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