[R-C] Modular Congestion Control in rtcweb

[Piers O'Hanlon]

It may well have been covered already but since SCTP is already proposed for data transport and it supports unreliable transport and has some support for pluggable congestion control then if one could specify RTP over SCTP which could provide another possible approach? It could also potentially simplify some aspects of inter-stream congestion control.

Piers

On 28 Mar 2012, at 01:11, Luca De Cicco wrote:

> 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
>> 
>> 
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion