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

[Wesley Eddy]

On 9/19/2012 8:30 AM, 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? 


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.


>>     - 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)?
> 


This was related to the "Internet suckage" metric.  I don't know of a
concrete proposal, but obviously things like measuring the queue and
the delay variation could be first cuts.

Basically, if you're failing to deliver interactive traffic because
of bufferbloat and competing flows, this would help to point the
finger at the guilty party, so maybe it can be fixed.

-- 
Wes Eddy
MTI Systems