Re: HTTP Alternative Services Best Practices?

[Ryan Hamilton <[e-mail]>]

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