On 4/8/2012 10:41 PM, Justin Uberti wrote:
On Sun, Apr 8, 2012 at 1:59 PM, Michael Welzl <michawe@ifi.uio.no <mailto:michawe@ifi.uio.no>> wrote:
> 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.
I think I have seen and heard about the wish to let the user prioritize flows, and somehow avoid that the flows would be totally ignorant about each other - but this is not the same as what I'm suggesting: a *single* congestion control instance for everything.
Now I'm not sure if I get this right: 1) Justin's statement above means that there is a plan to have one single SCTP CC module for everything in the "data channel", but there will still be different congestion control for RTP/UDP transfer => then this is not what I mean, you still won't get the same efficiency as if you use one CC instance for *everything*, by which I really mean *everything*.
2) Justin's statement above means what I say here (one CC instance for *everything*) => then I have missed that and misunderstood the discussion, and just think it's good.
#2 is what I think we've had in mind - given that this is fairly greenfield territory, we should be able to have a mechanism that can handle both media and data. Said mechanism will still have to guess at non-RTP/SCTP flows, of course.
Correct - that was the stated goal, but thus far we don't have a definitive answer about how to do so. Note that harald's draft generates available bandwidth estimates for all channels together if you let it include bytes received by the SCTP connection in the period in question. This would at minimum allow the sender side to decide (at the application layer) on a media/data split, and then use that to enforce an upper limit for the SCTP connection. Even if we run everything in one congestion algorithm, we still need to have a mechanism for splitting the bandwidth between media and data channels; "normal" SCTP mechanisms would not suffice for media streams (see some of Justin's recent comments on send timing for examples of why).
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-... <http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-1.pdf> 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.
I saw that presentation, but I had interpreted it as being only about the SCTP data channel, which would be case 1) above. Even if you extend that to incorporate other streams with cross-reporting as you describe above, it sounds like a complicated vehicle that will, I think, never be as efficient as simply having a single congestion control instance for everything.
Perhaps true - but efficiency isn't necessarily the primary goal here; a quality experience for the user given the available bandwidth is, including "appropriate" splits of data and media. And the reporting is because the application has knowledge of state we can't have - for example if the 2nd channel of video is important, or to decide if any video at all is important, or that when extra bits are available they should go to higher resolution instead of faster data transfer, or higher-quality audio, etc. As discussed, the WebRTC system will apply an automatic distribution of available bandwidth according to static priorities given to it, but the app is given the choice to intervene. This activity by the app should not cause significant issues for the congestion control algorithm as mostly it's just redistributing the pie. -- Randell Jesup randell-ietf@jesup.org