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

[Michael Welzl]

On 19. sep. 2012, at 14:30, Mirja Kuehlewind wrote:

> Hi,
> 
> I know I'm late to comment, but after reading the charter again, I have to 
> admit that two points are not absolutely clear to me. Maybe someone can 
> 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.
> Why do I need to identify shared bottleneck? The task of congestion control is 
> to shared the bottleneck capacity in some way. Usually I will end up with a 
> different share if the same or a different congestion control algorithm is 
> used by the competing flow(s). Is the idea here to detect a shared bottleneck 
> and then change the congestion control behavior to achieve a different share 
> than I would otherwise? I there a concrete scenario or approach how what to 
> do this and why this is needed in case a shared bottleneck is detected? 

This is about combined congestion control for a group of flows in case they share the same bottleneck.

Here's an example:
Consider two hosts and two flows between them. If they share a bottleneck, you could use only a single congestion controller for both. The share between them is then totally under the sender's control - the result of scheduling, and not the result of "fighting it out" on the bottleneck. From the queue's point of view, you're dealing with one, not two flows, leading to a reduction in queue fluctuations at least.

Examples of mechanisms designed to yield a benefit in such cases:
Congestion Manager: http://nms.csail.mit.edu/cm/
TCP Control Block Interdependence: RFC2140.

Example of a very prototypical implementation of a congestion-manager-like functionality via SCTP, yielding benefits, as a proof-of-concept:
Michael Welzl, Florian Niederbacher, Stein Gjessing: "Beneficial Transparent Deployment of SCTP: the Missing Pieces", IEEE GlobeCom 2011, 5-9 December 2011, Houston, Texas.

Example of a concrete scenario: in rtcweb, all traffic is (AFAIK) going to be multiplexed over the same UDP port-number pair. To be able to do any form of congestion control, it must therefore be assumed that all of these packets traverse the same path - which means that multiple flows multiplexed over this 5-tuple will share the same bottleneck.

(and then, there are several measurement-based mechanisms for shared bottleneck detection out there; essentially, they look for correlations in some measured values such as one-way delay)


>>    - Develop techniques to detect, instrument or diagnose failing to
>> meet RT schedules due to failures of components outside of the charter
>> scope, possibly in collaboration with IPPM.
> I believe I got the idea behind this but I not really sure how to realize it. 
> Are you expecting some explicit feedback from the receiver (or even other 
> components)? Is there a concrete proposal already how to do this? What are 
> you planning to do if you have detected an RT schedule failure? Change the 
> congestion control in some way (to be more aggressive)?

Many approaches are possible. I don't think that there is a concrete proposal out there already, but I suspect that there is some more concrete stuff on Matt Mathis' mind. He would be the right person to answer this.

Cheers,
Michael