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

RE: Striving for Compromise (Consensus?)

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>
Message-ID: <a7a50c24479a4bb9b0c5492edbb503f7@BL2PR03MB372.namprd03.prod.outlook.com>
We are OK with the first 4, but we agree that 5 is a bad idea.


-----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

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