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

[Bill Ver Steeg (versteb)]

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 at 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 at 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 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
>