[R-C] Congestion control requirements - I-D format, -01a version

[Harald Alvestrand]

On 03/04/2012 12:42 AM, Fred Baker wrote:
> On Mar 3, 2012, at 11:54 PM, Harald Alvestrand wrote:
>
>> To my way of thinking, the one-way case can usually tolerate delays of several seconds (see the "wardrobe malfunction buffer" used in the SuperBowl, for instance). I see this as out of scope for this set of requirements (although it's not unlikely that solutions we come up with here can be applicable to this use case).
> My suspicion: a wardrobe malfunction buffer - which is actually reasonably common in broadcasting - receives the signal, stores it for a time interval, and sends it again. I would expect that to be two separate data streams, one that among other places goes to it, and one that comes from it to a different set of places. I would expect that congestion control would apply to both of those data streams independently.
Yup, that would be the simple implementation.

However, some algorithms in video encoding can achieve significant 
compression by looking into the future and encoding a frame as a delta 
from a frame that the receiver hasn't seen yet (B-frames are one 
example). One could imagine that the wardrobe malfunction buffer could 
be used for that decision making.

The "interactive" part of "real time media" according to the definition 
I'm trying to use is that since you don't know the future, and don't 
have a large time budget to make it appear that you do, that kind of 
shenanigan is not possible.