On Sun, 22 Jul 2012 08:40:32 -0400, Randell Jesup <randell-ietf@jesup.org> wrote:
On 7/21/2012 4:46 PM, Mo Zanaty (mzanaty) wrote:
Michael Welzl <michawe@ifi.uio.no> wrote:
Just to be clear, what is the scenario you're envisioning? An application where one side does new-rmcat-congestion-control and the other side doesn't, and the new side has to make the most out of the feedback that it gets from the other? Right.
Since RTP flows are typically negotiated, it may be reasonable to assume that the rmcat-capable side knows it's talking to a non-rmcat-capable source (or even without negotiation, that it will know quickly). Or the behavior could be turned on by the first exchange of RTCP feedback messages specific to rmcat - there are a number of options.
So I'm trying to understand how one could recommend a specific behavior for such a case. We are facing a situation where we may not get enough feedback. Say, we get way too little feedback: the IETF-conformant (TCP-friendly) thing to do, then, is to assume loss and react by at least halving the send rate. This may not be attractive for the application at all, depending very much on the content and on the likelihood that missing feedback is due to the other side sending little vs. loss from the network. All in all, I'm having trouble imagining that some reasonable general behavior can be recommended for this case. Cheers, Michael