+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