[R-C] BoF approved

[Mo Zanaty (mzanaty)]

This happens all the time today. All widely deployed video communication products/services have some form of adaptive rate behavior, usually employing a combination of standard and proprietary feedback. When you mix vendors, only the standard feedback works. But the response to standard feedback is not standardized, so you get different behavior/rates on each side. RMCAT should avoid this chaos by specifying behavior in the absence of some or all of the newly standardized feedback, which will look just like unknown proprietary feedback to the non-RMCAT side.

We should first focus on getting the right standard in place for RMCAT on both sides. But then we should also specify interop behavior with non-RMCAT peers. 

Mo

-----Original Message-----
From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Michael Welzl
Sent: Sunday, July 22, 2012 9:01 AM
To: Randell Jesup
Cc: rtp-congestion at alvestrand.no
Subject: Re: [R-C] BoF approved

 On Sun, 22 Jul 2012 08:40:32 -0400, Randell Jesup 
 <randell-ietf at jesup.org> wrote:
> On 7/21/2012 4:46 PM, Mo Zanaty (mzanaty) wrote:
>> Michael Welzl <michawe at 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