Dear all, this mail follows a thread I've recently started at rtcweb@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. Best regards, -- Luca De Cicco, PhD, Eng. Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 Refs. [1] Datagram Congestion Control Protocol (DCCP), RFC 4340, http://tools.ietf.org/html/rfc4340
On 3/27/2012 7:25 AM, Luca De Cicco wrote:
Dear all,
this mail follows a thread I've recently started at rtcweb@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
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@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@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
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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Wes Eddy MTI Systems
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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Wes Eddy MTI Systems
On Mar 27, 2012, at 15:15, Luca De Cicco wrote:
For what I know, DCCP is only supported by the Linux kernel as of today.
There seem to be some DCCP userspace implementations. I have no experience with any of them and so cannot comment on their quality, but they do exist: http://www.cms.livjm.ac.uk/pgnet2008/Proceeedings/Papers/2008057.pdf http://www.phelan-4.com/dccp-tp/tiki-index.php
I think developing the congestion control in the userspace is still a good idea to speed up deployment.
True. But that's completely orthogonal to what protocol we pick. Lars
Dear Lars, my replies are inline. On Tue, Mar 27, 2012 at 3:33 PM, Eggert, Lars <lars@netapp.com> wrote:
On Mar 27, 2012, at 15:15, Luca De Cicco wrote:
For what I know, DCCP is only supported by the Linux kernel as of today.
There seem to be some DCCP userspace implementations. I have no experience with any of them and so cannot comment on their quality, but they do exist:
http://www.cms.livjm.ac.uk/pgnet2008/Proceeedings/Papers/2008057.pdf http://www.phelan-4.com/dccp-tp/tiki-index.php
Yes I'm aware of those implementations (yet I didn't tested any of them), however I thought - maybe wrongly - Wesley was suggesting using a kernel space implementation of DCCP to move, so to speak, the complexity of CC out of webrtc scope.
I think developing the congestion control in the userspace is still a good idea to speed up deployment.
True. But that's completely orthogonal to what protocol we pick.
Yep, that's true, in fact the whole purpose of making congestion control modular in webrtc is to make webrtc oblivious to the congestion control protocol we pick :). Luca
On 3/27/2012 9:44 AM, Luca De Cicco wrote:
Yes I'm aware of those implementations (yet I didn't tested any of them), however I thought - maybe wrongly - Wesley was suggesting using a kernel space implementation of DCCP to move, so to speak, the complexity of CC out of webrtc scope.
I didn't mention a kernel. I was simply mentioning that DCCP already exists and supports modularization and negotiation of the algorithm at run-time. When things are hard, it's best to either not redo them, or have really strong logic motivating it. -- Wes Eddy MTI Systems
Wesley, my bad, I totally agree with you then :). Luca On Tue, Mar 27, 2012 at 3:48 PM, Wesley Eddy <wes@mti-systems.com> wrote:
On 3/27/2012 9:44 AM, Luca De Cicco wrote:
Yes I'm aware of those implementations (yet I didn't tested any of them), however I thought - maybe wrongly - Wesley was suggesting using a kernel space implementation of DCCP to move, so to speak, the complexity of CC out of webrtc scope.
I didn't mention a kernel. I was simply mentioning that DCCP already exists and supports modularization and negotiation of the algorithm at run-time. When things are hard, it's best to either not redo them, or have really strong logic motivating it.
-- Wes Eddy MTI Systems
+1 And note that, if a new congestion control mechanism is specified, it would probably be better to have a generic "home" for it rather than requiring 20 RFCs, each describing how to implement it in this and that protocol... things are just getting rather messy. The problem with DCCP so far might be the lack of an efficient implementation that works over UDP (apologies if there IS such an implementation and I just don't know it). But we do have draft-ietf- dccp-udpencap... Cheers, Michael On Mar 27, 2012, at 3:52 PM, Luca De Cicco wrote:
Wesley, my bad, I totally agree with you then :).
Luca
On Tue, Mar 27, 2012 at 3:48 PM, Wesley Eddy <wes@mti-systems.com> wrote:
On 3/27/2012 9:44 AM, Luca De Cicco wrote:
Yes I'm aware of those implementations (yet I didn't tested any of them), however I thought - maybe wrongly - Wesley was suggesting using a kernel space implementation of DCCP to move, so to speak, the complexity of CC out of webrtc scope.
I didn't mention a kernel. I was simply mentioning that DCCP already exists and supports modularization and negotiation of the algorithm at run-time. When things are hard, it's best to either not redo them, or have really strong logic motivating it.
-- Wes Eddy MTI Systems
Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 27 Mar 2012, at 15:33, Eggert, Lars wrote:
On Mar 27, 2012, at 15:15, Luca De Cicco wrote:
For what I know, DCCP is only supported by the Linux kernel as of today.
There seem to be some DCCP userspace implementations. I have no experience with any of them and so cannot comment on their quality, but they do exist:
http://www.cms.livjm.ac.uk/pgnet2008/Proceeedings/Papers/2008057.pdf http://www.phelan-4.com/dccp-tp/tiki-index.php
I've played with dccp-tp some. It's a reasonable start, but not exactly production quality. -- Colin Perkins http://csperkins.org/
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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Wes Eddy MTI Systems
Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Wes Eddy MTI Systems
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
... 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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Wes Eddy MTI Systems
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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 (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, 2) incorporate that in the SCTP userland implementation, 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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Wes Eddy MTI Systems
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 29 Mar 2012, at 10:31, 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
Yes - I asked the question in the RTCWeb group after bringing it up on this list yesterday.
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 (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, 2) incorporate that in the SCTP userland implementation, 3) use SCTP as the transport for everything??
Sure (which is what I suggested) - since there seems to be limited concern about the fact that SCTP spec actually provides for pluggability, though this will need to specified somewhere..... I think Randell suggested on the Jabber in RTCweb that he'd like to see a delayed based TCP like congestion control for SCTP (e.g. CxTCP) - though it may make more sense to use LEDBAT as cxTCP isn't primarily focused on low delay operation. This is important as delayed based media congestion control is unable to provide for low delay if it is competing directly with normal loss-based TCP. The questions are then about how one puts (S?)RTP into SCTP....
That would then also give a good basis for the group's desired cross-steam-congestion management, I suppose.
Agreed. Piers.
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@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@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@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@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@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion > >
-- Wes Eddy MTI Systems
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On Mar 29, 2012, at 10:50 AM, Piers O'Hanlon wrote:
On 29 Mar 2012, at 10:31, Michael Welzl wrote:
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 (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, 2) incorporate that in the SCTP userland implementation, 3) use SCTP as the transport for everything??
Sure (which is what I suggested) - since there seems to be limited concern about the fact that SCTP spec actually provides for pluggability, though this will need to specified somewhere.....
- sorry for missing that this is what you had meant; agreed, this would have to be specified.
I think Randell suggested on the Jabber in RTCweb that he'd like to see a delayed based TCP like congestion control for SCTP (e.g. CxTCP) - though it may make more sense to use LEDBAT as cxTCP isn't primarily focused on low delay operation.
A LEDBAT-derivative might not fit the RTP requirements, I think. But yes, I wondered if basing a new congestion control mechanism off LEDBAT (e.g., using LEDBAT with the TCP equation as a minimum rate, just like proposed in the "google congestion control algorithm") wouldn't have been a better approach than to design a whole new mechanism. Just not sure if it's doable, as you want to ACK less, and have some logic on the receiver side for that.
This is important as delayed based media congestion control is unable to provide for low delay if it is competing directly with normal loss-based TCP.
The questions are then about how one puts (S?)RTP into SCTP....
Yes, this means an optional different ACKing behavior, with some congestion control logic on the receiver side, but only for the case of (partially) unreliable transfers. We're blowing up SCTP more and more here... still, this strikes me as a less blown up than having SCTP + DCCP, and possibly (note, only possibly) more efficient than having SCTP-for-data + some_new_cc-over-RTP/UDP Cheers, Michael
On 3/29/2012 5:09 AM, Michael Welzl wrote:
On Mar 29, 2012, at 10:50 AM, Piers O'Hanlon wrote:
I think Randell suggested on the Jabber in RTCweb that he'd like to see a delayed based TCP like congestion control for SCTP (e.g. CxTCP) - though it may make more sense to use LEDBAT as cxTCP isn't primarily focused on low delay operation.
A LEDBAT-derivative might not fit the RTP requirements, I think. But yes, I wondered if basing a new congestion control mechanism off LEDBAT (e.g., using LEDBAT with the TCP equation as a minimum rate, just like proposed in the "google congestion control algorithm") wouldn't have been a better approach than to design a whole new mechanism. Just not sure if it's doable, as you want to ACK less, and have some logic on the receiver side for that.
One thing I've realized, as we're now talking about this as well as other algorithms together - we need a name for what's covered in Harald's draft. Harald; Stefan? I'll refer to my similar extant algorithm (never published, more heuristic than Googles but very similar in approach) as the OJO algorithm if I mention it in posts here.
This is important as delayed based media congestion control is unable to provide for low delay if it is competing directly with normal loss-based TCP.
The questions are then about how one puts (S?)RTP into SCTP....
Yes, this means an optional different ACKing behavior, with some congestion control logic on the receiver side, but only for the case of (partially) unreliable transfers. We're blowing up SCTP more and more here... still, this strikes me as a less blown up than having SCTP + DCCP, and possibly (note, only possibly) more efficient than having SCTP-for-data + some_new_cc-over-RTP/UDP
It is an interesting idea which had not really been considered before, and would obviously solve the congestion issue between rtcweb data channels and media channels. There is an efficiency argument about RTP/SCTP/DTLS/(ICE)UDP compared to plain SRTP/UDP (keyed with DTLS-SRTP or SDES, a whole other religious war over in rtcweb). It's not a huge impact on video, especially at higher bandwidths, but could be significant for audio-only calls. In addition, some currently non-critical issues with SCTP would become more critical, such as an issue flagged about large reliable datagrams hogging the packet queues; and there might also be startup speed issues. It would be a pretty major change at this point, I should note, but not (quite) impossible. -- Randell Jesup randell-ietf@jesup.org
Randell Jesup wrote:
It is an interesting idea which had not really been considered before, and would obviously solve the congestion issue between rtcweb data channels and media channels.
Keep in mind that one of the arguments against the shim approach to multiple RTP sessions on a single port was that it would break all existing traffic management software at gateways, firewalls, etc., that tries to inspect RTP/SRTP packets. The same would be true of RTP/SCTP/DTLS/UDP, except moreso (as you would no longer even be able to get at the fields that are normally unencrypted in an SRTP session, regardless of your ability to upgrade software on the gateways and firewalls). To me this is at least as big a disadvantage as the efficiency argument, though adding that many more bytes of overhead to on the order of 100 packets a second is already a pretty big disadvantage.
Hi, I changed the subject as we're really talking about SCTP, not DCCP here now. More below: [snip]
Yes, this means an optional different ACKing behavior, with some congestion control logic on the receiver side, but only for the case of (partially) unreliable transfers. We're blowing up SCTP more and more here... still, this strikes me as a less blown up than having SCTP + DCCP, and possibly (note, only possibly) more efficient than having SCTP-for-data + some_new_cc-over-RTP/UDP
Note that the above paragraph by me captures a view that has meanwhile evolved: I now think that there should probably be only one single congestion control instance for everything (and then it wouldn't matter much whether it's on the sender or receiver side). With that in mind, I'll answer below:
It is an interesting idea which had not really been considered before, and would obviously solve the congestion issue between rtcweb data channels and media channels.
There is an efficiency argument about RTP/SCTP/DTLS/(ICE)UDP compared to plain SRTP/UDP (keyed with DTLS-SRTP or SDES, a whole other religious war over in rtcweb). It's not a huge impact on video, especially at higher bandwidths, but could be significant for audio-only calls.
In addition, some currently non-critical issues with SCTP would become more critical, such as an issue flagged about large reliable datagrams hogging the packet queues; and there might also be startup speed issues.
I don't see why (a potentially adapted) SCTP couldn't be made to always fragment packets beyond a certain size to avoid that hogging problem. And I don't understand how that would become more critical? As for startup speed, I think that this is not true (au contraire! no need for slow starting into a network that's already used by another stream) if we have only one congestion control instance. On Apr 8, 2012, at 9:26 AM, Timothy B. Terriberry wrote:
Keep in mind that one of the arguments against the shim approach to multiple RTP sessions on a single port was that it would break all existing traffic management software at gateways, firewalls, etc., that tries to inspect RTP/SRTP packets. The same would be true of RTP/SCTP/DTLS/UDP, except moreso (as you would no longer even be able to get at the fields that are normally unencrypted in an SRTP session, regardless of your ability to upgrade software on the gateways and firewalls).
To me this is at least as big a disadvantage as the efficiency argument, though adding that many more bytes of overhead to on the order of 100 packets a second is already a pretty big disadvantage.
I don't know much about and have no strong opinion about that first argument, but regarding the overhead, note that there is significant overhead in the other variant too: you have SCTP data traffic causing receiver-side ACKs that convey pretty much the same information as RTCP feedback, but both streams mutually ignore each other... Cheers, Michael
On Sun, Apr 8, 2012 at 7:51 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,
I changed the subject as we're really talking about SCTP, not DCCP here now. More below:
[snip]
Yes, this means an optional different ACKing behavior, with some
congestion control logic on the receiver side, but only for the case of (partially) unreliable transfers. We're blowing up SCTP more and more here... still, this strikes me as a less blown up than having SCTP + DCCP, and possibly (note, only possibly) more efficient than having SCTP-for-data + some_new_cc-over-RTP/UDP
Note that the above paragraph by me captures a view that has meanwhile evolved: I now think that there should probably be only one single congestion control instance for everything (and then it wouldn't matter much whether it's on the sender or receiver side). With that in mind, I'll answer below:
It is an interesting idea which had not really been considered before,
and would obviously solve the congestion issue between rtcweb data channels and media channels.
There is an efficiency argument about RTP/SCTP/DTLS/(ICE)UDP compared to plain SRTP/UDP (keyed with DTLS-SRTP or SDES, a whole other religious war over in rtcweb). It's not a huge impact on video, especially at higher bandwidths, but could be significant for audio-only calls.
In addition, some currently non-critical issues with SCTP would become more critical, such as an issue flagged about large reliable datagrams hogging the packet queues; and there might also be startup speed issues.
I don't see why (a potentially adapted) SCTP couldn't be made to always fragment packets beyond a certain size to avoid that hogging problem. And I don't understand how that would become more critical? As for startup speed, I think that this is not true (au contraire! no need for slow starting into a network that's already used by another stream) if we have only one congestion control instance.
On Apr 8, 2012, at 9:26 AM, Timothy B. Terriberry wrote:
Keep in mind that one of the arguments against the shim approach to
multiple RTP sessions on a single port was that it would break all existing traffic management software at gateways, firewalls, etc., that tries to inspect RTP/SRTP packets. The same would be true of RTP/SCTP/DTLS/UDP, except moreso (as you would no longer even be able to get at the fields that are normally unencrypted in an SRTP session, regardless of your ability to upgrade software on the gateways and firewalls).
To me this is at least as big a disadvantage as the efficiency argument, though adding that many more bytes of overhead to on the order of 100 packets a second is already a pretty big disadvantage.
I don't know much about and have no strong opinion about that first argument, but regarding the overhead, note that there is significant overhead in the other variant too: you have SCTP data traffic causing receiver-side ACKs that convey pretty much the same information as RTCP feedback, but both streams mutually ignore each other...
Not sure which thread these comments fit in, so I chose this one. It may be worth noting that: a. Delayed ACKs will make a send-side algorithm slower at reacting to increased delay upon congestion. This may be possible to get around by having some mechanism at the receive-side as well for detecting congestion and thereby force the ACK to be sent. b. Lost ACKs may introduce uncertainty for the send-side algorithm, which will never be a problem for a recieve-side algorithm. You can reduce the uncertainty by having something like an ACK sequence number in each ACK message, but you have still lost the delay information contained in the lost ACK. Maybe something like this already exists in SCTP?
Cheers, Michael
______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
On Tue, Apr 10, 2012 at 1:43 PM, Stefan Holmer <stefan@webrtc.org> wrote:
On Sun, Apr 8, 2012 at 7:51 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,
I changed the subject as we're really talking about SCTP, not DCCP here now. More below:
[snip]
Yes, this means an optional different ACKing behavior, with some
congestion control logic on the receiver side, but only for the case of (partially) unreliable transfers. We're blowing up SCTP more and more here... still, this strikes me as a less blown up than having SCTP + DCCP, and possibly (note, only possibly) more efficient than having SCTP-for-data + some_new_cc-over-RTP/UDP
Note that the above paragraph by me captures a view that has meanwhile evolved: I now think that there should probably be only one single congestion control instance for everything (and then it wouldn't matter much whether it's on the sender or receiver side). With that in mind, I'll answer below:
It is an interesting idea which had not really been considered before,
and would obviously solve the congestion issue between rtcweb data channels and media channels.
There is an efficiency argument about RTP/SCTP/DTLS/(ICE)UDP compared to plain SRTP/UDP (keyed with DTLS-SRTP or SDES, a whole other religious war over in rtcweb). It's not a huge impact on video, especially at higher bandwidths, but could be significant for audio-only calls.
In addition, some currently non-critical issues with SCTP would become more critical, such as an issue flagged about large reliable datagrams hogging the packet queues; and there might also be startup speed issues.
I don't see why (a potentially adapted) SCTP couldn't be made to always fragment packets beyond a certain size to avoid that hogging problem. And I don't understand how that would become more critical? As for startup speed, I think that this is not true (au contraire! no need for slow starting into a network that's already used by another stream) if we have only one congestion control instance.
On Apr 8, 2012, at 9:26 AM, Timothy B. Terriberry wrote:
Keep in mind that one of the arguments against the shim approach to
multiple RTP sessions on a single port was that it would break all existing traffic management software at gateways, firewalls, etc., that tries to inspect RTP/SRTP packets. The same would be true of RTP/SCTP/DTLS/UDP, except moreso (as you would no longer even be able to get at the fields that are normally unencrypted in an SRTP session, regardless of your ability to upgrade software on the gateways and firewalls).
To me this is at least as big a disadvantage as the efficiency argument, though adding that many more bytes of overhead to on the order of 100 packets a second is already a pretty big disadvantage.
I don't know much about and have no strong opinion about that first argument, but regarding the overhead, note that there is significant overhead in the other variant too: you have SCTP data traffic causing receiver-side ACKs that convey pretty much the same information as RTCP feedback, but both streams mutually ignore each other...
Not sure which thread these comments fit in, so I chose this one. It may be worth noting that:
a. Delayed ACKs will make a send-side algorithm slower at reacting to increased delay upon congestion. This may be possible to get around by having some mechanism at the receive-side as well for detecting congestion and thereby force the ACK to be sent.
b. Lost ACKs may introduce uncertainty for the send-side algorithm, which will never be a problem for a recieve-side algorithm. You can reduce the uncertainty by having something like an ACK sequence number in each ACK message, but you have still lost the delay information contained in the lost ACK. Maybe something like this already exists in
Also, how much extra overhead are we talking about when ACKing every packet compared to having periodic REMB packets? I think there are a lot of use-cases which won't have any significant amount of RTCWEB data streams, and in those situations we only get the extra overhead from ACKing every packet, as there are no significant data streams to share ACKs with.
Cheers, Michael
______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
On Apr 10, 2012, at 1:43 PM, Stefan Holmer wrote:
On Sun, Apr 8, 2012 at 7:51 PM, Michael Welzl <michawe@ifi.uio.no> wrote: Hi,
I changed the subject as we're really talking about SCTP, not DCCP here now. More below:
[snip]
Yes, this means an optional different ACKing behavior, with some congestion control logic on the receiver side, but only for the case of (partially) unreliable transfers. We're blowing up SCTP more and more here... still, this strikes me as a less blown up than having SCTP + DCCP, and possibly (note, only possibly) more efficient than having SCTP-for-data + some_new_cc-over-RTP/UDP
Note that the above paragraph by me captures a view that has meanwhile evolved: I now think that there should probably be only one single congestion control instance for everything (and then it wouldn't matter much whether it's on the sender or receiver side). With that in mind, I'll answer below:
It is an interesting idea which had not really been considered before, and would obviously solve the congestion issue between rtcweb data channels and media channels.
There is an efficiency argument about RTP/SCTP/DTLS/(ICE)UDP compared to plain SRTP/UDP (keyed with DTLS-SRTP or SDES, a whole other religious war over in rtcweb). It's not a huge impact on video, especially at higher bandwidths, but could be significant for audio-only calls.
In addition, some currently non-critical issues with SCTP would become more critical, such as an issue flagged about large reliable datagrams hogging the packet queues; and there might also be startup speed issues.
I don't see why (a potentially adapted) SCTP couldn't be made to always fragment packets beyond a certain size to avoid that hogging problem. And I don't understand how that would become more critical? As for startup speed, I think that this is not true (au contraire! no need for slow starting into a network that's already used by another stream) if we have only one congestion control instance.
On Apr 8, 2012, at 9:26 AM, Timothy B. Terriberry wrote:
Keep in mind that one of the arguments against the shim approach to multiple RTP sessions on a single port was that it would break all existing traffic management software at gateways, firewalls, etc., that tries to inspect RTP/SRTP packets. The same would be true of RTP/SCTP/DTLS/UDP, except moreso (as you would no longer even be able to get at the fields that are normally unencrypted in an SRTP session, regardless of your ability to upgrade software on the gateways and firewalls).
To me this is at least as big a disadvantage as the efficiency argument, though adding that many more bytes of overhead to on the order of 100 packets a second is already a pretty big disadvantage.
I don't know much about and have no strong opinion about that first argument, but regarding the overhead, note that there is significant overhead in the other variant too: you have SCTP data traffic causing receiver-side ACKs that convey pretty much the same information as RTCP feedback, but both streams mutually ignore each other...
Not sure which thread these comments fit in, so I chose this one. It may be worth noting that:
a. Delayed ACKs will make a send-side algorithm slower at reacting to increased delay upon congestion. This may be possible to get around by having some mechanism at the receive-side as well for detecting congestion and thereby force the ACK to be sent.
The is an extension (implemented in Linux and FreeBSD), described in http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-sack-immediately-08 which allows the sender to request a SACK not being delayed. Best regards Michael
b. Lost ACKs may introduce uncertainty for the send-side algorithm, which will never be a problem for a recieve-side algorithm. You can reduce the uncertainty by having something like an ACK sequence number in each ACK message, but you have still lost the delay information contained in the lost ACK. Maybe something like this already exists in SCTP?
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On Tue, Apr 10, 2012 at 2:28 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote:
On Apr 10, 2012, at 1:43 PM, Stefan Holmer wrote:
On Sun, Apr 8, 2012 at 7:51 PM, Michael Welzl <michawe@ifi.uio.no>
wrote:
Hi,
I changed the subject as we're really talking about SCTP, not DCCP here now. More below:
[snip]
Yes, this means an optional different ACKing behavior, with some congestion control logic on the receiver side, but only for the case of (partially) unreliable transfers. We're blowing up SCTP more and more here... still, this strikes me as a less blown up than having SCTP + DCCP, and possibly (note, only possibly) more efficient than having SCTP-for-data + some_new_cc-over-RTP/UDP
Note that the above paragraph by me captures a view that has meanwhile evolved: I now think that there should probably be only one single congestion control instance for everything (and then it wouldn't matter much whether it's on the sender or receiver side). With that in mind, I'll answer below:
It is an interesting idea which had not really been considered before, and would obviously solve the congestion issue between rtcweb data channels and media channels.
There is an efficiency argument about RTP/SCTP/DTLS/(ICE)UDP compared to plain SRTP/UDP (keyed with DTLS-SRTP or SDES, a whole other religious war over in rtcweb). It's not a huge impact on video, especially at higher bandwidths, but could be significant for audio-only calls.
In addition, some currently non-critical issues with SCTP would become more critical, such as an issue flagged about large reliable datagrams hogging the packet queues; and there might also be startup speed issues.
I don't see why (a potentially adapted) SCTP couldn't be made to always fragment packets beyond a certain size to avoid that hogging problem. And I don't understand how that would become more critical? As for startup speed, I think that this is not true (au contraire! no need for slow starting into a network that's already used by another stream) if we have only one congestion control instance.
On Apr 8, 2012, at 9:26 AM, Timothy B. Terriberry wrote:
Keep in mind that one of the arguments against the shim approach to multiple RTP sessions on a single port was that it would break all existing traffic management software at gateways, firewalls, etc., that tries to inspect RTP/SRTP packets. The same would be true of RTP/SCTP/DTLS/UDP, except moreso (as you would no longer even be able to get at the fields that are normally unencrypted in an SRTP session, regardless of your ability to upgrade software on the gateways and firewalls).
To me this is at least as big a disadvantage as the efficiency argument, though adding that many more bytes of overhead to on the order of 100 packets a second is already a pretty big disadvantage.
I don't know much about and have no strong opinion about that first argument, but regarding the overhead, note that there is significant overhead in the other variant too: you have SCTP data traffic causing receiver-side ACKs that convey pretty much the same information as RTCP feedback, but both streams mutually ignore each other...
Not sure which thread these comments fit in, so I chose this one. It may be worth noting that:
a. Delayed ACKs will make a send-side algorithm slower at reacting to increased delay upon congestion. This may be possible to get around by having some mechanism at the receive-side as well for detecting congestion and thereby force the ACK to be sent. The is an extension (implemented in Linux and FreeBSD), described in http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-sack-immediately-08 which allows the sender to request a SACK not being delayed.
Best regards Michael
Right, and by doing so you get more frequent ACKs and more overhead. I wanted to make it clear that there's a trade-off between the amount of overhead and the reaction time here.
b. Lost ACKs may introduce uncertainty for the send-side algorithm,
which will never be a problem for a recieve-side algorithm. You can reduce the uncertainty by having something like an ACK sequence number in each ACK message, but you have still lost the delay information contained in the lost ACK. Maybe something like this already exists in SCTP?
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 4/8/2012 1:51 PM, Michael Welzl wrote:
It is an interesting idea which had not really been considered before, and would obviously solve the congestion issue between rtcweb data channels and media channels.
There is an efficiency argument about RTP/SCTP/DTLS/(ICE)UDP compared to plain SRTP/UDP (keyed with DTLS-SRTP or SDES, a whole other religious war over in rtcweb). It's not a huge impact on video, especially at higher bandwidths, but could be significant for audio-only calls.
In addition, some currently non-critical issues with SCTP would become more critical, such as an issue flagged about large reliable datagrams hogging the packet queues; and there might also be startup speed issues.
I don't see why (a potentially adapted) SCTP couldn't be made to always fragment packets beyond a certain size to avoid that hogging problem. And I don't understand how that would become more critical?
There's already an issue with large datagrams (which are already fragmented by SCTP) monopolizing the stack queues in certain cases. However, currently this only affects other data streams and not media (which is very sensitive to even temporary blocking).
As for startup speed, I think that this is not true (au contraire! no need for slow starting into a network that's already used by another stream) if we have only one congestion control instance.
I was referring to call startup speed. Right now we don't need to start SCTP to start media.
On Apr 8, 2012, at 9:26 AM, Timothy B. Terriberry wrote:
Keep in mind that one of the arguments against the shim approach to multiple RTP sessions on a single port was that it would break all existing traffic management software at gateways, firewalls, etc., that tries to inspect RTP/SRTP packets. The same would be true of RTP/SCTP/DTLS/UDP, except moreso (as you would no longer even be able to get at the fields that are normally unencrypted in an SRTP session, regardless of your ability to upgrade software on the gateways and firewalls).
To me this is at least as big a disadvantage as the efficiency argument, though adding that many more bytes of overhead to on the order of 100 packets a second is already a pretty big disadvantage.
I don't know much about and have no strong opinion about that first argument, but regarding the overhead, note that there is significant overhead in the other variant too: you have SCTP data traffic causing receiver-side ACKs that convey pretty much the same information as RTCP feedback, but both streams mutually ignore each other...
Don't assume that there's lots of data traffic - often (usually) there will be little or no data traffic, so imposing overhead on every media packet is a significant hit, especially in a low-bandwidth situation. SRTP over UDP is already ~44-50 bytes (IPv4, depending on hash tag length - RTP over UDP is 40); RTP over SCTP over DTLS over UDP is ... a bunch; I don't have time to calculate it right now. And for a low-bandwidth audio-only call the payload could be little as 10 or 15Kbps over 50 packets/sec. -- Randell Jesup randell-ietf@jesup.org
On Mar 29, 2012, at 10:50 AM, Piers O'Hanlon wrote:
On 29 Mar 2012, at 10:31, 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
Yes - I asked the question in the RTCWeb group after bringing it up on this list yesterday.
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 (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, 2) incorporate that in the SCTP userland implementation, 3) use SCTP as the transport for everything??
Sure (which is what I suggested) - since there seems to be limited concern about the fact that SCTP spec actually provides for pluggability, though this will need to specified somewhere.....
I think Randell suggested on the Jabber in RTCweb that he'd like to see a delayed based TCP like congestion control for SCTP (e.g. CxTCP) - though it may make more sense to use LEDBAT as cxTCP isn't primarily focused on low delay operation.
Implementing LEBAT should be pretty simple (something on my ToDo list, however there are others with higher priority)
This is important as delayed based media congestion control is unable to provide for low delay if it is competing directly with normal loss-based TCP.
The questions are then about how one puts (S?)RTP into SCTP....
That would then also give a good basis for the group's desired cross-steam-congestion management, I suppose.
Agreed.
Piers.
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@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@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@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@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@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/rtp-congestion >> >> > > -- > Wes Eddy > MTI Systems
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@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@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@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@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@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion > >
-- Wes Eddy MTI Systems
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On Mar 28, 2012, at 9:56, Piers O'Hanlon wrote:
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.
I think that the SCTP BSD *implementation* has pluggable congestion control (because Lawrence Stewart added that for TCP and SCTP benefits as a side effect.) I don't think the SCTP *spec* has support for pluggable congestion control. AFAIK only the DCCP spec has pluggable congestion control. (And note that I personally have no strong feelings about SCTP vs. DCCP for rtcweb. I just want to make sure that we have all the facts when we decide.) Lars
On 28 Mar 2012, at 10:33, Eggert, Lars wrote:
On Mar 28, 2012, at 9:56, Piers O'Hanlon wrote:
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.
I think that the SCTP BSD *implementation* has pluggable congestion control (because Lawrence Stewart added that for TCP and SCTP benefits as a side effect.) I don't think the SCTP *spec* has support for pluggable congestion control. AFAIK only the DCCP spec has pluggable congestion control.
(And note that I personally have no strong feelings about SCTP vs. DCCP for rtcweb. I just want to make sure that we have all the facts when we decide.)
Ok - I wasn't quite clear on SCTP's support for pluggable CC - but having looked at the SCTP RFC I can see it is not part of the spec. I had wondered about the multipath-SCTP providing support but that doesn't either. Having seen pluggable CC for SCTP implementations for BSD, LInux, and Solaris, it seemed it wasn't too hard - and may have some of the benefits I mentioned, but since it would need additional specification then one could use something else... Piers.
Lars
On Mar 28, 2012, at 11:33 AM, Piers O'Hanlon wrote:
On 28 Mar 2012, at 10:33, Eggert, Lars wrote:
On Mar 28, 2012, at 9:56, Piers O'Hanlon wrote:
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.
I think that the SCTP BSD *implementation* has pluggable congestion control (because Lawrence Stewart added that for TCP and SCTP benefits as a side effect.) I don't think the SCTP *spec* has support for pluggable congestion control. AFAIK only the DCCP spec has pluggable congestion control.
(And note that I personally have no strong feelings about SCTP vs. DCCP for rtcweb. I just want to make sure that we have all the facts when we decide.)
Ok - I wasn't quite clear on SCTP's support for pluggable CC - but having looked at the SCTP RFC I can see it is not part of the spec. I had wondered about the multipath-SCTP providing support but that doesn't either. Having seen pluggable CC for SCTP implementations for BSD, LInux, and Solaris, it seemed it wasn't too hard - and may have some of the benefits I mentioned, but since it would need additional specification then one could use something else...
Just as a datapoint, working pluggable CC for Linux SCTP (in the kernel) doesn't seem to exist, I think, or at least it didn't one year ago when we made it but never really finished... see my related message to TSVWG yesterday: http://www.ietf.org/mail-archive/web/tsvwg/current/msg11212.html I also have no strong personal feelings on DCCP vs. SCTP and see your point about the benefits. Then again, DCCP was brought up in this discussion because it can negotiate congestion controls, and that functionality isn't there in SCTP, because pluggable CC. in SCTP isn't a part of the standard, as Lars said. Cheers, Michael
On 28 Mar 2012, at 11:42, Michael Welzl wrote:
On Mar 28, 2012, at 11:33 AM, Piers O'Hanlon wrote:
On 28 Mar 2012, at 10:33, Eggert, Lars wrote:
On Mar 28, 2012, at 9:56, Piers O'Hanlon wrote:
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.
I think that the SCTP BSD *implementation* has pluggable congestion control (because Lawrence Stewart added that for TCP and SCTP benefits as a side effect.) I don't think the SCTP *spec* has support for pluggable congestion control. AFAIK only the DCCP spec has pluggable congestion control.
(And note that I personally have no strong feelings about SCTP vs. DCCP for rtcweb. I just want to make sure that we have all the facts when we decide.)
Ok - I wasn't quite clear on SCTP's support for pluggable CC - but having looked at the SCTP RFC I can see it is not part of the spec. I had wondered about the multipath-SCTP providing support but that doesn't either. Having seen pluggable CC for SCTP implementations for BSD, LInux, and Solaris, it seemed it wasn't too hard - and may have some of the benefits I mentioned, but since it would need additional specification then one could use something else...
Just as a datapoint, working pluggable CC for Linux SCTP (in the kernel) doesn't seem to exist, I think, or at least it didn't one year ago when we made it but never really finished... see my related message to TSVWG yesterday: http://www.ietf.org/mail-archive/web/tsvwg/current/msg11212.html
Yes I'd seen your one - It was interesting - I wasn't implying that they were 'finished' and had made it into the main kernel. Though the userland SCTP stack from sctp.fh-muenster.de runs on Linux, BSD. OSX and Windows and it seems to have APIs in place for pluggable congestion control (though it seems to be limited in alternative algorithms for now). Since the RTCWeb folks are keen on userland approaches then this is more promising. Piers
I also have no strong personal feelings on DCCP vs. SCTP and see your point about the benefits. Then again, DCCP was brought up in this discussion because it can negotiate congestion controls, and that functionality isn't there in SCTP, because pluggable CC. in SCTP isn't a part of the standard, as Lars said.
Cheers, Michael
It's not clear to me how this discussion is developing: is there any consensus about making congestion control modular in webRTC (which was the original discussion here)? I'm asking this because the discussion rapidly changed topic from "should we make congestion control pluggable?" to "is DCCP a good candidate?" to "what congestion control should we use?" and I just feel kinda lost in these parallel discussions. Thanks, Luca On Wed, Mar 28, 2012 at 2:13 PM, Piers O'Hanlon <p.ohanlon@gmail.com> wrote:
On 28 Mar 2012, at 11:42, Michael Welzl wrote:
On Mar 28, 2012, at 11:33 AM, Piers O'Hanlon wrote:
On 28 Mar 2012, at 10:33, Eggert, Lars wrote:
On Mar 28, 2012, at 9:56, Piers O'Hanlon wrote:
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.
I think that the SCTP BSD *implementation* has pluggable congestion control (because Lawrence Stewart added that for TCP and SCTP benefits as a side effect.) I don't think the SCTP *spec* has support for pluggable congestion control. AFAIK only the DCCP spec has pluggable congestion control.
(And note that I personally have no strong feelings about SCTP vs. DCCP for rtcweb. I just want to make sure that we have all the facts when we decide.)
Ok - I wasn't quite clear on SCTP's support for pluggable CC - but having looked at the SCTP RFC I can see it is not part of the spec. I had wondered about the multipath-SCTP providing support but that doesn't either. Having seen pluggable CC for SCTP implementations for BSD, LInux, and Solaris, it seemed it wasn't too hard - and may have some of the benefits I mentioned, but since it would need additional specification then one could use something else...
Just as a datapoint, working pluggable CC for Linux SCTP (in the kernel) doesn't seem to exist, I think, or at least it didn't one year ago when we made it but never really finished... see my related message to TSVWG yesterday: http://www.ietf.org/mail-archive/web/tsvwg/current/msg11212.html
Yes I'd seen your one - It was interesting - I wasn't implying that they were 'finished' and had made it into the main kernel.
Though the userland SCTP stack from sctp.fh-muenster.de runs on Linux, BSD. OSX and Windows and it seems to have APIs in place for pluggable congestion control (though it seems to be limited in alternative algorithms for now). Since the RTCWeb folks are keen on userland approaches then this is more promising.
Piers
I also have no strong personal feelings on DCCP vs. SCTP and see your point about the benefits. Then again, DCCP was brought up in this discussion because it can negotiate congestion controls, and that functionality isn't there in SCTP, because pluggable CC. in SCTP isn't a part of the standard, as Lars said.
Cheers, Michael
On Apr 6, 2012, at 12:05 AM, Luca De Cicco wrote:
It's not clear to me how this discussion is developing: is there any consensus about making congestion control modular in webRTC (which was the original discussion here)?
True, we lost that thread; I guess that's mostly my fault - sorry! My vote is: yes, it should be modular. For how to signal that, see below for one thought:
I'm asking this because the discussion rapidly changed topic from "should we make congestion control pluggable?" to "is DCCP a good candidate?" to "what congestion control should we use?" and I just feel kinda lost in these parallel discussions.
DCCP would have been an obvious candidate for its signaling capabilities, but I don't have the impression that DCCP is a favorable choice. DCCP-like protocol negotiation could be done using other protocols. So I think what form the signaling should take, if we end up with modular congestion control at all, is open. Cheers, Michael
participants (13)
-
Colin Perkins -
Eggert, Lars -
Harald Alvestrand -
Justin Uberti -
Luca De Cicco -
Michael Tuexen -
Michael Tuexen -
Michael Welzl -
Piers O'Hanlon -
Randell Jesup -
Stefan Holmer -
Timothy B. Terriberry -
Wesley Eddy