[R-C] BoF approved

[Michael Welzl]

 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