Re: Alt-SvcB

David Schinazi <> Tue, 25 October 2022 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A96FC14CE32 for <>; Tue, 25 Oct 2022 16:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.059
X-Spam-Status: No, score=-5.059 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HnOQO-1G85A3 for <>; Tue, 25 Oct 2022 16:25:12 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 45F05C14CF1F for <>; Tue, 25 Oct 2022 16:25:11 -0700 (PDT)
Received: from lists by with local (Exim 4.94.2) (envelope-from <>) id 1onTF7-004s4V-JA for; Tue, 25 Oct 2022 23:21:57 +0000
Resent-Date: Tue, 25 Oct 2022 23:21:57 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1onTF4-004s3N-I6 for; Tue, 25 Oct 2022 23:21:54 +0000
Received: from ([2a00:1450:4864:20::62a]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1onTF2-001nkC-JI for; Tue, 25 Oct 2022 23:21:54 +0000
Received: by with SMTP id q9so16991803ejd.0 for <>; Tue, 25 Oct 2022 16:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ICc9DFB6YKEjz2ZCaPjmd9lDomYZQTk0WT/y7NdVx9g=; b=FZS6pYzSwXFpQ4cNcasgGQEHCRxDJPdt3G6/RX5v5OX3uYAGdqVKKl8iQJ19ndEifO nTY4tH3y0Dpzs2OwUHuuLgCvr9yapDnbNoUoRjrdeY2QSQHpWm5Ape4PMmTybo3J0uhQ gfu82p8Lz1ahJFdpwk3CMPadb3PDiudW6e3kMPsrL+gIAxe014NSKuEH8XCkiPZHT4Ah fqEom4f/qAOrktVd9gNsfXF3OK8Bt8Zt1r0jCd71bm66bp6DPjGBA7b+1SB/CJUNiXwZ +ZYdyP4/ea1EuFqdCZKWuyKfNuQatf/8fatTBcs5GtXdzAObJXXR2T6Ewr3sFF4bmQIX VT7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ICc9DFB6YKEjz2ZCaPjmd9lDomYZQTk0WT/y7NdVx9g=; b=pP/XYFzlA4zqjbJHDLfY0Hx/UoyV+BtOdoT0pAHT1PSuuCjyS0lQhN077lwjV8Fp23 Pe1a616sR5sqO+cWnDP5nwhPfHC9vLCoFxf0oqDW6fL3/yujQiTgObbpYkNh+J1jUOe3 PIFUHFgcko6peIP9mtaxpBbHMQVyuNbFQ6pRA7fWK4N53tnOB66tccm1COyWNIw/RXSf IjeGPBZwtIggqAQStBMrG+PIncGV/z58v3DjWb85jrNWtD/dMhfQjuw9QVuv5WVMp8bH Wf97yUT1HFPiVP+lfu8ZGskpJjOyPapcX5RwkF2s6a4g8tp+vBNA7NynpnxX2kfZFbZc Esag==
X-Gm-Message-State: ACrzQf2uNpLjxlDkY8yVxsqKkt7pI7xaJzfvPyuP7VLdMhVOriQ+AjBm NUSg00DE3fDg9KtdoNxWYqPbMJ/4S6bWSdAQ1zg=
X-Google-Smtp-Source: AMsMyM6W9+gnaJ226w0uPzR9tgl6peHcZHiP+mI5ztEHvNxWv2H/zz6k+m0dgUfqmyS10cF9Yc/nXLFTa7gE2RWePqE=
X-Received: by 2002:a17:906:fe0b:b0:787:f1d3:2105 with SMTP id wy11-20020a170906fe0b00b00787f1d32105mr34781559ejb.83.1666740101143; Tue, 25 Oct 2022 16:21:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Tue, 25 Oct 2022 16:21:29 -0700
Message-ID: <>
To: Tommy Pauly <>
Cc: Lucas Pardue <>, Ian Swett <>, Martin Thomson <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000a95fb405ebe42b40"
Received-SPF: pass client-ip=2a00:1450:4864:20::62a;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1onTF2-001nkC-JI 43ac607ebab09b3a5103da2d2d2f3e49
Subject: Re: Alt-SvcB
Archived-At: <>
X-Mailing-List: <> archive/latest/40489
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

h3 hints are a great example of something that needs to be added to
Alt-Svc. It might be the last tweak we need, but it also might not.
Deprecating it will get in our way if we find something that we do want to
tweak later. What's the motivation for deprecating apart from preventing
future work on it?


On Tue, Oct 25, 2022 at 4:08 PM Tommy Pauly <> wrote:

> Would you really need to add goodies to Alt-Svc, until you need a non-QUIC
> transport? Just having h3 hints in Alt-Svc is enough to know that you can
> try QUIC, and from there you can have both QUIC version negotiation as well
> as ALPN negotiation for a theoretical H4-over-QUIC.
> I agree that OSes can be slow — and certainly I’ll push for the OSes I can
> influence to support the DNS records you need in the short term — but I
> think the timeline we’re looking at is about the time it takes to replace
> QUIC. If we look at the time between TCP and QUIC, I think we have quite a
> bit of time before this becomes an issue (on the order of 10+ years).
> Tommy
> On Oct 25, 2022, at 3:54 PM, David Schinazi <>
> wrote:
> We'll be ready to drop support for Alt-Svc once browsers have access to
> HTTPS RR everywhere. Until that happens, browsers will still use Alt-Svc
> for new HTTP versions, and we will still add goodies to Alt-Svc. If the
> IETF doesn't standardize those, then browsers will come up with their own
> solutions. The problem here is once again misaligned incentives: browsers
> want to be fast and to use new standards but it's the OSes that need to
> change their DNS APIs. Do we know anyone at POSIX interested in revamping
> getaddrinfo?
> David
> On Tue, Oct 25, 2022 at 2:25 PM Lucas Pardue <>
> wrote:
>> 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] -
>> On Tue, 25 Oct 2022, 21:33 Tommy Pauly, <> 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 <> 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 <>
>>> 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 <>
>>>> 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
>>>>> 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
>>>>> that do require some
>>>>> amount of input.  But we think that this is a promising approach and would
>>>>> appreciate more input.
>>>>> Cheers,
>>>>> Martin