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

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

From: Erik Nygren <erik@nygren.org>
Date: Tue, 8 Jul 2014 21:11:25 -0400
Message-ID: <CAKC-DJjsVE3abALpisG_4-jGqT-tOuR6ORXf2xBW6b6tqGhg4A@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Jeff Pinner <jpinner@twitter.com>, Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
Would getting rid of the reference set also allow us to move the static
table back to a fixed position?
That also seemed like it would have value for some implementations and
use-cases
based on the previous discussion but was problematic as long as we had the
reference set, as I remember it.

        Erik



On Tue, Jul 8, 2014 at 7:34 PM, Roberto Peon <grmocg@gmail.com> wrote:

> There are two HOL blocking issues w.r.t. headers:
>   1) HOL blocking because you can't send data frames while headers are
> being transmitted.
>   2) HOL blocking because you can't create other new streams while headers
> are being transmitted.
>
> Removing the reference set doesn't change either of these.
>
> #1 occurs because of an artificial restriction added to the spec for the
> sake of implementation simplicity.
> We could remove tomorrow by allowing data frames to interleave with
> headers/continuation.
> #2 is the big(ger) issue.
>
> The easiest solution to #2 is to send small headers, which is what
> commonly takes place today.
> Assuming that large headers are being sent, however,
>
> Even without a reference set, anything that modifies or references state
> places an ordering requirement on header data.
> Getting rid of the reference set reduces HPACK code complexity for
> decoders and encoders slightly, and that is about it as far as properties
> of that change.
> Making emission of the reference set explicit (instead implicit at the end
> of the header block) helps to reduce encoder complexity somewhat, but the
> opcode-frame-boundary-crossing issues still exist.
>
> Jeff's proposal of separating SYN_STREAM is meant to help address #2.
> I don't know if that would work, however, since knowing what the stream is
> about or addressed to requires the headers, which in turn means that stream
> creation is always tied to headers anyway... and you end up HOL blocking on
> 'em at the receiver, though not necessarily on the wire.
> -=R
>
>
> On Tue, Jul 8, 2014 at 2:28 PM, <K.Morgan@iaea.org> wrote:
>
>> On 08 Jul 2014, at 19:05, "jpinner@twitter.com" <jpinner@twitter.com>
>> wrote:
>> >
>> > To be clear, the proposal is:
>> >
>> > 1) Remove the reference set from HPACK (use "Linear-H")
>> > 2) Increase the frame size to 16-bits
>> > 3) Allow interleaving of HEADERS frames
>> > 4) Remove the "\0" separator hack.
>> >
>> > Coupling this with my earlier proposal to add a "SYN_STREAM" header
>> > would also allow us to:
>> >
>> > 5) Remove CONTINUATION frames entirely
>> > 6) Move END_* flags to the last HEADERS frame
>> > 7) Flow control HEADERS frames
>> >
>>
>> Hi Jeff-
>>
>> Can you please explain why the SYN_STREAM frame is necessary? It seems to
>> me that just removing the reference set would get rid of the need for
>> CONTINUATION frames since there would no longer be a requirement to process
>> all headers together as one big "jumbo block", just a requirement to
>> process frames in order.
>>
>> To be short, it seems to me that getting rid of the reference set also
>> solves 5, 6, & 7??
>>
>> -Keith
>>
>> This email message is intended only for the use of the named recipient.
>> Information contained in this email message and its attachments may be
>> privileged, confidential and protected from disclosure. If you are not the
>> intended recipient, please do not read, copy, use or disclose this
>> communication to others. Also please notify the sender by replying to this
>> message and then delete it from your system.
>>
>>
>
Received on Wednesday, 9 July 2014 01:11:52 UTC

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