RE: #578: Header Table and Static Table Indices Switched

I did some quick experiments before putting the change in the spec.

The impact (of putting the dynamic table after the static table) is very small and positive for requests.
For responses, the impact is very small, positive or negative, for small maximum table size (1-4K). It becomes larger (still being small) and negative for medium table size (8-16K). It is reduced, still negative for larger table size (32K).

My analysis is that:
- For small table size, the number of entries is limited, and in both cases, indexes into the dynamic table always fit in 1 octet.
- For large table size, there are many entries, and in both cases, most indexes into the dynamic table need 2 octets.
- For medium table size, indexes into the dynamic table use either 1 or 2 octets, with roughly equivalent probability. Therefore, the ordering of the tables has an impact on the compaction.


My conclusion was, and still is, that the compaction impact was slightly negative, but very small and was more than balanced by the other benefits of putting the dynamic table after the static table.

Hervé.

> -----Original Message-----
> From: Willy Tarreau [mailto:w@1wt.eu]
> Sent: samedi 27 septembre 2014 09:09
> To: Mark Nottingham
> Cc: HTTP Working Group
> Subject: Re: #578: Header Table and Static Table Indices Switched
> 
> On Fri, Sep 26, 2014 at 04:51:50PM +0100, Mark Nottingham wrote:
> > <https://github.com/http2/http2-spec/issues/578>
> >
> > This hasn?t seen much discussion on list, and no one seems to have
> complained about it beyond Jeff.
> >
> > Does anyone want to argue for changing this, or should we WONTFIX?
> 
> I think that if there are strong opinions in both directions, it deserves
> being still studied openly. It's just a matter of encoding, variations are
> possible (I proposed one some time ago, I don't know if it would have
> addressed both usages).
> 
> Why not put numbers on the table. How many different non-standard headers
> Jeff needs, etc...
> 
> I'd like that we don't release a protocol which causes significant
> frustration to every single participant for one reason or another.
> At least the schedule is not a valid response to tell these people
> that they'll get a less efficient protocol for their use case, and
> I'd expect that a short time later someone would have found the
> best solution, so let's seek it now!
> 
> Willy
>

Received on Tuesday, 30 September 2014 08:55:03 UTC