On 4/5/2012 11:21 AM, Michael Welzl wrote:
On Apr 5, 2012, at 4:03 PM, Justin Uberti wrote:
On Thu, Apr 5, 2012 at 8:14 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
I have now figured out that the best way to do transport for RTCWEB would involve using only ONE type of congestion control for everything (note that I'm not making any specific argument here about whether this is based on draft-alvestrand-rtcweb-congestion or LEDBAT or whatever).
[SNIP]
I think that the correct solution to that problem is to have only one type of congestion control, make it (mostly) delay-based to minimize queuing delay, and let that congestion control dictate the total rate available to the RTCWEB sender. Then, let the sender schedule packets across the video-, audio- and file-transfer streams based on some fairness policy. This gives you the best possible control over fairness as an extra - it's much better than trying to influence how the flows compete with each other on the bottleneck. Well, and again it seems to me that SCTP looks ideal for that type of usage.
Theoretically, it could perhaps be okay to use multiple different types of delay-based (delay-minimizing) controls in parallel, e.g. using draft-alvestrand-rtcweb-congestion-01 for video / audio and LEDBAT for data transfer, but that just seems to make the situation more complicated and it would give you less control over the fairness among the streams.
Curious to hear what you think :-) because I *know* I'm right :-D
Justin replied:
I think we agree - to avoid the exact problems you mention, the plan has been to replace the SCTP CC module with a CC that is common across media and data.
Oh, cool! I wasn't aware of that - is that documented somewhere? Sorry if I missed it! I'm a bit new to the whole forest of RTCWEB documents...
If you read the early archives of this list (and discussions predating it on rtcweb), you'll find that goal articulated a number of times. As one of those driving the congestion-control issue and also the data channel design, I've always spoken to wanting to in some manner merge the congestion control regimes of media and data flows, and barring that to at least provide feedback between them. The last fallback to avoiding problems would be to partially punt the problem up to the application (which also knows the relative priorities of the media and data, and of each data flow), by reporting back to the JS application the current automatic distribution of available bits to the different streams, and allow the application to change the distribution of those bits to the various media and data sub-flows (but not let it increase the total number of bits sent directly; it could decrease it directly or indirectly (by removing flows, such as dropping a video stream, etc)). We will very likely be doing that application-level reporting, and probably allowing the application to adjust the distribution. My proposal on the API for that is outstanding in the W3 side of this standardization effort. I spoke more directly to this at the rtcweb Interim meeting in Febuary; my slides are at: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-1.pd... The relevant slides are 10-13. While not stated on the slides, this discussion emanates from the goal to in some manner merge them or make them work together (and not fight), and this was I think re-iterated from the podium there. -- Randell Jesup randell-ietf@jesup.org