Re: Large Frame Proposal

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