Hi, On Sep 19, 2012, at 15:27, Michael Welzl <michawe@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.
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.
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.)
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. Lars