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

[Bill Ver Steeg (versteb)]

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