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

[Harald Alvestrand]

On 03/03/2012 02:16 PM, Ali C. Begen (abegen) wrote:
>
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald at alvestrand.no]
>> Sent: Saturday, March 03, 2012 8:03 AM
>> To: Ali C. Begen (abegen)
>> Cc: rtp-congestion at 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?