- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Thu, 5 Oct 2023 12:30:16 +0900
- To: Rory Hewitt <rory.hewitt@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, TLS List <tls@ietf.org>, "Hewitt, Rory" <rhewitt=40akamai.com@dmarc.ietf.org>
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