- From: Rob Trace <Rob.Trace@microsoft.com>
- Date: Fri, 11 Jul 2014 21:30:42 +0000
- To: Martin Thomson <martin.thomson@gmail.com>, Greg Wilkins <gregw@intalio.com>
- CC: Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
We are OK with the first 4, but we agree that 5 is a bad idea. -Rob -----Original Message----- From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Friday, July 11, 2014 10:48 AM To: Greg Wilkins Cc: Jeff Pinner; HTTP Working Group Subject: Re: Striving for Compromise (Consensus?) 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.
Received on Friday, 11 July 2014 21:31:11 UTC