- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 4 Jul 2014 13:10:16 +1000
- To: Michael Sweet <msweet@apple.com>
- Cc: Greg Wilkins <gregw@intalio.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Michael, As a reminder, we’re using ALPN tokens to identify the protocol in use, regardless of whether TLS is actually in use. E.g., in the upgrade exchange, we use an ALPN protocol identifier; likewise in alternative-services. See: http://http2.github.io/http2-spec/#versioning On 4 Jul 2014, at 1:06 pm, Michael Sweet <msweet@apple.com> wrote: > Mark, > > ALPN tokens don't address clear text HTTP/2, which I'm guessing matters to low-resource end points. > >> On Jul 3, 2014, at 6:58 PM, Mark Nottingham <mnot@mnot.net> wrote: >> >> Hi Greg, >> >> Thanks (and thanks also to Amos for elaborating). >> >> Some responses below… >> >>> On 3 Jul 2014, at 5:11 pm, Greg Wilkins <gregw@intalio.com> wrote: >>> >>> • The max acceptable size will be declared in a SETTING, allowing for it to be know in advance >> >> True, but that’s the case for *individual* frames already (see below for the CONTINUATION case) >> >> >>> • max frame size can be adjusted down for low resource impls. >> >> OK. This seems like a general argument for JUMBO, not one regarding CONTINUATION. There are other ways to get there, and the consensus has been that a low-resource ALPN token would be the way to go here, because there are many different aspects that would need to be “tuned”, not just frame size. >> >> >>> • A true jumbo frame has its total size in the first frame, so an impl can immediately know if it is acceptable or not. With continuations, you might have to process 5 frames to reach a 64KB limit, only then to find out that their is a 6th frame and you have to throw away all that work done. >> >> As Amos says, this is the big one. >> >> I’ve heard it argued that CONTINUATION on smaller-than-16k chunks is useful, because it allows you to flush your buffers on sending. However, in the current design, it seems like that’s pushing a problem off of the sender and onto the recipient, which isn’t a great dynamic. >> >> I’d like to hear what people think about this. It seems like, because of the nature of HTTP headers, either the sender or the recipient needs to be able to buffer them in entirety (yes, there are tricks one can play in certain situations, but that doesn’t hold in the general case). >> >> Would it be interesting if using CONTINUATION required prefixing their size so that recipients can make this up-front decision? >> >> Note that there are a few different forms this could take; e.g., it could be a byte count, or it could be a “reservation” of the number of continuations that the sender thinks they’re going to need. >> >> >>> • The code path for handling large or small frames will be pretty much the same for jumbo frames, with the exception of the code that determines the frame length. With continuations, there is a significantly different code path that will be executed only for headers that are larger than 20-something KB. This is a code base that will be rarely used and thus probably not well tested. Here be dragons! >> >> Understood. >> >> >>> • Jumbo frames can also be applied to data frames (IF both the endpoints so desire). This can be done to either simply tune the frame size to the most efficient size for the network (eg the fast hop between a load balancer and application server maybe able to have a much larger frame size and still have good multiplexing), or it may even be used to allow a single frame to send very large content. >> >> This drops us back into the jumbo argument. Allowing large DATA frames defeats the goals of multiplexing, and would only encourage clients to use multiple connections, putting us into the same situation with have with /1. While it’s easy to imagine non-browser, specialist uses of HTTP where both ends know that only one request will be outstanding at a time and therefore able to agree to this, in the general case this is not so. >> >> This is true regardless of the type of Web site, because browsers are the clients and browsers can’t make that assumption; the user might open up another tab to that site, the JS might ask for another fetch, the user might navigate, etc. etc. >> >> That’s what led me to say that we didn’t have consensus to add jumbo frames; it’s been discussed at length, and I’m not inclined to revisit it unless there’s genuinely new information that’s capable of changing peoples’ minds. I asked this question to find out why jumbo advocates were so down on CONTINUATION, not to reconsider jumbo. >> >> >>> • Closing stuff down is just really hard. No its harder than that! I mean really really difficult! SSL handshakes, half closed TCP connections, race conditions, blah blah blah - it is just really really really difficult to write robust code that always closes neatly, without double/triple work and does not leak any resources. Any simplification in this part of the code will be really really really valuable. >> >> Understood, and I think widely and violently agreed to. This is a secondary effect, but well worth noting. >> >> >>> • Jumbo frames means that the END_STREAM flag is set on the last frame of a stream. It is a real WTF moment for anybody looking at the spec when they see CONTINUATIONS can be sent after END_STREAM. The confusion this causes should not be underestimated and reading this list is a good indication of the communication problems that will result. >> >> Right. That’s something in the design that’s worth exploring, if at least so that everyone understands the tradeoffs. >> >> >>> • A finally - CONTINUATIONS are jumbo frames. If it quacks like a duck…. >> >> When you have a hammer… ;) >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> -- Mark Nottingham http://www.mnot.net/
Received on Friday, 4 July 2014 03:10:49 UTC