Subject: Back to the drawing board? was: #540: "jumbo" frames

From: Greg Wilkins <[email-masked]>
Date: Wed, 25 Jun 2014 12:36:48 +0200

On 25 June 2014 12:20, David Krauss <[email-masked]> wrote:

> I’ve not been following this (my implementation is on hold as it seems
> HTTP/2 is going back to the drawing board) but any “jumbo frames” scheme
> should be amenable to hardware implementation.

David,
I encourage you to progress your HTTP/2 impl, as I certainly found that
doing so has greatly improved my understanding of the draft and the issues
associated with it.

While I think there are outstanding issues, I'm not sure that the continued
discussion of them does mean that we will go back to the drawing board, nor
that the WG thinks those issues are not adequately addressed.  The current
draft is implementable and there does appear to be considerable interest in
going forward with it to see how it goes.

ie, whilst the current draft is not how I would do it if I were god,  I
could live with most of it if it did become an RFC..... and would revel in
the "I told you so" rights I would get when we are all back here in a few
years because it failed to be widely adopted or we have to work out how to
deal with the growing usage of massive headers :)

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jun 2014 14:27:12 +0200

> deal with the growing usage of massive headers :)

Worst part of it, it will not fail, it will succeed and will come with its
bag of new problems (though it will obviously solve some). It will be a bit
like Set-Cookie, NTLM or chunked encoding, it will probably itch over the
long term, but we'll adapt to it using extra hardware and more complex code
or tricks.

Willy

---

From: David Krauss <[email-masked]>
Date: Thu, 26 Jun 2014 00:15:11 +0800

On 2014–06–25, at 6:36 PM, Greg Wilkins <[email-masked]> wrote:

> I’ve not been following this (my implementation is on hold as it seems HTTP/2 is going back to the drawing board) but any “jumbo frames” scheme should be amenable to hardware implementation.
> 
> David,
> I encourage you to progress your HTTP/2 impl, as I certainly found that doing so has greatly improved my understanding of the draft and the issues associated with it.

I’m not quitting :) but at the moment, I don’t have as much to add to the group effort as I’m less far along, and it’s better to conservatively wait out any possible churn as my system is less amenable to rapid prototyping.

> While I think there are outstanding issues, I'm not sure that the continued discussion of them does mean that we will go back to the drawing board, nor that the WG thinks those issues are not adequately addressed.  The current draft is implementable and there does appear to be considerable interest in going forward with it to see how it goes. 

“Back to the drawing board” might have been a little strong, heh, I just meant the framing layer and the protocol-wide state machine that tracks header blocks are pretty fundamental.

> ie, whilst the current draft is not how I would do it if I were god,  I could live with most of it if it did become an RFC..... and would revel in the "I told you so" rights I would get when we are all back here in a few years

As a newbie, this group has always responded nicely to my ideas, even if I don’t have much “push.” Things currently seem to be going in a good direction. The immediate effort with headers and framing is for minimizing RAM and cycles per stream, and that’s the bread and butter of the whole operation.

> because it failed to be widely adopted or we have to work out how to deal with the growing usage of massive headers :)

Massive headers I find worrisome, only because they are already theoretically supported by HTTP/1 but implementations universally impose limitations. The existing practice needs more emphasis. But, this too seems to be getting addressed currently.