Re: Large Frame Proposal

Greg,

On Jul 7, 2014, at 6:36 PM, Greg Wilkins <gregw@intalio.com> wrote:
> On 8 July 2014 04:48, Nicholas Hurley <hurley@todesschaf.org> wrote:
> Let's please not conflate the issue of large headers with video
> 
> +1
> 
> I actually think that if you asked those that server video, they are not likely to want huge frame sizes.  There is little point sending video much faster than it can be watched, as to do so means that you need lots of buffering in the client and when they decide they've watched enough of the very cute kittens and press stop, you've sent a lot of bytes that were not consumed.
> 
> OK I know it is actually impossible to stop watching a cute kitten video, but I'm sure there are use-cases to which my argument applies.
> 
> Video is a use-case where frame size probably needs to be optimised, but not necessarily up.

Frame size optimization means balancing (perceived) latency with bandwidth/processing efficiency.  Let's call this the LRRH ("Little Red Riding Hood") principle - not too big, not too small, "just right".

For printing today the optimal frame size seems to be 64k.  I'm guessing that video will be similar, if only because the data volume is similar and interruptions in the data stream can cause stuttering or paused output.  A 1080p MPEG-4 movie file on iTunes averages about 28k per video/audio frame (24 frames per second) - you'll need two 16383-octet DATA frames to hold that, while a single 64k DATA frame can hold two video/audio frames.

So I actually think that many bulk data "pipes" will desire to use a larger frame size than 16383, but that size will reflect a balance of what is "just right" for the application - not infinite, but a number that provides perceived/visible improvement without adversely affecting things for any of the involved parties, otherwise you can kiss any improvement goodbye.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair