[R-C] Modular Congestion Control in rtcweb

Luca De Cicco ldecicco at gmail.com
Tue Mar 27 15:15:17 CEST 2012


Well, that's a good point, of course there are pros and cons here.

The pro is that using the socket interface is super-simple from the
application point of view, the downside (and that's a though one)
is that having a new protocol developed for an operating system
is not a piece of cake.
For what I know, DCCP is only supported by the Linux kernel as of today.

I think developing the congestion control in the userspace is still
a good idea to speed up deployment.

Cheers,
--
Luca De Cicco, PhD, Eng.
Politecnico di Bari
Dipartimento di Elettrotecnica ed Elettronica
Via Re David, 200 - Bari - ITALY
Office: +39 080 596 3851



On Tue, Mar 27, 2012 at 3:00 PM, Wesley Eddy <wes at mti-systems.com> wrote:
> I think the first question that should be answered is why
> not just use DCCP where this modularity already exists.
>
> I think the answer might be that if you buy the requirement
> to operate across multiple flows, and that you're doing the
> muxing of them via RTP, then the feedback also needs to come
> via RTP rather than on an aggregate below that DCCP might
> provide.
>
> This should probably be discussed though.
>
>
> On 3/27/2012 8:46 AM, Luca De Cicco wrote:
>> Well, I guess the first step is to define an interface that  congestion control
>> modules should use. We could base this effort on the requirements defined
>> in draft-jesup-rtp-congestion-reqs.
>>
>>>From the implementation point of view, we should discuss how to
>> distribute congestion control algorithms. Should we allow distribution
>> of cc algos
>> as  browser plug-ins to extend the ones standardized by the webrtc effort?
>>
>> What do you think?
>>
>> Cheers,
>> --
>> Luca De Cicco, PhD, Eng.
>> Politecnico di Bari
>> Dipartimento di Elettrotecnica ed Elettronica
>> Via Re David, 200 - Bari - ITALY
>> Office: +39 080 596 3851
>>
>> On Tue, Mar 27, 2012 at 2:24 PM, Wesley Eddy <wes at mti-systems.com> wrote:
>>> On 3/27/2012 7:25 AM, Luca De Cicco wrote:
>>>> Dear all,
>>>>
>>>> this mail follows a thread I've recently started at rtcweb at ietf.org.
>>>> and moved to this mailing list following Harald's suggestion.
>>>>
>>>> Since congestion control is a fundamental building block
>>>> for a multimedia communication framework such as webrtc,
>>>> I think it makes sense to design the framework to allow
>>>> using different congestion control algorithms such as it is
>>>> done with audio/video codecs.
>>>>
>>>> Are there any plans to make the congestion control algorithm
>>>> modular for multimedia transmission via PeerConnections?
>>>>
>>>> This would require the peers to select a particular congestion
>>>> control algorithm at the establishment of the PeerConnection
>>>> similarly to how the DCCP [1] protocol does at kernel level.
>>>>
>>>
>>> It seems like a good idea to me, in order to make it
>>> potentially easier to deploy upgrades to the algorithms
>>> over time (especially since it seems that the algorithms
>>> will start as question marks).
>>>
>>> This also motivates the question of why RTP over DCCP
>>> isn't a potential solution.
>>>
>>> --
>>> Wes Eddy
>>> MTI Systems
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>>
>>
>
>
> --
> Wes Eddy
> MTI Systems


More information about the Rtp-congestion mailing list