On 10 July 2014 01:18, Patrick McManus <pmcmanus@mozilla.com> wrote: > 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. Patrick, that is not in dispute. But there are two mitigations: - You are suggesting that the only way this proposal can be used in this example is to send a 500MB frame. That is not the case, as the flow control window at least will limit frames to 64KB initially. Even once the flow control window is enlarge, it is not certain that a 500MB frame will be used. The printer use case has indicated that simply doubling the frame size to 64KB is sufficient for a significant increase in throughput. We get that HUGE frames are bad, but that should not mean that we prohibit larger frames. - if somebody starts sending a 500MB header (in either 1 or more frames) then we have the same issue. So our QoS is already entirely dependent on the good sense of a single endpoint. Large or larger frames relies on the good sense of both end points. At one stage I was not too bothered with LC on h2-13, but now that not implementing continuations is seen as being a bad actor, I can't live with a LC on h2-13, regardless of timetables. 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.
Received on Thursday, 10 July 2014 00:07:34 UTC