Re: HTTP Alternative Services Best Practices?

[Lucas Pardue <[e-mail]>]

I agree with both of your points. IMHO there are a few patterns of
deployment that likely benefit from different approaches to Alt-Svc usage.
RFC7540 provides the toolkit but not everything is a hammer nor a nail.

In my original email I also neglected to mention the Alt-Used header or the
"clear" special value, which may have different considerations applicable
to different deployments. Is there much experience with these at Internet
scale?

Lucas

On Tue, 17 Dec 2019, 19:27 Mike Bishop, <[e-mail]> wrote:

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