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

Hey Martin,

Some ordered response which roughly match up to your comments, since adding
inline gets really difficult to read after a while :)

1. Yes, I'll mention that this will follow the 'normal' path of IETF
registries (IANA does clerical, IETF does technical).

2. I certainly didn't mean to overstep by suggesting myself as a designated
expert - I'll ensure this section is appropriately vague. But I want to
clarify that the HTTP Archive folks already have all the info we need in
terms of a representative web sample that we can query. The last thing I
would want is for this proposal to be mired in "we need people to do this
complex, time-consuming bit of work, so let's not do it at all". The data
is there and is freely available and is regularly updated.

3. Using "a year" was an example of the timeframe I think makes sense.
There doesn't need to be a schedule as such - new updates to tables and
versions get published when they get published. As noted above, the HTTP
Archive data could be used and I believe a new version of that is published
annually as a BigQuery, so that would be the optimal cadence for
determining whether new headers should be appended to existing table
versions. If the prevalence of the new headers are significant (FSVO
'significant'), such that a new table version would actually make sense,
that would be a decision for the registry maintainers. My gut feeling is
that appending new headers would likely happen every year or so, with a new
version being published every 2-3 years. But that's just a gut feeling -
like I say, there's no schedule.

4. Ah, you saw my bit about deprecation. I added that, then took it out,
then added it, then took it out. It should probably be taken out. Since
we're just talking about a registry, there's no downside to keeping every
prior version in the registry.

5. Good point! 99 is the default value for Version 0. Since each new
version will effectively start out as a re-ordered version of the latest
update of the prior version, then the default value for each version will
be different (but always >= 99). The specific default value for each
version will obviously be available in the registry.

6. Supporting a number of entries less than the default is a really
interesting case that I've been noodling on. Using your scenario, if a
micro client in the year 2030 says that it supports 5,30 and the server
says that it only supports version 2, then they will both use the first 30
entries in Version 2. I guess this could result in sub-optimal performance,
if there is a significant difference between the first 30 entries in v2 and
the first 30 entries in v5, but realistically, I think the first  few
entries (10? 20? 30?) are unlikely to change significantly - they're just
really commonly used. Entry 0 (":authority") is probably always going to be
number 1 :) Another option would be there to be different Types of tables
(Type would be higher than Version) so that e.g. micro clients can always
use a different table which works for them and the servers they think they
are likely to contact. But that migth be getting even more complex for
little benefit.

On Wed, Oct 4, 2023 at 8:30 PM Martin J. Dürst <duerst@it.aoyama.ac.jp>
wrote:

