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

Mirja Kühlewind mirja.kuehlewind at ikr.uni-stuttgart.de
Wed Sep 19 22:23:46 CEST 2012


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. 
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.

>
> >>     - 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.
>
> 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.

hm, isn't this quite a topic on its own and actually might simply belong in 
the IPPM working group at least as long if there is no very specific case why 
something is different for RT traffic? Maybe it's not so much about the 
measurement techniques but the way how the interpret the measured metrics 
(when sending RT traffic)?

Mirja




More information about the Rtp-congestion mailing list