- From: Jeff Pinner <jpinner@twitter.com>
- Date: Tue, 8 Jul 2014 19:17:02 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: Mike Belshe <mike@belshe.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
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. >>>> >>>> >>> >>
Received on Wednesday, 9 July 2014 02:17:30 UTC