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