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

2023年9月29日(金) 3:18 Marten Seemann <martenseemann@gmail.com>:

> 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.
>
> I might echo the hesitation of using indices as a way extension point, but
in a more technical way.

The problem of extending the static table as proposed is that it is prone
to ossification; there's no way of reclaiming a slot once that slot is
occupied by anything, that being an individual draft, WG draft, private
experiment, or whatever.

If anybody makes use of a slot and we want to take back, what we'd be doing
is to use a different code point in the negotiation scheme, regardless of
the scheme being TLS extensions or HTTP settings.

But if we are to use code points to indicate different ways of extending
the static table, wouldn't it better to just use different IDs to indicate
different tables being used, from day one?

Then, we can have a huge number space to indicate many many kinds of static
tables. Some of them can be extensions of the current static table, some
can be entirely different.

Separately, I think it would be great if the I-D was accompanied by a
scheme that makes actual use of the extension, rather than just proposing a
mechanism to extend. That's because without an actual use-case it is hard
to test interop and the correctness of the design.


> On Wed, 27 Sept 2023 at 18:08, Mike Bishop <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> on behalf of Lucas Pardue <
>> lucaspardue.24.7@gmail.com>
>> *Sent:* Tuesday, September 26, 2023 9:48 PM
>> *To:* Martin Thomson <mt@lowentropy.net>
>> *Cc:* Mike Bishop <mbishop@akamai.com>; HTTP Working Group <
>> ietf-http-wg@w3.org>; TLS List <tls@ietf.org>; Hewitt, Rory <rhewitt=
>> 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> 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
>> https://www.ietf.org/mailman/listinfo/tls
>>
>

-- 
Kazuho Oku