Re: [R-C] Congestion control requirements - I-D format, -01a version
On 03/05/2012 03:32 PM, Bill Ver Steeg (versteb) wrote:
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. To be clear: I am not at all objecting to work on RTP multicast.
What I'm saying is that *for the RTCWEB scenario*, RTP multicast is irrelevant. Given that RTCWEB is expecting to deploy on a very fast schedule, delaying work that RTCWEB may depend on in order to address the multicast scenarios is not a good option. In other words: I would like multicast to remain out of scope *for this requirement set*.
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
Harald- That seems reasonable. If this is the path we take, we need to be sure to state this clearly in the documents and be rigorous. In some of the previous documents, the primary focus was on unicast and there was some secondary discussion on multicast. As we all know, high-concurrency multicast flows present a unique set of problems and they need to be thought out in detail. IMHO, the multicast portions of the older documents came up with suboptimal design points around detection of ECN-compliant receivers and middleboxes. The described algorithms would lead to unwarranted duplication of streams in the high-fan-out (aka IPTV) deployment models. If we want to move the unicast design quickly, it would be better to carve out the multicast work and do it later. This is a bit perilous, but I understand the motivations for doing so. So, in summary, I am OK with confining the RTCWEB work to unicast as long as we label it as such and plan to go back and look at the multicast variants. bvs -----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, March 05, 2012 9:36 AM To: Bill Ver Steeg (versteb) Cc: Fred Baker (fred); Randell Jesup; Ali C. Begen (abegen); rtp-congestion@alvestrand.no Subject: Re: [R-C] Congestion control requirements - I-D format, -01a version On 03/05/2012 03:32 PM, Bill Ver Steeg (versteb) wrote:
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. To be clear: I am not at all objecting to work on RTP multicast.
What I'm saying is that *for the RTCWEB scenario*, RTP multicast is irrelevant. Given that RTCWEB is expecting to deploy on a very fast schedule, delaying work that RTCWEB may depend on in order to address the multicast scenarios is not a good option. In other words: I would like multicast to remain out of scope *for this requirement set*.
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
participants (2)
-
Bill Ver Steeg (versteb) -
Harald Alvestrand