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

Thu Mar 29 11:14:43 CEST 2012

On Mar 29, 2012, at 10:31 AM, Michael Welzl wrote:

> So here's an idea.
> 
> Main reason for DCCP: the negotiation of congestion controls.
> Main reason against DCCP: not much experience, no available efficient user-land implementation over UDP.
> 
> ... but the data channel will be done with SCTP, where an efficient UDP based implementation exists. And the question of pluggable congestion controls for SCTP was just raised here in the RTCWeb session. As Michael Tuexen just said, the FreeBSD implementation of SCTP provides that, but on a per-connection (not per-stream) basis (if I understood him correctly), and negotiation of congestion controls is not a part of the protocol spec. Given that SCTP also provides partial reliability
Correct.
> (which can be more useful for streaming media than DCCP's total absence of reliability too!), would it not be the most efficient way ahead to:
> 1) extend SCTP to have pluggable congestion control per stream and negotiate that,
Hmm. That is an interesting idea, you could do something like a coupled congestion
for all streams. Could work. But I guess some research has to be made.
> 2) incorporate that in the SCTP userland implementation,
The infrastructure is there to implement another CC for the association. That is
easy. Changing that to a per stream CC is more difficult...
> 3) use SCTP as the transport for everything??
> 
> That would then also give a good basis for the group's desired cross-steam-congestion management, I suppose.
> 
> Cheers,
> Michael
> 
> 
> 
> On Mar 29, 2012, at 12:41 AM, Michael Welzl wrote:
> 
>> ... 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
>> 
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> 
> 