Re: Large Frame Proposal

Mark,

Speaking as an (almost completed) implementor, this proposal solves my issues with needing to implement CONTINUATION frames just to support Kerberos authentication - servers that need Kerberos authentication can advertise their ability to receive larger header frames; clients that can do Kerberos will already have the resources to send them.

It also solves an issue I haven't yet reported (mainly because I don't have any evidence for HTTP/2 yet) where many current printers benefit from larger frame sizes.  In current HTTP/1.1 implementations, going from a maximum chunk size of 16k to 64k has yielded a 2x performance improvement (over Wi-Fi or Gigabit Ethernet).  The overhead of processing chunks in a low-resource, embedded processor is fairly high, so anything we can do to tune the chunk/frame size to the maximum the printer can safely handle (i.e. avoid a deadlock situation that prevents our reporting a paper jam or other condition to the user) will make for a better user experience.


On Jul 7, 2014, at 6:12 AM, 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/
> 
> 
> 
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair