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

Some thoughts:
Putting it into a TLS extension seems like a layering violation. At that point during the handshake, we don't know yet which ALPN will be negotiated. In the best case scenario, this would render the qpack_static_table_version extension useless, but things might get more complicated once a different protocol (HTTP/3.1?) starts using QPACK (potentially with a different static table).
I've never been a big fan of the one-size-fits-all approach of QPACK's static table, so a replacement mechanism would be much more interesting to me.

On Wed, 27 Sept 2023 at 18:08, Mike Bishop <mbishop@evequefou.be <mailto:mbishop@evequefou.be>> wrote:
> My general thoughts, in no particular order: 
> I’d be more excited about using a generic mechanism to agree on SETTINGS pre-handshake (e.g., ALPS) than using a protocol-specific TLS extension for just this feature.  Therefore, HTTP WG for this particular use-case, but if there were to be a generic mechanism, that would probably live in TLS WG with HTTP WG as a consumer. 
> The value of a TLS extension is that it lets you agree on something before the application-layer protocol gets started.  That enables these things which you can’t do in SETTINGS: 
> Wholesale replacement of the static table, to put different things in the low-bitcount real estate 
> Use of “extended” entries in the first flight, to fit the most requests in the first packet(s); note that this matters more with TCP/TFO than QUIC 0-RTT. 
> Reducing the size of the static table for micro clients; see below 
> If we’re not doing one of those things, SETTINGS is the right model for this.  We decided in H3 that pre-application-data agreement wasn’t required for SETTINGS; do we want to revisit that? 
> The value of the static table in the protocol drops as the table gets longer, as the entries get more expensive to reference. For a frequently-used field, the marginal impact may just be shortening the initial reference to put the header into the dynamic table.  How many bytes does this actually save in a real session? 
> The difficulty of including the static table in a binary increases as the static table gets bigger, and this proposal could be very helpful in that problem – if a compact implementation could declare they only want to use the first 32 entries, for example.  The current version of QPACK imposes a minimum binary size on any H3 implementation, due to the requirement to keep the full static table accessible. 
> Wholesale table replacement probably involves offer-select or a priority ordering, departing from the usual SETTINGS model.
> Agreement is somewhat implicit – if the decoder has advertised support for entry N, the encoder can only reference it if it knows the value of entry N. If it knows the value of N, it would ordinarily be willing to accept references to N as well. 
> Exception: those micro-clients again. If a small binary contained a sparse selection of “useful values” from the static table, the encoder could use the entries of which it was aware, but a decoder could only advertise support for the first contiguous portion of the table. 
> 
> From: TLS <tls-bounces@ietf.org <mailto:tls-bounces@ietf.org>> on behalf of Lucas Pardue <lucaspardue.24.7@gmail.com <mailto:lucaspardue.24.7@gmail.com>>
> Sent: Tuesday, September 26, 2023 9:48 PM
> To: Martin Thomson <mt@lowentropy.net <mailto:mt@lowentropy.net>>
> Cc: Mike Bishop <mbishop@akamai.com <mailto:mbishop@akamai.com>>; HTTP Working Group <ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>>; TLS List <tls@ietf.org <mailto:tls@ietf.org>>; Hewitt, Rory <rhewitt=40akamai.com@dmarc.ietf.org <mailto:40akamai.com@dmarc.ietf.org>>
> Subject: Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension
>  
> Hi Rory,
> 
> I echo Watson and Martin, lets discuss this in the HTTP WG.
> 
> As for a very brief technical response. In general I'm supportive of the idea of more agility of the static table but I think my motivations would be different than the ones behind this proposal. For me, I'd like more domain-specific tables to be defined, and to have the possibility of asymmetric tables; but lets stick that on the side for now.
> 
> The QPACK static table description states "The order of the entries is optimized to encode the most common header fields with the smallest number of bytes.". How does the proposed append-only table gel with this? I.e. each year, the new most common fields are added to the end? At what point would it make sense to wipe out the cruft and define a newer table altogether?
> 
> I think what might be needed is a good amount of datamodelling and simulation that is sufficient to decide when there is activation energy to make changes. Perhaps the proposal is a compromise to make it low effort enough for implementations to update, that they don't need tremendous amounts of overwhelming evidence to keep up. IIRC historically the effort to sample the Internet and propose a table has been quite high, and there have been some criticisms about the outputs. Given the HTTP WG has struggled with this aspect, I think it is decidedly impractical to make IANA or a designated expert solely responsible for deciding the QPACK entries. This is something that has to run through a consensus approach IMO, especially as lower entries are more valuable and couldn't ever be reclaimed.
> 
> I think the largest activation energy would be to convince endpoints to implement the negotiation mechanism because it is pushing it into the TLS layer and that crosses implementation boundaries. Watson asks why not SETTINGS. One answer is that it requires clients to have to wait for the server's settings, which adds a delay that many clients don't already apply. Trading off latency for a few bytes doesn't sound like a good tradeoff. Indeed, this is why we optimised the static table for the clien'ts first flight before it knows if the server supports dynamic QPACK or not. Putting a client's static QPACK preference in a Client Hello is a fingerprinting vector, so that is a concern. Perhaps a middleground is to use a SETTING but then rope in the old ALPS proprosal [1] so that the client learns the server's view as early as required, and the client sends its view in SETTINGS after protection is established.
> 
> Changing track a bit, I don't understand why your proposal requires the client and server to agree on the extension value. Its a declaration of what the endpoint can support and I don't think there is any issue in e.g. the client being willing to receive references to entries greater than 99 and the server refusing to. Encoding asymmetry is already part of QPACK DNA.
> 
> Cheers,
> Lucas
> 
> [1] - https://datatracker.ietf.org/doc/html/draft-vvv-tls-alps
> 
> 
> 
> 
> 
> On Wed, Sep 27, 2023 at 1:40 AM Martin Thomson <mt@lowentropy.net <mailto:mt@lowentropy.net>> wrote:
> On Wed, Sep 27, 2023, at 01:32, Hewitt, Rory wrote:
> > Apologies if I should respond directly to the mailing list - my old W3C 
> > profile has disappeared and I'm trying to get it back...
> 
> Just on this point.  Watson added the HTTP working group, which I think is the right thing to do here.  The maintenance of HTTP/3 now formally belongs in that group.  The work of defining a TLS extension for that purpose would occur there (if indeed a TLS extension is the right choice, as Watson asks).
> 
> As for the W3C involvement, the HTTP working group is an IETF activity that - for historical reasons - uses a W3C-hosted mailing list.  You don't need to be a W3C member to sign up for that list.  The process is just a little different than for other IETF lists.  See https://lists.w3.org/Archives/Public/ietf-http-wg/ for details.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls