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

[Ali C. Begen (abegen)]

> > 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.

> 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.
 
> Now that we're probably clear on what we are talking about, how should
> we express this to get the right understanding at the reader?

Some wording in the intro section could help with this.

Thanks.
-acbegen