W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Call for Consensus: Remove "reference set" from HPACK (to address #552)

From: Greg Wilkins <gregw@intalio.com>
Date: Tue, 15 Jul 2014 10:46:36 +1000
Message-ID: <CAH_y2NHa9GN5W4W1UpFQYHDsay_7cdSVOxW3+rwUSh5FmxBc3g@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: Kazu Yamamoto <kazu@iij.ad.jp>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 15 July 2014 00:04, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

> Personally, I don't think current scheme (static table at the end of
> dynamic one) is very hard to implement or tricky. So I'm not so sure this
> change is worth its cost.  If dynamic header table index gets screwed up,
> we still valid index in static table but it is corrupted anyway as a whole.‚Äč
>

I don't think it is so much an argument about being difficult to implement
- it's is pretty simple.  I think the argument is about  what is most
efficient.

I think it is self evident that copying static entries into the dynamic
table is less efficient.  It causes 2 entries for the same field (or more
for dumb encoders), which wastes space in the index space.  It also causes
churn in the header table which will result in retransmits.   So without
the need to limit the reference set size, I think it is a no brainer to
stop doing this copy.

Then references to the  static table are going to be a lot more frequently
used.  If the static table is indexed first, then those frequent entries
will only be 1 byte.  If they are indexed 2nd, then they are going to be at
least 2 bytes for any non trivial sized header table.

If we can get some good example headers, then it should be pretty simple to
work out which is best for a few sample header table sizes.

Failing that, a dedicated static table bit is a good guess at a compromise
for different sized header tables:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1 | S |    Index (6+)         |
   +---+---------------------------+

This gives 62 static entries (excluding 0 and 64) that fit into 1 byte,
plus the first 62 dynamic entries would also fit into 1 byte.     I think
this allows use-cases with lots of common headers and ones with lots of
custom headers to both have a good number of 1 byte field encodings.


cheers





-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Received on Tuesday, 15 July 2014 00:47:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC