Re: Large Frame Proposal

Mark,

thanks for the serious consideration.

I agree that the issues need to be carefully identified.   I think 549,550
and 551 are all good issues to create (although this proposal does not
directly address 550).   But I think there should also be issues for

   - a fixed frame size does not allow tuning multiplexing performance
   based on current/future experience.
   - the 16KB frame size is not well tuned for frequent payload sizes
   - a fixed frame size cannot be adjusted for specific streams in specific
   situations that may not required multiplexing efficiency.

Or at least one issue that the fixed max frame size cannot be tuned for any
reason

One note of caution with decomposing to individual issues, is that no
single issue may be sufficiently important to rock the boat at this late
state, but a proposal that resolves many such issues might well be worth
the disruption.

cheers











On 7 July 2014 20:12, Mark Nottingham <mnot@mnot.net> wrote:

> Thanks, Greg.
>
> I'm very much of two minds about this proposal.
>
> On the one hand, it's very late in the process; if these issues and this
> proposal had been articulated six or even three months ago, we'd be having
> a very different conversation. We committed at our recent meeting to go to
> WGLC on a tight schedule, and it's not at all certain that such an invasive
> change is necessary to resolve the underlying issues. As such, I suspect
> implementer enthusiasm is going to be dim (and yes, I saw the attempt to
> address this in the write-up).
>
> On the other hand, it is a very interesting proposal, and it does seem to
> address many potential objections as well as the underlying issues. As
> such, I want to see the Working Group take it seriously; we cannot simply
> ignore it, if only because doing so is very likely to get us an even larger
> delay in our LCs and beyond.
>
> I'm currently discussing this with our AD to make sure we get the balance
> right.
>
> Stepping back, I'll make one observation -- we're seeing a lot of
> proposals, and I think the underlying issues are still muddy. I've tried to
> separate them out in the issues list; see:
>    https://github.com/http2/http2-spec/issues/549
>    https://github.com/http2/http2-spec/issues/550
>    https://github.com/http2/http2-spec/issues/551
>
> If we can't gain consensus one of our current proposals, we're still going
> to need to have good answers for each of these issues.
>
> Regards,
>
> P.S. I suspect that the relative silence from many over the last few days
> is due to the US long weekend; welcome back,and please get into the
> discussion ASAP.
>
>
> On 7 Jul 2014, at 6:39 pm, Greg Wilkins <gregw@intalio.com> wrote:
>
> >
> >
> >
> > On 7 July 2014 18:27, Mark Nottingham <mnot@mnot.net> wrote:
> > Hi Greg (et al),
> >
> > Thanks for the proposal. The most immediate concern I have here is how
> SETTINGS is used; see my recent e-mail to Jason.
> >
> >
> > Mark,
> >
> > In reference to your comment:
> >
> > > SETTINGS is explicitly not a negotiation mechanism; it only allows one
> end to advertise its configuration to its peer.
> > >
> > > In this case, the semantic of MHS (MAX_HEADER_SIZE) would be roughly
> "I allow headers
> > > coming at me to be at most THIS BIG." There's no way for the peer to
> ask for more; it has to
> > > accept the limitation.
> >
> > Correct!  This is not intended to be a negotiation, it is simply
> intended to make explicit the current HTTP semantics that allows a server
> to reject large entities.    It is not an invitation to haggle with an
> endpoint, the endpoint is simply saying - don't even think about sending me
> a header larger than this setting.
> >
> > Endpoint already have limitation, which can only be discovered by
> attempting to send a header block, only to receive a 413.  This proposal
> puts the burden on the sender rather than the receiver to enforce such
> limitations.
> >
> > cheers
> >
> >
> >
> >
> >
> >
> > --
> > 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.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>


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