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

[Eggert, Lars]

Hi,

On Sep 19, 2012, at 14:58, Michael Welzl <michawe at ifi.uio.no> wrote:
> 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.

how do you *know* two flows share a bottleneck?

You could *assume* they do if, e.g., they share a path, i.e., run between the same two IP addresses concurrently in time. But even then - thanks to ECMP routing, datacenter load balancers, etc. - you don't really know.

Or you could try and correlate loss events, but I don't know how robust that is.

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

Yep, building a mechanism for this case is easy - *detecting* that a set of flows is limited by a shared bottleneck is harder.

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

Ah, I see. We're not looking at the general problem here. Under the definition above, you don't actually have multiple flows. You have one flow (five-tuple) into which multiple senders are transmitting. That's a *much* simpler problem, because we actually don't need a combined congestion controller here, all we need is a priority scheme for which sender gets what fraction of the flow capacity.

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

Somebody needs to seriously look into how practically applicable they are, before we can use them as a basis for an IETF mechanism. I have seen a bunch of measurement papers, but I don't recall one that struck me as particularly real-world applicable. (This is probably my fault for not being up-to-date with what's out there now.)

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120919/3a79ab35/attachment-0001.bin>