[R-C] WG Review: RTP Media Congestion Avoidance Techniques (rmcat)

[Randell Jesup]

Moving discussion to RMCAT...

On 9/20/2012 3:02 AM, Michael Welzl wrote:
> On 19. sep. 2012, at 22:23, Mirja Kühlewind wrote:
>
>> Hi,
>>
>>>> provide further explanations here:
>>>>>     - Develop a mechanism for identifying shared bottlenecks between
>>>>> groups of flows, and means to flexibly allocate their rates within the
>>>>> aggregate hitting the shared bottleneck.
>>> The original motivation for this was pretty simple.  If you knew two
>>> flows with different elasticities were sharing a bottleneck, and seeing
>>> loss, you could make the congestion reaction on the more elastic flow,
>>> and leave the less elastic one untouched.
>> Okay, I can understand this point. But if fact if you see congestion and you
>> are elastic (up to a certain degree), you should lower your sending rate (or
>> do whatever you can do) because there also might be other flows on the link
>> that need the bandwidth even more urgent.
> With combined congestion control, this (lowering the send rate) will happen. Consider having only one controller; then, "making the congestion reaction on the more elastic flow" translates into a change to the scheduler that takes data from application 1 and application 2 in addition to the standard congestion control reaction for what looks like one flow to the network.

You can also proportionally allocate the reduction, etc.  This just 
allows for more direct interaction, potentially less 'hunting' and less 
chance of corner-case behaviors, and faster reaction (most algorithms, 
especially delay-sensing algorithms) need some number of inputs to 
ensure a datapoint isn't jitter or an outlier (i.e. filtering the 
data).  More data points from parallel flows should lead to 
better/faster reaction time.

>
> (in fact, the way I envision it, this behavior would be the result of information exchange between multiple controllers).
>
>
>> I guess the only case I really see is if there is not enough bandwidth for
>> both transmissions (such that both of the respective services do not work
>> proper) and you have to decide which one to kill. But that's the
>> circuit-breaker case and thus out of scope.
> This sounds like a misunderstanding. I hope what I wrote above and my previous email help. Else, maybe you'd want to take a look into the list archives for more information; this has been discussed at some depth in the past. BTW, Randell Jesup has, at some point, stated that Mozilla is already using such scheduling / combined congestion control.

Already planning to use; not yet implemented.

-- 
Randell Jesup
randell-ietf at jesup.org