On Jul 8, 2014, at 8:24 AM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote: > ... > If we are going to expand length bits, I very much support this approach. > We get 64K - 1 payload and Kerberos headers is supported which is only known use case I heard so far. > By requiring implementations to fully process 64K frame, we don't need additional settings at all (and no WINDOW_UPDATE abuse). Implementations are free to return 431 or RST_STREAM within their limits but just keep running HPACK decompressor to stay connected. > This is far more simpler than the proposal and not invasive at all. We just goes back to the state when we decided that frame payload size should be 16K. 32-64k is probably the sweet spot for 1080p video, and 64k is what we use for printing today. So if we deployed HTTP/2 right now, using 16 bits for the frame length would address those two common use cases. That said, the downside of stopping at 64k-1 is that it will force an extension or new version of HTTP if it turns out that 64k-1 isn't enough for emerging content like 4k streaming video. On the few 4k video files I have, the average video/audio frame size varies from 17k for a highly-compressed Blender animation to 101k for an underwater video sequence. I'll grant that most video streaming applications do employ buffering to minimize the impact of interruptions in the data stream, but we should also try to design a protocol that can scale moderately well and allow clients and servers to deliver content in pieces large enough to do useful work (see my other post on the subject). _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 8 July 2014 13:03:31 UTC