- From: James M Snell <jasnell@gmail.com>
- Date: Wed, 9 Jul 2014 08:37:36 -0700
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: Greg Wilkins <gregw@intalio.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Roberto Peon <grmocg@gmail.com>, David Krauss <potswa@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Ok, so we do both. Set the default operation of the protocol to size-16k frames. If an endpoint wishes to allow jumbo frames, it enables an extension that says "enable jumbo frames. yes, yes, I know that means the protocol will be less responsive, and I get that, but I have good reason to allow for it so, please, go ahead and do it". Once that setting is set, there's no going back on that connection and the willful participants go into it knowing full well that the protocol will be less responsive for multiplexed streams. The folks who are willfully enabling the switch will be well aware of those "pitfalls" and will understand what they are doing and why. On Wed, Jul 9, 2014 at 8:18 AM, Patrick McManus <pmcmanus@mozilla.com> wrote: > > > > On Wed, Jul 9, 2014 at 8:41 AM, Greg Wilkins <gregw@intalio.com> wrote: >> >> >> On 9 July 2014 22:26, Patrick McManus <pmcmanus@mozilla.com> wrote: >>> >>> obviously if jumbo frames are not used jumbo frames dont matter >>> >>> but when they are used, all of the receivers streams are put at risk. So >>> the client is incented to use multiple connections so the risk is not >>> linked. And that's a fail for h2. >> >> >> >> Patrick, >> >> I don't see the incentive to use multiple connections. > > > If I have N transactions on a connection that uses jumbo frames then all N > transaction have a responsiveness risk anytime a jumbo frame is used because > the server cannot react to a CANCEL (or other high priority event) without > serializing the entire jumbo frame. If I start a 500MB download and then > cancel it and start a different 500MB download the subsequent transfer > cannot happen in a timely fashion if the first one used a 500MB frame and > they all share the same connection. > > There are two fixes to that problem: > > 1] don't use jumbo frames. that's the status quo. Its a good thing - but the > preface above was "when they are used" > > 2] place N transactions on N connections the way h1 does. The stream cancel > turns into a tcp rst which gives the appropriate level of reactivity. > Unfortunately now I'm not running a prioritized muxed protocol with good > connection handling - that is a bad thing :) > > I appreciate that the proposal makes frames larger than 16KB optional for > the receiver and I appreciate it. My objection is that you can't create > large frames at all and have it be compatible with a prioritized mux'd > protocol - so it shouldn't be there because there really is no other reason > to want h2 other than priority mux and large frames are inherently not > priority mux friendly. I also appreciate that it allows mini frames (is that > the opposite of a jumbo frame?) but at this point in the schedule it doesn't > seem to be addressing a demonstrated problem, so I'd rather proceed on the > LC call track with this as an extension. > > -P > > > > >> >> If an endpoint wants streams to proceed in parallel, then it should not >> send nor accept large frames. We have already shown that going >> multiplexed over a single connection has advantages over multiple >> connections, but if an endpoint really wanted multiple connections with >> large frames, then it would use h1 rather than pervert h2. >> >> Besides, I don't think this is a black and white issue here. Firstly, it >> is not given that increases in frame sizes will be to huge frames, as it >> maybe that for a given network/situation 32KB frames give good throughput >> and acceptable QoS. More over, it is simply not the case that 16KB frames >> give good QoS and any thing greater does not. The proposal can also be >> used to decrease frame sizes if that is optimal for some situations. >> >> We have already accepted that endpoints have to be restrained with large >> headers if they want QoS, so we are already trusting them with that >> decision. How is this any different for large data? >> >> regards >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> 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 15:38:27 UTC