- From: Jeff Pinner <jpinner@twitter.com>
- Date: Tue, 8 Jul 2014 19:13:12 -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>
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:13:40 UTC