Re: Large Frame Proposal

On 10 July 2014 01:18, Patrick McManus <> 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.


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.


Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Thursday, 10 July 2014 00:07:34 UTC