[R-C] Congestion control requirements - I-D format, -01a version

[Harald Alvestrand]

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 at alvestrand.no
> [mailto:rtp-congestion-bounces at 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 at 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 at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>