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

[Michael Welzl]

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

> Hi,
> 
> On Sep 19, 2012, at 15:27, Michael Welzl <michawe at ifi.uio.no> wrote:
>> What makes it harder is that RMCAT isn't supposed to do congestion control for rtcweb *only*,
> 
> actually, I would be *thrilled* if we came up with a good scheme that would work for rtcweb only. I think multi-flow congestion control (where flow means "different five-tuples") will be quite difficult, irrespective of whether some or all flows are rtcweb.

FWIW, Google's current proposal would probably already work for rtcweb, if having one such mechanism for rtcweb is all we want and need. I don't understand what makes multiple flow (i.e. different five-tuples) congestion control so difficult? You have, from the LFE, the information which flows share a bottleneck. Say, not based on the 5-tuple-multiplexing, but based on heuristics. (in my opinion, this shouldn't make a difference, but okay)

So then? For those flows, you can do the things in the style of RFC2140 (which is for TCP of course, but it gives the idea).


>> 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.
> 
> I'm kinda worried that the "congestion control for rtcweb" is ballooning into "internet congestion control 2.0". If there was something simple that could be done for integrated CC of multiple parallel flows, that'd be nice, but I don't really see it.

I don't see that balloon. What's your worry?


>> 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.
> 
> I think it is still too complex, because you envision this being a separate entity somewhere in the OS of the host. That'll take a long time to deploy and get used. I wonder if a similar exchange inside the *browser* would be a good enough first step. So the browser can be smart about prioritizing the aggregate traffic it sends and receives, but it will still compete with other apps on the same host. Tough luck. Even with an OS-based scheme, the host will still compete against other hosts in the same LAN, so it's not like the host based solution is the end-all anyway. (And yeah you could share this information around the LAN, but then we enter security hell.)

Indeed, in the browser if you want, as I wrote in the message in which I introduced the idea of an FSE:
http://www.alvestrand.no/pipermail/rtp-congestion/2012-July/000436.html

"An FSE is a *passive* entity on a host that receives congestion- 
control-relevant information from RTP flows and provides that  
information upon request. It resides on a host, and if we define it in  
the right way it probably doesn't matter at which layer: one could  
have an FSE inside the browser, and optionally have the browser talk  
to an additional system-wide FSE in the kernel. Note that this is not  
the Congestion Manager (RFC3124): the CM was an *active* entity, much  
more complicated to realize, and much closer to the "single congestion  
control instance" idea described above."

I guess you never read that statement though, because even then you responded to this message by saying that this sounds a lot like RFC3124  :-)

My point is: we've been through this discussion already. I *think* (would have to check) we also already have agreed to keep this on one host, as you suggest above. Anyway, I definitely agree, this is one-host-only.


>> 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).
> 
> I think we would need to at least informally describe some mechanism that gives a benefit, in order to demonstrate that the scheme is actually worth the cost. We don't need to mandate its use, but it would sure be nice if we had some sort of argument that this information exchange is actually beneficial.

... and since I don't see a difference between feeding the FSE with a set of flows because of measurements, or because these flows happen to be multiplexed over the same 5-tuple, I felt that this is not necessary. "They share a bottleneck because they're multiplexed over the same 5-tuple" is just another shared bottleneck detection mechanism.

Anyway, I have no problem with informally describing some mechanism that gives a benefit. Whether we'll be able to agree on a mechanism being good enough is a different story. Perhaps. We'd need to look at the literature. I'm not opposed to that.

Cheers,
Michael