Re: Large Frame Proposal

Jeff,

how is a frame size limit state significantly different from the state that
must already be kept for flow control windows?   We are already stateful at
both the stream and connection level because of those and I don't think
I've seen anybody argue against flow control.

I would argue that frame size is a priori a framing layer concern and that
we already manage it dynamically for flow control, so having a dynamic
limit is not a significant nor complex change.

Note that the proposal originally had a limit for both the connection and
stream, which nicely matched flow control. Currently it is only proposed to
add a connection limit - but if I could very easily be persuaded back to
support both.

regards





On 9 July 2014 12:17, Jeff Pinner <jpinner@twitter.com> wrote:

> To be clear, my issue is that this change makes determining valid
> frame lengths dependent on the session state which to me seems a step
> backwards both in terms of protocol layering and in terms of the
> achievable decoding throughput based on the simple frame layout.
>
> On Tue, Jul 8, 2014 at 7:13 PM, Jeff Pinner <jpinner@twitter.com> wrote:
> > Reading through I am -1 on the frame layout changes.
> >
> > I would be fine with un-reserving the first two bits and simply
> > requiring 64kb frames, but I feel like needing to compare allowed
> > sizes against SETTINGS that may change dynamically is a more
> > complicated change.
> >
> > On Tue, Jul 8, 2014 at 5:37 PM, William Chan (陈智昌)
> > <willchan@chromium.org> wrote:
> >> On Tue, Jul 8, 2014 at 5:36 PM, William Chan (陈智昌) <
> willchan@chromium.org>
> >> wrote:
> >>>
> >>> On Tue, Jul 8, 2014 at 3:09 PM, Mike Belshe <mike@belshe.com> wrote:
> >>>>
> >>>> Thanks, Greg.
> >>>>
> >>>> I believe your proposal is preferable to what we have today in H2.
> >>>>
> >>>>
> >>>> On Mon, Jul 7, 2014 at 8:14 PM, Greg Wilkins <gregw@intalio.com>
> wrote:
> >>>>>
> >>>>>
> >>>>> Mike,
> >>>>>
> >>>>> I think the settings are needed with the ability to send larger frame
> >>>>> sizes.   If I understand the feedback from SPDY correctly, the
> larger frame
> >>>>> sizes there were some endpoints that were lazy with their frame
> sizes and
> >>>>> sent overly large ones that hurt multiplexing.
> >>>>
> >>>>
> >>>> OK - thanks for clarifying.   I don't recall any such learning from
> SPDY.
> >>>> It certainly wasn't learning while I was at Google.
> >>>
> >>>
> >>> Yes, Patrick identified these issues after you stopped working on SPDY.
> >>
> >>
> >> Clarification: Patrick identified actual abuses live in the wild. Not
> >> theoretical. We indeed talked about the theoretical issue back when you
> were
> >> still at Google.
> >>
> >>>
> >>>
> >>>>
> >>>>
> >>>> BTW, some history:
> >>>> * SPDY originally used large frames too - 24bits - and let you use it
> as
> >>>> you wished.  Some people worried that these large frame sizes would be
> >>>> abused someday and felt compelled to shrink them.  But, as far as I
> know,
> >>>> those arguments were only theoretical.  The fact is that you're
> really only
> >>>> going to hurt yourself; and 'you' is the server.  Proxies are a
> different
> >>>> story.
> >>>>
> >>>> * SPDY's final field sizes were not arbitrary - they were an evolution
> >>>> based on lessons of what is valuable and what works.  Initially all
> headers
> >>>> were limited to 16k-ish.  This was because we didn't "like" large
> headers.
> >>>> But, when put to practice there are edge cases which needed to be
> dealt
> >>>> with, and some apps out there, wisely or not, use ridiculously sized
> >>>> headers.  It just happens.  Increasing the size was always preferable
> >>>> because:
> >>>>    a) we learned that the constraint itself wasn't very valuable and
> >>>> didn't make anything materially better.
> >>>>    b) there were edge cases where the constraint just didn't work, and
> >>>> the solutions were worse than the initial problem.
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> The intention of the proposal is to allow large frame sizes IF
> NEEDED,
> >>>>> but to use the settings to constrain implementations to the 16KB
> that has
> >>>>> been selected as a reasonable one-size-fits-all for todays traffic.
>   The
> >>>>> settings can then be adjusted without needing to rev the spec or
> deploy
> >>>>> extensions as experience is gained, traffic changes, networks change
> etc.
> >>>>> It may well be that they are adjusted down initially as much as they
> are
> >>>>> adjusted up.
> >>>>>
> >>>>>
> >>>>> So I don't see it as a compromise - it is simply moving the limit
> that
> >>>>> must exist from being a fixed capability of the framing layer to be
> an
> >>>>> explicitly managed parameter of the protocol.
> >>>>>
> >>>>
> >>>> Ok. I don't see any real need for these either.  They may introduce
> new
> >>>> oddities if someone goes crazy with them.  I'd lean toward not adding
> these
> >>>> if possible.
> >>>>
> >>>> Mike
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> cheers
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 8 July 2014 10:07, Mike Belshe <mike@belshe.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Jul 7, 2014 at 12:50 AM, Greg Wilkins <gregw@intalio.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> squid3@treenet.co.nz
> >>>>>>> Greg Wilkins gregw@intalio.com
> >>>>>>> Jason Greene jgreene@redhat.com
> >>>>>>> Keith Morgan K.Morgan@iaea.org
> >>>>>>> Poul-Henning Kamp phk@phk.freebsd.dk
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0926.html
> >>>>>>> [2] http://httparchive.org/interesting.php
> >>>>>>> [3]
> >>>>>>>
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1664.html
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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.