We do need to get some clarity on the scope of this work. When I reviewed some of the earlier RTP/RTCP/ECN congestion work, I had some concerns about its applicability to high-fan-out deployment models. If we can find mechanisms that satisfy both the unicast and multicast use cases, that would be great. If we are explicitly excluding multicast from this design, we need to be very clear in the document. IMHO, the RTP multicast case is very important and should be in scope. There are some techniques that can be used to aggregate and/or suppress RTCP feedback implosions, and we can map these techniques onto ECN. These mechanisms are in common use for error recovery in IPTV deployments, so there is some precedent for their use. bvs -----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: Sunday, March 04, 2012 5:49 AM To: Fred Baker (fred) Cc: Randell Jesup; Ali C. Begen (abegen); rtp-congestion@alvestrand.no Subject: Re: [R-C] Congestion control requirements - I-D format, -01a version On 03/04/2012 11:42 AM, Fred Baker wrote:
You realize that this mechanism, whatever it turns out to be, has one of the problems of reliable multicast; if the RTP service is one to many, the RTCP service is many to one, and that can be a lot for the one. You find yourself wanting to find some way to collude with it.
If for example it is built on conex, it will collect CE flags in the outbound path, and you will want some way of reporting the fact back. Imagine it's 1:1000000, CE gets set on the first hop out, and a million receivers decide to reply... Yep, I regard the multicast case as a distraction for RTCWEB, however, since it seems that trying to solve both multicast and unicast at the same time usually results in either no solution or no deployment.
Another thing to make clear in the introduction - that this is solving for the unicast case.... _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion