Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

Hey Mike,

So you're suggesting that we could publish the current table as a v1
registry, but then the v2 registry might be completely different - not just
a re-ordering but with some entries removed and some others added? The
major downside I see to that methodology is that it doesn't allow easy
'downgrade' - if a client advertises support for v5 and the server
advertises support for v3 and the entries in v5 and v3 aren't just
reordered (and with some new entries in v5) but actually significantly
different, then how do they both recognize that they will both have to
downgrade to v1 (assuming that we agree they both have to support v1)?

The idea of the client specifying which table versions it supports and the
server responding with the 'best' match (a là TLS versions/ciphersuites)
was something I toyed with when coming up with this design - I decided
against it because of the overhead of the client passing an array of
Version/Length pairs. But if we were to get the TLS WG to agree that this
makes sense as a TLS extension (whether HTTP-specific or whatever), it
might make sense.

As it is, I'll have to get some buy-in from the TLS folks if this does
require a TLS extension... TBH, I didn't think about the complex option of
the sender identifying sub-sections of tables that it supports (that sounds
crazy!).

FWIW, as far as getting a TLS extension goes, it appears that ALPS doesn't
have much, if any, takeup - the I-D expired 2 years ago. That being said,
maybe it was built in to some clients or servers and it's just not in
'active' use.

Rory

On Wed, Oct 18, 2023 at 2:09 PM Mike Bishop <mbishop@evequefou.be> wrote:

> I don't know that the assumption that it starts as a re-ordering is going
> to be valid. Certainly we have at least one instance (the erratum you
> reported, Rory!) where we've found something in a static table that's
> simply invalid; I'd expect we drop that line in any versioned update, even
> if we have to keep it while extending. Similarly, fields that are lists of
> capabilities (e.g. Content-Encoding) are likely to have a new 1-2 top
> values that replace the old ones. I'd expect we generate the table *de
> novo* each time we do so, while hoping that many values remain the same
> over time.
>
> I also do think there are interesting possibilities here for
> domain-specific tables which aren't a contiguous list of ongoing
> improvements. (Clients might also like not to remember the decades-old
> versions other than the fallback version zero.)  That might suggest
> something more like the TLS supported_versions (
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.1) extension,
> in which the sender could indicate "I know the first 104 entries of version
> 0, the first 72 entries of version 1, and the first 32 entries of version
> 61932." This also allows us more flexibility for doing draft version
> support during development, similar to QUIC versions that embedded draft
> numbers.
>
> Roy, to your comment a while back that the HTTP Archive isn't
> representative:  It absolutely isn't, and yet it's the best resource we had
> at the time and what we used. If there's a more representative resource to
> be used in the future, please do suggest it when we start trying to build a
> new table.
>
> Thanks,
> Mike
> ------------------------------
> *From:* Rory Hewitt <rory.hewitt@gmail.com>
> *Sent:* Tuesday, October 17, 2023 2:21 PM
> *To:* Martin J. Dürst <duerst@it.aoyama.ac.jp>
> *Cc:* HTTP Working Group <ietf-http-wg@w3.org>; TLS List <tls@ietf.org>;
> Hewitt, Rory <rhewitt=40akamai.com@dmarc.ietf.org>
> *Subject:* Re: [TLS] New Internet Draft: The qpack_static_table_version
> TLS extension
>
> Hey Martin,
>
> That's a fair point, and I appreciate you bringing it up.
>
> What I wanted to clarify was that every 3 years, whoever is doing the
> sampling and appending of new entries should determine whether the new
> entries are sufficiently popular that re-ordering the table makes sense.
> They can certainly decide that it doesn't make sense to create an entire
> new registry just because entry 123 should actually be at position 98. As a
> consequence, I agree that creating a new table every 3 years doesn't
> necessarily make sense.
>
> Indeed, the most common scenario is almost certainly that new field
> strings are appended to the table every year or so, but while they are
> 'somewhat' popular (more popular than the last entry in the table, at
> least), they're not 'really' popular - they're not going to be so popular
> that they displace the low-order numbers in the table and make a real
> difference. So no new version is required.
>
> However...
>
> Since the web traffic was originally sampled in 2018 to create that
> initial QPACK table, things have changed considerably. I suspect that some
> of the Client Hints header strings (Accept-CH etc.) have probably become
> very popular and will continue to do so - possibly to a point where it may
> make sense that a new registry be created with the table being reordered.
>
> Additionally, the current QPACK table contains some entries that are,
> shall we say, weird. For example, many of the CORS entries (73-82) contain
> invalid values. While the point of the QPACK table is to aid compression
> (and therefore commonly-used fields, even if they are technically invalid,
> should be included), I'm surprised that some valid values are not included
> in there.
>
> I wouldn't be surprised if we sampled traffic today (5 years after the
> original sample) we found a) a number of frequently-used headers which
> don't exist in the current static table; and b) that some of the headers in
> that table should be re-ordered because it would make an actual difference.
> Which would certainly mean appending those new fields, but very likely
> (again IMO) in re-ordering the table and creating a second registry.
>
> Finally, while it may be the case that a new version is only needed every
> 10 years, it makes sense to me to define the process for creating that
> version now, even if it's not needed for a while.
>
> Thoughts?
>
> Rory
>