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

Hello Rory,

Sorry for not answering earlier. Many thanks for your detailed response. 
One main additional comment inline below, about the utility and 
frequency of new versions.

On 2023-10-06 01:34, Rory Hewitt wrote:
> 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.

I can agree with appending about every year or so. Newly defined header 
fields could become popular, or existing header fields could suddenly 
soar in popularity.

However, I have strong doubts about using a new version every 2-3 years. 
That has several reasons:

1) We don't have exact data; the relative frequency of the entries is 
just a guess. Statistical fluctuations occur, and as Roy has said, the 
data we have access to doesn't cover all of HTTP/3 usage. Changing the 
order, and then changing back a few years later just produces 
unnecessary churn.

2) Whether some header field name or header field is in a table makes a 
big difference (roughly 10~20 bytes to 1~2, i.e. one order of 
magnitude). On the other hand, whether an entry is e.g. number 50 or 
number 60 in most cases doesn't change the number of bytes used to 
encode that entry, and in the rest of cases, just adds or removes a 
single byte. So the performance gains of a new version are really minimal.

3) The overhead of new versions, ranging from registry updates to 
implementations and memory, are more serious than those for just appending.

4) Entries never get removed (see point 5 below). So we have to carry 
old entries around anyway, even if (in the extreme) their occurrence 
went down to 0 (e.g. because a new header field took over from an older 
one). That also makes cutting new versions less attractive.

All that makes me guess that a new version every 10 years or so might 
make more sense, if at all.

That then in turn raises the question of whether we need the "new 
version" mechanism at all, and whether we need it now or can wait for 
five or ten years down the line to define it.

Regards,   Martin.

> 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.
>

Received on Tuesday, 17 October 2023 05:10:10 UTC