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

[Luca De Cicco]

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
>>
>