- From: Mike Belshe <mike@belshe.com>
- Date: Tue, 8 Jul 2014 17:50:04 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: Jeff Pinner <jpinner@twitter.com>, Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABaLYCtXaew30yo+28R_Mo5Y3KMkc7CdnobBm9zf+mkVmU+UCQ@mail.gmail.com>
On Tue, Jul 8, 2014 at 5:33 PM, William Chan (陈智昌) <willchan@chromium.org> wrote: > On Tue, Jul 8, 2014 at 3:01 PM, Mike Belshe <mike@belshe.com> wrote: > >> >> >> >> On Tue, Jul 8, 2014 at 9:39 AM, Jeff Pinner <jpinner@twitter.com> wrote: >> >>> To be clear, the proposal is: >>> >>> 1) Remove the reference set from HPACK (use "Linear-H") >>> >> >> +1; Kazu's data convinces me entirely. >> >> >>> 2) Increase the frame size to 16-bits >>> >> >> +1 to increase the size. I would support going larger; the artificial >> limits never provided value in SPDY nor H2. I liked Greg's proposal >> generally. >> > > Just chiming in to note that this statement is factually incorrect, since > Patrick identified several instances where serialization latency of large > DATA frames was substantial. You can subjectively say this is little value, > but saying it has no value is simply false. > We all know that depending on what network/configuration/content you're rendering you'll see different results between 4kb, 12kb, and 16kb. These tests go back to the origin of SPDY. What I was trying to say is that you can have a larger maximum size and yet use a smaller size to get better performance if that suits you. So the "little value" means that it doesn't inhibit using well suited frame sizes. Conversely, if you are running a case where larger frames would help, you cannot go beyond an artificially low maximum. I believe most implementations will voluntarily use smaller sizes for performance reasons without having to put a hard coded constant in the frame size. We certainly did this in the early spdy implementations, and it worked. Since it was working, clearly the artificially smaller frame size is optional - you can still achieve good performance without it, and that is why I claim it has minimal value. Mike > > >> >> >>> 3) Allow interleaving of HEADERS frames >>> 4) Remove the "\0" separator hack. >>> >> >> +1; these were hacks unresolved due to the global compressor. >> >> >>> >>> Coupling this with my earlier proposal to add a "SYN_STREAM" header >>> would also allow us to: >>> >>> 5) Remove CONTINUATION frames entirely >>> >> >> +1; this makes things much simpler. >> >> >>> 6) Move END_* flags to the last HEADERS frame >>> >> >> +1; makes things simpler. >> >> >>> 7) Flow control HEADERS frames >>> >> >> +1; this is just simpler too. >> >> Mike >> >> >> >> >> >
Received on Wednesday, 9 July 2014 00:50:31 UTC