[R-C] BoF approved

[Randell Jesup]

On 7/22/2012 10:14 PM, Mo Zanaty (mzanaty) wrote:
> 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.

I agree - though in that case it's hard to specify every possibility, 
since the other side is effectively uncontrolled, but some specific 
rules/SHOULDs and guidance would be good.

> -----Original Message-----
> From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Michael Welzl
>
> >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.

Per above, this is the current interop case - and I suspect strongly 
that few if any RTP applications follow the TCP-friendly rule of halving 
sending rate if they don't get any feedback for an RTT.  (I suspect few 
halve their sending rate if they don't get any feedback for 5+ seconds, 
for that matter.)  The only feedback they can assume they will 
*probably* get in an interop case is AVP RCTP at ~5 second intervals - 
if it doesn't get lost.  Anything better in that situation is a bonus.

-- 
Randell Jesup
randell-ietf at jesup.org