> Hello Rory,
>
> Just a few questions/comments below.
>
> On 2023-10-05 06:12, Rory Hewitt wrote:
> > A few upcoming changes for version-01:
> >
> > 1. A published version of the QPACK static table (see #2 for publishing
> > details) will have a Length and a Version, and the QSTVExtension will be
> > defined like this:
> >
> > struct {
> >      uint8 StaticTableVersion;
> >      uint8 StaticTableLength;
> > } qpack_static_table_version;
> >
> > where:
> >
> > StaticTableVersion - the version of the table. Initial version is 0.
> > StaticTableLength - the maximum number of entries supported in the table.
> > Initial length is 99
> >
> > So the first version of the table (currently defined in Appendix A in RFC
> > 2904 (https://www.rfc-editor.org/rfc/rfc9204.html#name-static-table-2)
> will
> > be 0,99.
> >
> >
> >
> > 2. I will specify that a new IETF registry should be created (and
> > *nominally* maintained by IANA) with myself and others as designated
> > experts.
>
> Two points:
> 1) Can you say what you mean by *nominally*? If it's just that IANA does
> the clerical work, but none of the technical work, then please note that
> all IANA registries work that way.
> 2) As far as I understand, designated experts are usually appointed by
> the IESG, with the responsible Area Director making a proposal. It's of
> course very good to have volunteers! But there's also some argument to
> having the proposers of new registrations and the approving expert(s)
> being different people (additional pair of eyes,...).
>
> > On an ongoing basis, we will sample traffic (likely from the HTTP
> > Archive, since they already do significant web traffic sampling). Where
> new
> > HTTP field names or name/value combinations (collectively 'header lines')
> > have become more prevalent than the current last entry in the latest
> table
> > , they will be appended as new entries in the table, increasing its
> length.
> >
> > Additionally, on an ongoing basis, new Versions of the table will be
> > created. This will involve re-ordering the table to ensure that the
> entries
> > are ordered in the most efficient manner possible.
> >
> > Example
> > =======
> >
> > The initial table is 0,99 (Version 0, Length 99) and is published in the
> > registry.
> >
> > A year from now, we re-sample traffic and discover 12 new header lines
> > which are more common than "x-frame-options: sameorigin" (entry 99 in the
> > current table). These 12 header lines are ordered by prevalence to each
> > other and appended as entries in the table in the registry - this is
> > referred to as 0,111 (Version 0, Length 111) and REPLACES table 0,99 in
> the
> > registry.
> >
> > A year after that, we re-sample traffic again and discover 5 new
> prevalent
> > header lines, so we order these entries and append them, giving table
> > 0,116, which REPLACES table 0,111.
>
> A year makes sense as a basic pacer. But there may be times where change
> is faster or slower (and there's times when humans are faster or
> slower). Is "year" here just an example, or a specific proposal?
>
>
> > Crucially, there is no reordering of entries in Version 0 - only
> appending
> > of new entries.
> >
> > At that point, we ALSO reorder ALL the table entries in order of total
> > prevalence and increment the Version, giving 1,116 and publish that as a
> > separate table in the registry.
> >
> > So now we have two published tables:
> >
> > * 0,116 - Version 0 with 116 entries. Entries 0-98 are in the same order
> as
> > the current QPACK table. Entries 99-111 are ordered by prevalence with
> one
> > another, but not with any prevalence order to entries 0-98. Same goes for
> > entries 112-116 - ordered in relationship to one another but with
> > relationship to entries 0-111.
> > * 1,116 - Version 1 with 116 entries. All entries are ordered by
> prevalence
> > compared to every other entry.
> Is the expectation that new versions also happen at a constant pace? Or
> do you expect to use some kind of entropy calculation so that new
> versions only get created if the reordering leads to "significant"
> savings? [some entries in entries 99-111 may be more prevalent than some
> of the later entries up to entry 98, but not by much.]
>
>
>
> > Over time, the registry could end up containing multiple Versions. Older
> > versions MAY be deprecated if we can reasonably determine that they are
> no
> > longer used (TBD). Only one table per Version will be published at any
> time.
> >
> > Clients and servers MUST always support Version 0. They MAY also support
> > other Versions as long as they support all intermediate versions between
> > Version 0 and the Version for which they advertise support in
> > qpack_static_table_version. This allows both client and server to simply
> > downgrade to a shared supported Version without the client needing to
> > advertise multiple supported Versions (c.f. TLS cipher suites) and
> possibly
> > missing intermediate versions.
>
> How does "they support all intermediate versions between Version 0 and
> the Version for which they advertise support" work together with
> deprecation?
>
>
> > Client and servers can still negotiate both the highest Version the
> support
> > and the Length (number of entries) within that Version in a manner
> similar
> > to that in version-00 of the I-D as follows:
>
> <snip>
>
>
> > 3. A client or server can specify any positive value for
> StaticTableLength.
> > A negative value is invalid and the default value (99) MUST be assumed by
> > the receiver.
>
> Is 99 the default value for version 0 only, or for all versions?
>
> > Thus a client or server which may have very limited memory and/or which
> > expects to send/receive only a few known headers can specify 0,30,
> > indicating that they support only the first 30 entries in Version 0 of
> the
> > static table and any other header lines must be specified in the dynamic
> > table.
>
> Interesting. What if a few decades from now, a client or server only
> wants to support the first 30 entries in a new version?
>
> Regards,   Martin.