Re: Striving for Compromise (Consensus?)

On 12/07/2014 8:27 a.m., Martin Thomson wrote:
> On 11 July 2014 13:23, Poul-Henning Kamp wrote:
>> I mean that if we insist the entire header-set goes into a single
>> frame at most *zero* set of headers can be incomplete at any point
>> in time.
> 
> That's a valid point, though I was considering the fact that you have
> to read/buffer/process that frame, which takes non-zero time.  The
> point being that whether it's 0 or [0,1), this is very much different
> to N.
> 

In Gerg et al framing there is nothing forcing any recipient to buffer.
It is entirely possible to stream a large frame straight into the HPACK
decoder then PROTOCOL_ERROR the connection on HPACK errors. Such
recipients will be required to buffer the decoded headers, but this is
unrelated to the framing.

The frame size up front is to:
 a) identify clearly whether to RST/431 the stream then stream the frame
into decompressor (unbuffered!) to keep consistent HPACK state. Or if
buffering

 b) shift buffering to senders as intentional incentive for senders to
avoid huge frames. They are able to do so if the recipient permits, but
incentivised not to by all the recipients which advertie small frame limits.

Amos

Received on Saturday, 12 July 2014 04:17:26 UTC