Re: Alt-SvcB

I'd also add that by deprecating Alt-Svc, we can reasonably descope it from
other related work, to the advantage if the community.

For instance, Martin Duke and I have a draft intended to optimise
performance of selecting QUIC versions with HTTP/3 [1]. We describe how
this works with the HTTPS record. We also have to accommodate Alt-Svc
since  "that's what people use", even though we know that Alt-Svc's design
is broken for this type of versioning support in certain scenarios like
multi-CDN.

I can live with contuinuing to send Alt-Svc in order to support legacy
clients. Alt-Svc being frozen in time and not getting new goodies seems
fair.

Cheers
Lucas

[1] -
https://datatracker.ietf.org/doc/draft-duke-httpbis-quic-version-alt-svc/

On Tue, 25 Oct 2022, 21:33 Tommy Pauly, <tpauly@apple.com> wrote:

> The way I’d look at this is that we should be fine keeping the use of
> Alt-Svc for existing (and what will become legacy) clients to upgrade to
> h3, but we should not use it for any new protocol discovery. I.e., when we
> have an HTTP version that needs some transport other than TCP and QUIC, we
> shouldn’t plan on using Alt-Svc for that. So, our timeline should be to
> make sure clients can do HTTPS RRs by the time we replace QUIC, which
> should give us time.
>
> Tommy
>
> On Oct 25, 2022, at 1:21 PM, Ian Swett <ianswett@google.com> wrote:
>
> I would second David's statement.  In the world we live in today, we still
> need to use the Alt-Svc header for a substantial number of users.
>
> On Tue, Oct 25, 2022 at 2:31 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> Thanks for writing this up. Overall I think the long-term strategy makes
>> sense, but I think it's too early to obsolete/deprecate 7838. It's fairly
>> common for browsers to use getaddrinfo() on some platforms and that does
>> not provide access to HTTPS RRs. In those cases, 7838 is the only path to
>> using HTTP/3, so I expect browsers to keep using it for quite some time.
>> Marking 7838 as obsolete doesn't reflect that reality.
>>
>> David
>>
>> On Mon, Oct 24, 2022 at 5:10 PM Martin Thomson <mt@lowentropy.net> wrote:
>>
>>> Hey everyone,
>>>
>>> The Alt-Svc design team has been very busy recently and making some
>>> progress on working out an alternative alternative services design.
>>>
>>> I just posted
>>> https://martinthomson.github.io/alt-svcb/draft-thomson-httpbis-alt-svcb.html
>>> as a -00 draft.  This outlines the alternative design that we've been
>>> exploring in the design team.
>>>
>>> The basic idea is split into two procedures:
>>>
>>> 1. Use: When an Alt-SvcB field or ALTSVCB frame is encountered, the
>>> client looks for HTTPS records for the provided name in the DNS and creates
>>> a connection using what it learns.
>>> 2. Reuse: When a client that has previously used an alternative service
>>> connects again, it remembers the HTTPS record that worked.  It performs a
>>> regular HTTPS record lookup for the server - not using the alternative that
>>> it learned, but the name from the URI - but it prefers the alternative it
>>> previously used if that alternative appears in the results.
>>>
>>> The draft explains in more detail and goes into some of the implications
>>> of the design.
>>>
>>> This is not done by any imagining.  We have a bunch of open issues at
>>> https://github.com/martinthomson/alt-svcb/issues that do require some
>>> amount of input.  But we think that this is a promising approach and would
>>> appreciate more input.
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>