[R-C] Feedback mechanisms

[Randell Jesup]

On 8/9/2012 8:38 AM, Piers O'Hanlon wrote:
> Hi,
>
> On 9 Aug 2012, at 08:43, Michael Welzl wrote:
>
>> Hi,
>>
>> Nice summary indeed! Very interesting for a RTP-newbie like me...
>>
>> A few observations:
>>
>> - I think (not sure though, maybe it was *only* Randell  :-)   well, I like it too! ) that I heard several people talk about the idea of piggybacking ACKs on RTP payload whenever that's possible. That just seems to be a good idea.
>>
> Yes - from my brief analysis of Facetime it would appear that is how they are signalling congestion as there's not much sign of RTCP packets that I can see....

I had a hack in our videophone to use header extensions as an alternate 
channel for RTCP due to a Canadian ISP/telecom not forwarding RTCP 
packets. (Grrrr).   Facetime may be doing it as combo cheap rtcp-mux and 
to reduce bandwidth/packet rate, and maybe to avoid differential 
handling by mobile carriers.

> When using RTP header based feedback one could envisage a case where video may be unidirectional but audio is maintained thus keeping a two way feedback channel open.

Yes, and audio typically runs a shorter frame rate.

>> - I think that the RTCP feedback limitation rules grew out of thinking of multicast, which we decided to avoid here. Given the fact that we're dealing with congestion information and want to react to growing queues as fast as we can, I really don't think that we should be limited in that way for simple, short packets (which *might* translate into: RTCP is not the right tool for this. Don't know...). Just as a thought model, I think it's perfectly "legal" to run RTP over TCP, and then you get all these TCP ACKs... why would that be appropriate, but sending that amount of feedback for something that's running over UDP wouldn't?
>>
> It does also cover cases where you have multicast-like distribution scenarios - such as mixers and relays. But as the group size diminishes the imposed delay is reduced so it can allow for what AVPF term's 'immediate' feedback (with some caveats).
>
> But since the goal of limiting feedback is largely to avoid congestion it might seem that it one could make an exception if we're actually using them for congestion avoidance...

True.  Note that sending rates should take into account RTCP usage 
(actual, not maximum), I believe.

-- 
Randell Jesup
randell-ietf at jesup.org