[R-C] Modular Congestion Control in rtcweb

Luca De Cicco ldecicco at gmail.com
Wed Mar 28 01:11:09 CEST 2012


Yes, it makes sense.  DCCP already defines a clear interface to
write CC algorithms. We could at least use that interface as a starting
point in the case DCCP is a no-go.

Cheers,
Luca
On Wed, Mar 28, 2012 at 1:03 AM, Justin Uberti <juberti at google.com> wrote:
> Browsers are trying to kill off plugins as fast as possible, so I don't
> think deploying CC modules as plugins is viable.
>
> The simplest thing would be to provide a generic C interface within
> Chrome/Firefox so that a 3rd party could easily build a private version with
> their own CC module inside it. We could then bundle implementations that
> looked promising into official builds and allow applications to negotiate
> them, like codecs. But we'd need to define a bunch of stuff to make this
> happen.
>
> On Tue, Mar 27, 2012 at 8:46 AM, Luca De Cicco <ldecicco at gmail.com> 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
>
>


More information about the Rtp-congestion mailing list