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?