Re: Large Frame Proposal

On 2014–07–09, at 11:18 PM, 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.
> 
> 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

Please see my recent messages to the list. There is a fundamental misunderstanding about what it means to be able to generate large frames. Just because someone can, doesn’t mean they should. The standard should probably make this clear, since it seems to be such a point of misunderstanding.

The problem of writing a working mux is exactly the same with and without jumbo frames. They simply allow removal the special case handling of multi-frame header blocks, and reduce the inherent per-frame CPU overhead when correctly availed of. A mux should make some decision about how much to write to its output stream before it calls write(). Blocking on write() is a Bad Thing and will likely result in mismatched HTTP and IP frames. Don’t do it.

Given that that is being avoided, an frame size limit simply is not needed to dictate mux behavior.

Received on Wednesday, 9 July 2014 23:02:31 UTC