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

Re: Large Frames, Continuations, Flow Control, and changing HPACK

From: Cory Benfield <cory@lukasa.co.uk>
Date: Tue, 8 Jul 2014 17:02:43 +0100
Message-ID: <CAH_hAJHqbP-t6kYbj3daqRE5pmuMGL0unX-7pMx_D0VZw07geA@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Note that Kazu Yamamoto posted to the list with implementation data
that suggests that the reference set does not provide a much in the
way of increased compression only last week[1]. Some discussion was
had in that thread, I recommend people read through it before
following up here.

[1]: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0149.html

On 8 July 2014 16:55, Jeff Pinner <jpinner@twitter.com> wrote:
> I would like to propose that we remove the "reference set" from HPACK.
>
> I think that this would help to alleviate many of the issues that are
> being brought up on the list w.r.t large header blocks and their
> affect on HOL blocking.
>
> By using the "reference set" of headers, the frame boundary and the
> header block boundary are tied together. We have also made the
> ordering of headers indeterminate leading to the null-separator hack
> and made requirements on the receipt of the ":" headers impossible to
> enforce requiring possibly complete buffering before basic routing
> decisions can be made.
>
> Removing the "reference set" would allow interleaving of HEADERS
> frames from different streams. It would remove the need for large
> contiguous frames carrying an entire "header block" since the
> termination of these blocks is meaningless. Headers could be more
> effectively "streamed" and CONTINUATION frames could be dropped from
> the spec.
>
> Since HEADERS frames can now be interleaved even if they do not
> contain the complete header set, this would also remove the HOL
> blocking issue and open up the possibility to flow control headers as
> well as data.
>
> - Jeff
>
Received on Tuesday, 8 July 2014 16:03:11 UTC

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