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

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.

Received on Thursday, 5 October 2023 03:30:29 UTC