On 03/03/2012 01:33 PM, Ali C. Begen (abegen) wrote:

Looks like you are specifically talking about the reqs for interactive media. Then, I think the title should reflect that (as opposed to any real time media which would include one-way streaming). Actually I was using the definition of "real-time" from draft-ietf-rtcweb-overview:

Interactive: Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, with the total time required for the action/reaction/ observation is on the order of no more than hundreds of milliseconds. Media: Audio and video content. Not to be confused with "transmission media" such as wires. Real-time media: Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds). If you insist, I can add "interactive" to the title, but I don't think of one-way streaming of stored video as "real-time", and wouldn't want to encourage that idea.

-acbegen

...

-----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: Saturday, March 03, 2012 7:14 AM To: rtp-congestion@alvestrand.no; Randell Jesup Subject: [R-C] Congestion control requirements - I-D format, -01a version

These requirements are Randell's text, mostly, cropped into an I-D format and annotated a bit by me. I'll upload this to the I-D server tomorrow. Randell, is it OK to submit it with your name in the I-D name?

Comments are welcome for 24 hours starting .... now ....

Harald

On 03/03/2012 02:16 PM, Ali C. Begen (abegen) wrote:

...

-----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Saturday, March 03, 2012 8:03 AM To: Ali C. Begen (abegen) Cc: rtp-congestion@alvestrand.no; Randell Jesup Subject: Re: [R-C] Congestion control requirements - I-D format, -01a version

On 03/03/2012 01:33 PM, Ali C. Begen (abegen) wrote:

...

Looks like you are specifically talking about the reqs for interactive media. Then, I think the title should reflect that (as opposed to any real time media which would include one-way streaming). Actually I was using the definition of "real-time" from draft-ietf-rtcweb-overview:

Interactive: Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, with the total time required for the action/reaction/ observation is on the order of no more than hundreds of milliseconds.

Media: Audio and video content. Not to be confused with "transmission media" such as wires.

Real-time media: Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds). One hundred vs hundreds of ms makes a big difference IMO. I won't insist but these two types of apps have quite different requirements when it comes to congestion control.

I'm not sure which two types you are at any more.... The origin of the number is that webrtc-based solutions need to work well on Stockholm-California (where we routinely use our present conferencing solutions), with an RTT of ~170 ms today. We're not the extreme case for terrestrial high-capacity links, but the extreme case isn't a lot bigger. In the interest of not getting bogged down over exact numbers, I picked the "no more than hundreds of milliseconds" language. There are other changes in what you can do when the RTT is in the 70-ms range (twitch-style games) and 20-ms range (playing music together). But I didn't want those lower numbers to be used to drive our designs.

...

If you insist, I can add "interactive" to the title, but I don't think of one-way streaming of stored video as "real-time", and wouldn't want to encourage that idea. 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 requirements (although it's not unlikely that solutions we come up with here can be applicable to this use case). 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?

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@jesup.org

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.

On 03/04/2012 11:42 AM, Fred Baker wrote:

You realize that this mechanism, whatever it turns out to be, has one of the problems of reliable multicast; if the RTP service is one to many, the RTCP service is many to one, and that can be a lot for the one. You find yourself wanting to find some way to collude with it.

If for example it is built on conex, it will collect CE flags in the outbound path, and you will want some way of reporting the fact back. Imagine it's 1:1000000, CE gets set on the first hop out, and a million receivers decide to reply... Yep, I regard the multicast case as a distraction for RTCWEB, however, since it seems that trying to solve both multicast and unicast at the same time usually results in either no solution or no deployment.

Another thing to make clear in the introduction - that this is solving for the unicast case....