Re: Striving for Compromise (Consensus?)

Hi Martin,

On Fri, Jul 11, 2014 at 10:47:34AM -0700, Martin Thomson wrote:
> This seems to be the set that people are talking about most seriously:
> 
> On 11 July 2014 00:48, Greg Wilkins <gregw@intalio.com> wrote:
> > 1) Increase frame size to 16-bits
> > 1a) Add a settings for max_frame_size
> > 1b) ...that defaults to 16k
> > 1c) ...with some minimum (which might be 256, though a 256 byte frame could be all padding...)
> > 2) Remove reference set from HPACK allowing for "streaming" decoding.
> > 3) Requiring that all ":"-headers appear first.
> > 4) Only allowing CONTINUATION if the previous frame is max_frame_size.
> >
> > 5) Allowing interleaving of CONTINUATION frames with other frames.
> > 5b) The size of the HEADERS and CONTINUATION frames are removed from the
> > flow control window, but the they are never flow controlled.
> 
> I think that 4 and 5 might be problematic.
> 
> 4 doesn't seem to be well understood, but the interaction between TCP
> congestion window and something like the proposed 5b could mean some
> serious stalling/HOL issues.  More serious than the issues it purports
> to address.
> 
> I think that 5 is a non-starter.  Roberto's analysis on this has
> convinced me that this is an undesirable feature.

I think that in Roberto's case, it's the opposite in fact. Assuming he
runs a customer-facing gateway that aggregates streams to origin servers
using less connections, *and* that he forwards headers on the fly without
buffering, then a slow client sending a small header frame and slowly
pushing continuation frames would simply block all traffic from all other
clients to that same server for the same connection.

This problem does not happen if headers are buffered, and if they are
buffered, there's no need for CONTINUATION unless headers are larger
than max_frame_size, which is exactly point 4.

Regards,
Willy

Received on Friday, 11 July 2014 18:09:19 UTC