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

[Justin Uberti]

On Sun, Apr 8, 2012 at 1:59 PM, Michael Welzl <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.


>
>
>  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.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.
>
> Cheers,
> Michael
>
>
> ______________________________**_________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120408/59d6a214/attachment-0001.html>