Re: Large Frame Proposal

On Wed, Jul 9, 2014 at 4:01 PM, David Krauss <potswa@gmail.com> wrote:

>
> 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.
>

I suspect we're agreed on that :)


>
> 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.
>
>
Not really true, though.
Lets say I write a muxing sender which looks at the available streams,
selects the highest priority amongst them, then generates a frame for it
and writes it to the socket.

With a small framesize, that'll work just fine.
With a large framesize, that won't work. You may end up with single frames
which take seconds or even hours (4GB of data on a low bandwidth link, for
instance) to drain.

This is orthogonal to the quality of the rest of the implementation.


> Given that that is being avoided, an frame size limit simply is not needed
> to dictate mux behavior.
>
>
True because a well implemented mux would select a small frame size.
In other words a (small) frame size is required to achieve good mux
behavior. A limit on the max framesize (dynamic or not) is one way to
accomplish that.

We've seen server implementations of SPDY get this wrong (when all that was
necessary was to fragment responses into smaller frames).
We have at least one declaration that folks would use larger frame sizes
for uploads or downloads, either of which will reduce the reactivity of the
session and cause a failure of the protocol to achieve its goals for that
connection if anything else happens during that upload/download.

-=R