W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: #541: CONTINUATION

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 9 Jul 2014 00:50:09 +0900
Message-ID: <CAPyZ6=KeAcET3ocnX3EDFoL38G=mNKoXtodRbvw-6aVCaSkfqw@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, Jason Greene <jason.greene@redhat.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Johnny Graettinger <jgraettinger@chromium.org>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
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
>
>
Received on Tuesday, 8 July 2014 15:50:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC