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

[Mike Bishop]

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  on behalf of Lucas Pardue 

Sent: Tuesday, September 26, 2023 9:48 PM
To: Martin Thomson 
Cc: Mike Bishop ; HTTP Working Group ; 
TLS List ; Hewitt, Rory 
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 dy

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

[Marten Seemann]

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  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  on behalf of Lucas Pardue <
> lucaspardue.2...@gmail.com>
> *Sent:* Tuesday, September 26, 2023 9:48 PM
> *To:* Martin Thomson 
> *Cc:* Mike Bishop ; HTTP Working Group <
> ietf-http...@w3.org>; TLS List ; Hewitt, Rory  40akamai@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 so

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

[Hewitt, Rory]

More thoughts:

(note that I'm trying to get emails sent from my personal email 
(rory.hew...@gmail.com) but for now, it's this 
work email. But a random email may pop up from that email address out of 
order...)

* It sounds like there are some concerns (possibly significant) about using a 
new TLS extension for this. So then it comes down to using the SETTINGS frame 
directly or ALPS. I'd prefer ALPS, and I can change the I-D to reference ALPS 
instead. Would that answer the majority of concerns?

* Re MB's point about the static table size, there are three issues, I think:

** total table size and cost of seeking a table entry
** putting common entries near the beginning
** using smaller tables for micro clients

I'm not clear on how much the total table size is an issue - f.e. if the static 
table size doubled, are we talking an additional microsecond or is it 'real' 
numbers? At what point does the existence of a static table entry (even near 
the end of a large table) get outweighed by the additional seek expense?

Whilst the current design simply has a UInt8 to specify the number of entries, 
it's trivial to use a UInt16 (or a struct with multiple UInt4 or UInt8) to 
encode far more information, including a 'version' (which indicates entry 
ordering) and the number of entries. Thus the initial value could be 
effectively v1, 99 entries, and as new entries are appended, we'd have v1, 114 
entries and then v1, 146 entries etc. But at a certain point, we can publish a 
reordered static table as v2, moving some of the newer commonly-used entries to 
the start and have v2, 146. This allows us (whoever 'us' is) to reorder the 
table on an ongoing basis for best performance. For micro-clients, they can 
specify v2, 32 entries and servers will use the v2 ordering and only the first 
35 entries.

Basically, I want to ensure that this information is made available and agreed 
upon between clients and servers in SOME format. Again, this is all about 
future-proofing.

Rory

From: Marten Seemann 
Sent: Wednesday, September 27, 2023 11:55 AM
To: Mike Bishop 
Cc: Lucas Pardue ; Martin Thomson 
; HTTP Working Group ; TLS List 
; Hewitt, Rory 
Subject: 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 
mailto:mbis...@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 

Re: [TLS] TLSFlags ambiguity

[David Benjamin]

Nice catch! I agree those don't match. I think bit zero should be the
least-significant bit. That is, we should leave the examples as-is and then
fix the specification text.

Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no
inherent order to bits in memory, so the most natural order is the power of
two represented by the bit. Put another way, everyone accesses bit N by
ANDing with 1 << N and that's least-significant bits first. I can think of
a couple systems (DER, GCM) that chose to order bits most-significant first
and both have caused endless confusion and problems. (It's particularly bad
for GCM which is actually representing a polynomial, but then messed up the
order. Let's not repeat this blunder.)

On Fri, Sep 15, 2023 at 1:37 PM Jonathan Hoyland 
wrote:

> Hi TLSWG,
>
> I'm working on implementing the TLS Flags extension
> , and I
> just wanted to clarify a potential ambiguity in the spec.
>
> In Section 2 the spec says:
> Such documents will have to define which bit to set to show support, and
> the order of the bits within the bit string shall be enumerated in network
> order: bit zero is the high-order bit of the first octet as the flags field
> is transmitted.
>
> And also gives the example for encoding bit zero:
> For example, if we want to encode only flag number zero, the FlagExtension
> field will be 1 octet long, that is encoded as follows:
>
>0001
>
> In which it seems that the low-order bit of the first octet represents zero.
>
> I have no preference either way, but when transmitted on the wire, should 
> flag 0 be transmitted as
>
> 0x01 or 0x80?
>
> Regards,
>
> Jonathan
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls