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

I'm +1 for this proposal.

I have an issue of handling priority weights in sending multiple HEADERS 
with allocating resorces. I'm using a deficit round-robin and the order 
of sending frames are determined by its size and allocated resources.

With interleaving of HEADERS from diffrent streams, I can adjust and cut 
HEADERS sizes so as to fit their allocated resource and need not care 
their sending orders. Flow control can also be applied to them together 
with DATAs. It would be nice for me to handling priority trees.

Regards,

(2014/07/09 0:55), Jeff Pinner 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 17:11:43 UTC