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

[Michael Welzl]

On 19. sep. 2012, at 15:14, Eggert, Lars wrote:

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

You don't know. You can measure, and estimate, leading to a probability; you can correlate delay measurements too. But I think the core of this discussion is at the end of the email.


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

Yes, I agree 100% (see my earlier postings to the list, one of them called "one congestion control to bind them all"  :-)   ).
What makes it harder is that RMCAT isn't supposed to do congestion control for rtcweb *only*, and so it would be better to think of a more generic model, in which one could essentially implement what you describe here for rtcweb, but also install a shared bottleneck detection mechanism and use that for one's own benefit for multiple non-rtcweb flows.

This can be addressed by designing an as-simple-as-possible element for exchanging the state of flows (a FSE), which I described earlier in messages to the list.


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

I think an up-to-date literature survey would be interesting. A relatively recent example, with application, is:
Sofiane Hassayoun, Janardhan Iyengar and David Ros, “Dynamic Window Coupling for Multipath Congestion Control”. In Proceedings of IEEE ICNP 2011, Vancouver, October 2011.

However, I don't think the IETF would need to standardize a shared bottleneck detection mechanism per se. Just the type of information exchanged, for flows that are identified to share the same bottleneck by whatever means (multiplexing over the same 5-tuple or some measurement based technique).

Cheers,
Michael