[R-C] One congestion control to bind them all!

[Randell Jesup]

On 4/8/2012 10:41 PM, Justin Uberti wrote:
>
>
> On Sun, Apr 8, 2012 at 1:59 PM, Michael Welzl <michawe at ifi.uio.no
> <mailto:michawe at 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-1.pdf
>         <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 at jesup.org