Re: #541: CONTINUATION

On Tue, Jul 8, 2014 at 10:02 PM, Michael Sweet <msweet@apple.com> wrote:

> 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).
>
>
Why do we have to use same frame size for HTTP/2 with video's?
We can deliver multiple DATA frames for 1 video frame.  Also big frame
really hurts multiplexing many people stated earlier.

Best regards,
Tatsuhiro Tsujikawa






>  _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>