Re: Large Frame Proposal

On 8 July 2014 03:53, Nicholas Hurley <hurley@todesschaf.org> wrote:

> So now we're resurrecting jumbo frames.
>

Not resurrecting.  CONTINUATIONs are jumbo frames, so we already have
them.  We are just making them sane


> Again. I've already said "no" to this, and apparently I have to say it
> again. No jumbo frames, no large frames. Anyone who cares to see my
> reasoning against jumbo/large/huge/whatever frames is welcome to go back
> and read the archives.
>

I care, so I've gone back to see your arguments:


On 26 June 2014 04:48, Nicholas Hurley <hurley@todesschaf.org> wrote:

> Exactly. Jumbo frames seem like prime candidates for an extension,
> especially since no one can seem to come together on a single plan for what
> they would look like.
>

We've had a significant group get together and have decided what they
should look like.  please consider on merit.



> And given that we've already removed things from the spec that had some
> actual implementation experience (or at least broad implementer interest -
> I'm thinking ALTSVC and BLOCKED), I see no reason to add something to the
> spec just before WGLC.
>

Why go to LC, when those calls will be many saying they can't live with
continuations?



> If the procedural concerns aren't enough (they don't seem to have been in
> the past, so I'm not sure they will be now),
>

they are not enough.


> let's talk about actual experience. We have running code, right now, from
> a good number of implementers, that works with the regular-sized frames as
> currently in the spec. The current frame layout is simple, easy to parse,
> and easy to make decisions about. With all the perceived "complexity" that
> people have been complaining about, I'm honestly a little surprised that
> people are asking to add even more complexity (some of whom seem to be the
> same people complaining earlier!)
>

I believe the proposal is seen as simpler by most.  It certainly has a less
complex state machine.  It just standardises limits that many
implementations will already have. The complexity of changing a 14 bit
integer to 31 bits in the header can hardly be prohibitive.


I'm not convinced by the arguments around large file downloads - those are
> the exception rather than the rule. Optimize for the common case. In HTTP,
> that means viable multiplexing and priority, both of which are much more
> effective with frame size limited to 16k like we have it now.
>

In which case why are we getting ourselves in knots over the 0.001% of
cases with large headers.   If large headers get support in the standard
spec, then surely large payloads should also.

Besides, many of the issues the proposal addresses are for tuning
multiplexing for future networks - this is the common case.




>
> This is a HUGE change to the spec in order to make people feel better
> about cases that make up 0.02% of the streams out there. Why are we
> continuing to spend time and energy on this?
>

Hold a sec - you can't say it is a "HUGE change" and then later say it
doesn't "change much of anything".   It is a moderate change.  Increase the
length field to 31 bits and use settings rather than capacity to limit
frame size.    Not rocket science.


>
> One of the problems this tries to address -- END_STREAM on HEADERS vs.
> CONTINUATION -- I'd be fine with changing in the existing spec. Put the
> flag wherever.
>

It does not help unless you allow interleaving.


>
> If the WG decides to go this route (which I think would be ill-advised),
> there NEEDS to be a minimum on max frame size. We don't need to provide
> people two directions (too low and too high) to shoot themselves in the
> foot with.
>

+1, the proposal says 256, but happy to discuss better minimums.  I think
1024 would be fine.


>
> Finally, this doesn't ACTUALLY change much of anything. Some people might
> not need to buffer as much data, but otherwise, the end result is the same
> - they end up sending a GOAWAY. It's just a question of "go away because I
> realized you're sending me more headers than I want to deal with" (maybe we
> can add a new error code for this if it makes people feel better), or "go
> away because you sent me something I explicitly said I didn't want to
> accept" (PROTOCOL_ERROR).


As a server, I'd much rather the client did the buffering and then didn't
send a too large header.   Having the server buffer up all the headers for
the clients and then throw them away if they are too large is a poor design.



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.