Re: Multiple Huffman code tables

It's not that they're optimized for a brand. Right now, the QPACK static
table contains a 'representative sampling' of web traffic from 5 years ago.
I would like to change that - see
https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-version-02.html
.

But I understand Christian's point that the 'optics' of including
particular branded headers aren't great - even though the actual benefits
of doing so are real. Since I'm just looking at this from a performance
POV, part of me thinks we absolutely SHOULD include all commonly-passed
headers as static table entries (so there's not even any Huffman-encoding
overhead). But as Christian points out, those headers may change over time,
so those previous entries become less useful, as well as leading to
questions years hence about why a particular User-Agent header referencing
a particular company's browser was included.

Hence my wish to allow different vendors to specify different header
tables, especially when they are interacting with their own servers, so
they know which headers will and will not be sent.

On Fri, Dec 8, 2023 at 1:18 PM 姓名 <falsandtru@gmail.com> wrote:

> I really don't know why you assume that they are optimized for a
> particular brand.
>
> 2023年12月9日(土) 6:15 Rory Hewitt <rory.hewitt@gmail.com>:
>
>> I have struggled with this conceptually when thinking about the QPACK
>> static table.
>>
>> If a vast number of requests pass a 'branded' header, is it not in
>> everyone's best interests to include that information, to reduce
>> bytes-on-the-wire?
>>
>> That's why we should have a standard where 'common' headers have
>> predefined positions in a static table, with separate versions of that
>> table which can be used by the various vendors to append their own
>> branded headers (or indeed, to have their own standalone static tables that
>> include both their branded headers and also only the very small subset of
>> the total set of possible headers that their devices may send or receive).
>>
>> For example, the various voice assistants (Google Assistant, Amazon
>> Alexa, Apple Siri) only ever make requests to/from specified servers, so
>> their designers are very well aware of the best way to encode the headers
>> used in their transactions - both branded and not - to both reduce bytes
>> on-the-wire AND limit the memory usage by those client devices storing
>> QPACK/HPACK tables full of headers that they will never normally send or
>> receive.
>>
>> On Fri, Dec 8, 2023 at 12:37 PM Christian Huitema <huitema@huitema.net>
>> wrote:
>>
>>> I have no opinion on the benefits or not of defining better compression
>>> than HPACK/QPACK, but I do have an opinion on the inclusion of brands in
>>> the training set, like:
>>>
>>>
>>>  > -1, '"Google Chrome";v="117", "Not;A=Brand";v="8", "Chromium";v="117"'
>>>
>>>  > -1, '"Google Chrome";v="117.0.5938.89", "Not;A=Brand";v="8.0.0.0",
>>>  > "Chromium";v="117.0.5938.89"'
>>>
>>>  > -3, 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
>>>  > (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36'
>>>
>>>
>>>  > 0, '1P_JAR=2023-11-22-18; expires=Fri, 22-Dec-2023 18:46:19 GMT;
>>>  > path=/; domain=.google.com; Secure; SameSite=none'
>>>
>>> I assume that this kind of branded content reflects the reality of the
>>> market place, and that assigning short Huffman codes to it will indeed
>>> reduce the size of messages. But I think dedicating codes to such brands
>>> today is an error. Market shares and product names will change over
>>> time, making such optimizations ephemeral. But even if the optimizations
>>> were stable, optimizing for the existing set of brands will provide an
>>> advantage to these brands over newcomers, and thus contribute to
>>> increased concentration -- something that standards should certainly not
>>> encourage.
>>>
>>> -- Christian Huitema
>>
>>

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt