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

[Randell Jesup]

On 3/3/2012 12:21 PM, Ali C. Begen (abegen) wrote:
>>> Stored or live, that is a separate discussion but in the case of streaming of one-way content, the crucial thing is the
>> tolerable delay not whether the content is pre-encoded or live.
>>
>> 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
> Yes, that was my point. But, in your definition of "real-time" such buffers are not acceptable. That is why I thought making it clear would be appropriate in the title and text. Both are real-time media but interactive one has a delay budgets which are far less.

True.

>> requirements (although it's not unlikely that solutions we come up with
>> here can be applicable to this use case).
> I am a bit skeptical about this. The one-way streaming that can tolerate seconds of delay needn't be as reactive to congestion or rate changes as the two-way conferencing apps. Time scales are quite different. Some tools/methods will of course be similar but they will not necessarily be identical or directly applicable.

One-way typically can tolerate lots of delay (and may want delay to 
locally buffer), but some "one-way" is actually interactive 
delay-sensitive - for example, remote surgery (and any sort of 
tele-operation).

-- 
Randell Jesup
randell-ietf at jesup.org