[R-C] DCCP as an RTCWEB option (Re: Modular Congestion Control in rtcweb)

Thu Mar 29 00:41:55 CEST 2012

... and, FWIW, my comment at the meeting yesterday was also  
specifically about DCCP over UDP. I think it's clear that if DCCP can  
be a choice, than only over UDP.

On Mar 29, 2012, at 12:17 AM, Luca De Cicco wrote:

> Dear Harald,
>
> just to be clear, I was considering DCCP (at userspace) only because  
> it
> supports pluggable congestion control (which was the main point of
> the thread "Modular congestion control"), so that it could be used  
> as a
> starting point at least for the definition of a common interface for  
> congestion
> control algorithms.
>
> Cheers,
> Luca
>
>
> On Wed, Mar 28, 2012 at 11:20 PM, Harald Alvestrand
> <harald at alvestrand.no> wrote:
>> If you are thinking of DCCP as "DCCP in the kernel, using proto=33  
>> on the
>> network", the answer is simple: This is not deployable as a part of a
>> browser deployment.
>>
>> Browsers are deployed fairly rapidly across the Net, but have to  
>> run on a
>> variety of platforms, and have no control over the platform they  
>> run on.
>> Installing a new protocol is not an option; limiting deployment to  
>> the
>> subset of the market that supports DCCP today, and is behind  
>> firewalls and
>> NATs that do the right thing with DCCP now (or within 12 months) is  
>> also not
>> an option.
>>
>> So DCCP in the kernel is not compatible with the goals of RTCWeb.
>>
>> DCCP over UDP is more realistic to deploy, given that UDP already  
>> passes
>> firewalls. This is the major reason why, for a peer-to-peer data  
>> protocol,
>> the SCTP/DTLS/UDP stack was felt to be a reasonable option; another  
>> major
>> factor was the fact that we have code for an userland stack that is  
>> known to
>> run on several OSes already available.
>>
>> Given the lack of tested userland stacks for DCCP, and the wide  
>> availability
>> of userland stacks, protocol analyzers and other tools for RTP over  
>> UDP, the
>> RTCWEB WG chose to not investigate the use of DCCP for RTP  
>> transport any
>> further.
>>
>> Others who were part of that discussion may have more to contribute.
>>
>>                       Harald
>>
>> On 03/27/2012 03:15 PM, Luca De Cicco wrote:
>>>
>>> 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
>>>
>>> _______________________________________________
>>> 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