Re: Large Frame Proposal

All,

Here is my summary of objections to this proposal so far.

>From my biased point of view, the following objections have been raised but
adequately responded to:

   - Too late in the process
      - It is too late when the chair tells us it is too late
   - The lack of ability to tune frame size has not yet definitely been
   identified/accepted as an issue.
      - real use-cases have been provided where a 16KB is far from optimal.
      - I don't like jumbo frames
      - I don't like continuation - deadlock!
      - Could achieve the same with a prepended size to a
   HEADERS+CONTINUATION* sequence
      - Worst of both worlds
      - Doesn't solve all DOS attacks
      - never claimed it did
   - It is too complex
      - Perhaps WINDOW_UPDATE, but the core change is very simple.


But I do think we need to discuss these ones some more:

   - The WINDOW_UPDATE change is adding a feature
   - The WINDOW_UPDATE change is a per stream setting - thus it is bad.
      - The mechanism is intended to be part of the flow control
      algorithm.   It is the intention of http2 to not specify a flow control
      algorithm, but instead define the bounds of flow control and to then let
      implementations develop better algorithms over time, with experience and
      potentially for special purposes.   Adding frame size as a variable that
      flow control algorithms can adjust will allow for more algorithms to be
      explored without requirements to change the specification or deploy an
      extensions.   However, this part of the proposal is indeed separable from
      the rest of it.


   - It assumes 'bigger is better' and will make for a poor QoS.
      - It is definitely not the intention of this proposal to just allow
      bigger frames, rather to move the frame size limit from a fixed
capacity to
      a configurable parameter.  In some circumstances it may well be that the
      frame size is configured smaller rather than larger.   I think
it is really
      important that we explore this issue an make sure that the proposal does
      not allow inadvertent nor deliberate degradation of QoS and
while i believe
      this is already the case, we need to ensure that it is understood.


   - It prevents streaming headers
      - yes it does (no such thing as a free lunch!) However, other
      limitations of hpack have already severely limited the practicality of
      streaming headers.  In fact I've not yet seen a good description of a use
      case where a header can be safely streamed without risking HOL
blocking.
      I believe that the benefits of this proposal outweighs this particular
      limitation.  If streaming headers really are a hard requirement, then we
      should look to HPACK to make changes, not the framing layer.

Have I missed any?

cheers






On 8 July 2014 13:39, Greg Wilkins <gregw@intalio.com> wrote:

> I've pushed some fixes to a few editorial issues in the proposal
> identified by Martin
>
>
> https://github.com/gregw/http2-spec/commit/b55765fc173823da1e515ec653604d9cea6ce820
>
> cheers
>
>
>
> On 8 July 2014 13:23, Greg Wilkins <gregw@intalio.com> wrote:
>
>>
>> On 8 July 2014 10:58, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>> That's a design decision that was made a long time ago. To reconsider
>>> it, I need more than vague concerns that amount to "I don't like it"; I
>>> need concrete problems that it causes.
>>
>>
>> insert Michael Sweets use-case here.
>>
>> cheers
>>
>>
>>
>> --
>> Greg Wilkins <gregw@intalio.com>
>> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
>> scales
>> http://www.webtide.com  advice and support for jetty and cometd.
>>
>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.