Re: The qpack_static_table_version TLS extension (Draft version 02)

[Rory Hewitt <[e-mail]>]

Yeah, if ALPS 'can be used as a de facto negotiation protocol' then life is
much easier - although does the first settings frame there come from client
or server?

In any event, as long as one of them is able to send a list of supported
variant/length combinations and the other can reply with their chosen one
from that supported list, then we're golden.

On Tue, Dec 12, 2023 at 8:06 AM Mike Bishop <[e-mail]> wrote:

> ALPS not being a negotiation mechanism comes from the HTTP/QUIC idea that
> settings are not responses to each other, but unilateral declarations about
> a client’s state. The protocol then needs to describe what is safe to send
> / how to interpret things being received based on what is seen in SETTINGS.
>
>
>
> A more complex approach might be to assume the peer will have seen the
> SETTINGS you sent as well and define an algorithm to “negotiate” by
> combining what was sent and what was received.  No HTTP extensions to date
> have gone this far, largely because guarantees about ordering get a bit
> squishy, especially in QUIC.  The key benefit of ALPS is a guarantee that
> both sides have seen and processed the settings by the time the TLS
> handshake completes, so you can rely on such an algorithm in 1-RTT data.
> (0-RTT might still have sharp edges.)
>
>
>
> *From:* Rory Hewitt <[e-mail]>
> *Sent:* Monday, November 27, 2023 8:49 PM
> *To:* David Benjamin <[e-mail]>
> *Cc:* HTTP Working Group <[e-mail]>
> *Subject:* Re: The qpack_static_table_version TLS extension (Draft
> version 02)
>
>
>
> Hey David,
>
>
>
> Focusing in on what is (IMO) the most important bit of your response:
>
>
>
> Right, I think that's the ALPN vs ALPS question. If we believe a mess of
> vendor-specific static tables is worthwhile, we should do this with as
> subfeature and do something like ALPS. If we don't believe this is that
> important, and that we can live with a single, infrequently-updated,
> universal static table, let's just define h2.1 and move on with life.
>
>
>
> Given that the dynamic mechanism already compresses repeat headers after
> the first utterance, and that h2 and h3 are quite good at connection reuse,
> I suspect the h2.1 path is just fine. Or are you seeing that people are
> trying to make vendor-specific static tables already? I've not heard of
> this happening.
>
>
>
> I haven't seen any evidence that any vendors are creating their own static
> tables. But if I were, let's say, Google (random example, I swear), I would
> note that Chrome appears to send a number of headers with every request for
> a web page, some of which are very big, and would therefore
> benefit significantly from being added to a static table, e.g.:
>
>
>
>
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
>
> Sec-Ch-Ua: "Google Chrome";v="119", "Chromium";v="119",
> "Not?A_Brand";v="24"
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
> (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
>
>
>
> Leaving aside the discussion of if/when the User-Agent header will be
> frozen and what form it will take at that point, that's a lot of bytes
> (340-ish)! Using static table entries for name/value combos reduces that to
> about 12 bytes. Dynamic table Huffman coding compression doesn't even get
> close.
>
>
>
> So I can certainly see vendors seeing the benefit of being allowed to
> define small (possibly vendor-specific) tables as a noticeable benefit over
> and above the h2.1 path.
>
>
>
> If ALPS works as a negotiation mechanism, then coolio. I was mistakenly
> under the impression that it wouldn't.
>
>
>
> Rory
>
>
>
> On Mon, Nov 27, 2023 at 12:43 PM David Benjamin <[e-mail]>
> wrote:
>
> On Mon, Nov 27, 2023 at 3:21 PM Rory Hewitt <[e-mail]> wrote:
>
>
>
>
>
> On Mon, Nov 27, 2023 at 10:57 AM David Benjamin <[e-mail]>
> wrote:
>
> > 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
>
>
>
> Ah - I was indeed fixating on this (Section 3 - semantics):
>
> ALPS is _not_ a negotiation mechanism: there is no notion of rejecting peer's settings, and the settings are not responses to one another.
>
>
>
> Ah, forgot about that text. This document is old. :-) I believe this was
> just trying to capture that each side's blobs were expected to be
> configured mostly statically. See the immediately following text:
>
>
>
> > Nevertheless, it is possible for parties to coordinate behavior by, for
> instance, requiring a certain parameter to be present in both client and
> server settings. This makes ALPS mechanism similar to QUIC transport
> parameters [I-D.ietf-quic-transport] or HTTP/2 SETTINGS frame [RFC7540],
> but puts it in contrast to similar mechanisms in TLS.
>
>
>
> I.e., this was just trying to capture that this is akin to the QUIC and
> HTTP pattern, rather than the TLS pattern where one side's message is
> directly in response to the other. We didn't want to invent a whole new
> pattern and just try to patch up the issues with the existing one. (At the
> end of the day, you just need *something* to signal that the new thing is
> happening, and then the rest is just protocol engineering.)
>
>
>
> Though also I don't consider these details to be that fundamental. We
> probably could have allowed the client one to be in response to the server
> one, if people prefer that. It just would have encouraged a more complex,
> asymmetric callback API. Such a callback would be particularly challenging
> considering that your h2 logic may be far from your TLS terminator in some
> deployments. Thus it seemed cleanest to use static messages and have
> everything flow from there. (You just need *something* that consistently
> signals to both sides, at the right time, that the new thing is happening.)
>
>
>
> > 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.
>
>
>
> Yeah, I'm aware of that :) It was meant somewhat (OK, almost entirely) in
> jest...
>
>
>
>
>
> 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.
>
>
>
> I admit I've only been lurking in the half-rtt data discussion.
>
>
>
> TBH, in many ways it would make sense to use the ALPS as defined in
> https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html#name-using-alps
> for my use-case (QPACK static table), since in that case the server sends
> the ALPS h2 settings first and the client effectively 'responds', so a
> negotiation would start from the server, if I understand correctly.
>
>
>
> 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".
>
>
>
> Sorry, just noticed that I mixed up "first" and "second" here. (This is
> what I get for referencing things by numbers!) That was probably confusing.
> I meant to say that the *first* seems perfectly defensible. That is, I
> think:
>
> - *If* you want to model this as lots of orthogonal features, something
> ALPS-y is the right shape.
> - But just rolling up common static table updates into h2.1, h2.2, etc.,
> whenever we find we need to mint new ones, seems likely fine.
>
>
>
> Which is fine by me.
>
>
>
> My concern is really about us having defined how h3 headers should be sent
> (QPACK, combo of static and dynamic tables) but not having a mechanism to
> extend that going forwards for specific use-cases.
>
>
>
> IMO, the worst-case scenario is where different client/server vendors
> (e.g. Apple, Amazon, etc.) decide to create their own additional static
> table entries (or simply much smaller and more limited static tables) in an
> effort to reduce bytes on the wire for things like assistants (Siri, Alexa,
> etc.) which only send a few headers, several of which are vendor-specific
> and which only contact servers which are expecting those requests. For each
> individual vendor, doing that would absolutely make sense and I wouldn't
> blame them for doing that, but overall it would make it much more complex
> to design common testing tools or utilities like cURL or simply to maintain
> some sort of standardization.
>
>
>
> Right, I think that's the ALPN vs ALPS question. If we believe a mess of
> vendor-specific static tables is worthwhile, we should do this with as
> subfeature and do something like ALPS. If we don't believe this is that
> important, and that we can live with a single, infrequently-updated,
> universal static table, let's just define h2.1 and move on with life.
>
>
>
> Given that the dynamic mechanism already compresses repeat headers after
> the first utterance, and that h2 and h3 are quite good at connection reuse,
> I suspect the h2.1 path is just fine. Or are you seeing that people are
> trying to make vendor-specific static tables already? I've not heard of
> this happening.
>
>
>
> David
>
>
>
> 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
>
>
>
>
> --
>
> Rory Hewitt
>
> https://www.linkedin.com/in/roryhewitt
>
>
>
>
> --
>
> Rory Hewitt
>
> https://www.linkedin.com/in/roryhewitt
>


-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt