Re: The qpack_static_table_version TLS extension (Draft version 02)

[David Benjamin <[e-mail]>]

> FWIW, I'm inclined to come out against the idea of using ALPS rather than
a TLS extension, primarily because ALPS is specifically NOT designed to be
a negotiation mechanism.

I think this may be fixating too much on the name and missing what the
extension actually does.

As one of the folks involved in the original design, I think I can
authoritatively say this is false. We named ALPS S for settings simply
because "ALPS" is easy to pronounce, and because the corresponding message
in h2 and h3 is called SETTINGS. It is absolutely designed to communicate
application protocol capabilities and preferences... in other words,
negotiation. Indeed we specifically had [HQ]PACK static tables in mind as a
use case when designing this. See here:
https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html#section-1-2

> Of course basic ALPN IS a negotiation mechanism (it's right there in the
name!)

I think this is further fixating on naming coincidences. The N in ALPN
doesn't mean "Negotiation *within* an Application-Layer Protocol" but
"Negotiation *of* Application-Layer Protocol". We couldn't name ALPS after
the former because ALPN was already taken and it's a bit ambiguous.

> maybe what I *want* is a brand-new ALSN (Application-Layer Stuff
Negotiation) which would encompass ALPN and also QPACK static table
negotiation and anything else which needs to be negotiated.

If you work through that design, I think you will quickly reinvent
something akin to the ALPN + ALPS combo.

Really all this is just the standard set of tradeoffs in protocol design
between minting new top-level versions or optional extensions within a
version:

- If we think this is just a sequential series of infrequently updated,
essentially universal features, this can be rolled up into h2.1, h2.2,
h2.3, etc., once we've settled on a cadence/criteria for how often we want
to mint new ones of these.

- If we think there may be multiple static tables for different folks, or
that we want to define new ones frequently, or that maybe one might want to
not have a static table at all, these tables may need to be one of several
orthogonal features. We don't have a great story for this in h2 and h3
today. ALPS aims to fill that gap, and fill in a few papercuts we left in
h3 around how SETTINGS and 0-RTT tickets interact.

FWIW, while I believe ALPS is the right starting point for problems shaped
like the second case, I don't personally have any horse in whether new
static tables should look like the first or second. The second seems
perfectly defensible, once we've switched from "never defining new ALPNs"
to "occasionally defining new ALPNs".

On Mon, Nov 27, 2023 at 1:12 PM Rory Hewitt <[e-mail]> wrote:

>
>    - Bumping this to request some input on my changes...
>
> FWIW, I'm inclined to come out against the idea of using ALPS rather than
> a TLS extension, primarily because ALPS is specifically NOT designed to be
> a negotiation mechanism. Of course basic ALPN IS a negotiation mechanism
> (it's right there in the name!), so maybe what I *want* is a brand-new ALSN
> (Application-Layer Stuff Negotiation) which would encompass ALPN and also
> QPACK static table negotiation and anything else which needs to be
> negotiated. It could probably include ALPS as well, since that could just
> not use the 'negotiation' concept... But I fear that's a pipe dream :)
>
>    -
>    - From: Rory Hewitt <[e-mail]
>    <[e-mail]?Subject=Re%3A%20The%20qpack_static_table_version%20TLS%20extension%20(Draft%20version%2002)&In-Reply-To=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E&References=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E>
>    >
>    - Date: Thu, 9 Nov 2023 16:03:23 -0800
>    - To: HTTP Working Group <[e-mail]
>    <[e-mail]?Subject=Re%3A%20The%20qpack_static_table_version%20TLS%20extension%20(Draft%20version%2002)&In-Reply-To=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E&References=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E>>,
>    TLS List <[e-mail]
>    <[e-mail]?Subject=Re%3A%20The%20qpack_static_table_version%20TLS%20extension%20(Draft%20version%2002)&In-Reply-To=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E&References=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E>>,
>    "Hewitt, Rory" <rhewitt=[e-mail]
>    <rhewitt=[e-mail]?Subject=Re%3A%20The%20qpack_static_table_version%20TLS%20extension%20(Draft%20version%2002)&In-Reply-To=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E&References=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E>
>    >
>    - Message-ID: <CAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb=
>    [e-mail]>
>
> Hey folks,
>
> Following my presentation at the meeting at IETF 118 today (thanks for
> taking it easy on me, as this was my first IETF appearance as well as being
> my first I-D), I have created another version of my I-D:
> https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-version-02.html
>
> Significant changes from version-01 are as follows:
>
> 1. I changed references to registry "Version" to "Variant" to make it clear
> that they could be very different.
>
> 2. I added a section on vendor-defined registries, which would contain
> static tables that might be much smaller and/or contain vendor-specific
> field names or values - for instance for personal assistants and APIs which
> only use a very small set of headers with known values.
>
> 3. In the QPACK Static Table Background
> <https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-version-02.html#name-qpack-static-table-backgrou>
> section,
> I added an example showing how the use of a static table can significantly
> reduce bytes on the wire by passing only 2- or 3-byte references to much
> longer strings that are known to both client and server.
>
> 4. The details of the TLS extension has been changed so that it is no
> longer simply a Variant/Length pair, but similarly to ciphersuite support,
> it is (when passed in the ClientHello) an array of Variant/Length
> combinations supported by the client and (when passed in the ServerHello) a
> single negotiated Variant/Length pair which will be used by both client and
> server.
>
> Note that the draft still refers to this as a "TLS extension" - I think
> many of us agree that it would be preferable if it were defined in ALPS,
> but since ALPS support is still minimal, I'll keep referring to it as a TLS
> extension for now. Given that, I would really appreciate any comments on
> the high-level concept, on the understanding that it may not end up being a
> TLS extension. Speaking of which, where can I find details of why ALPS was
> not taken up - it was mentioned in the meeting that there were 'concerns'
> about ALPS, but I'm not clear on what they were or who was concerned - HTTP
> WG or TLS WG or both or some other entity?
>
> Finally, I'm still trying to build a test harness to determine whether the
> benefits of any additional compression make sense - is this even worth the
> hassle? I would greatly appreciate any help on this - you'll get co-author
> credit, for what that's worth :)
>
> Thanks,
>
> Rory
>
> Received on Friday, 10 November 2023 00:03:41 UTC
>