[R-C] Feedback mechanisms

[Piers O'Hanlon]

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.... 

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.


> - 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...

Piers.

> - Nothing's bad about sending a lot of feedback traffic as long as there is no backwards congestion, and backwards congestion can be detected and reacted upon, in rather simple ways - see RFC 5690, or DCCP for examples. It's early enough to reduce feedback when backwards congestion is detected in my opinion.
> 
> - It seems that a sender should be able to parse a multitude of feedback packets... not sure if we can cleanly standardize such a thing, but in case of RTCWEB for instance, you may face incoming RTCP TMMBR messages, some new RTCP message and SCTP ACKs too, all from the same path... I think that the FSE could help here. But first things first, I suppose.
> 
> Cheers,
> Michael
> 
> 
> On 8. aug. 2012, at 18:35, Randell Jesup wrote:
> 
>> So, there are a few possible feedback mechanisms (regardless of the exact algorithm):
>> 
>> 1) TMMBR
>>    Has issues in that it's SSRC-specific
>>    Requires most of the algorithm to run in the receiver
>>    Travels over RTCP and is subject to AVPF rules, otherwise can send whenever needed
>>    Pro:
>>        Already exists, has some chance of being useful in interop situations (iffy)
>>    Con:
>>        In extreme congestion, can fail to be delivered.
>>        If congestion information is merged between multiple streams between endpoints, it's confusing what should be sent for a specific SSRC - requires the receiver to make decisions about inter-stream tradeoffs without knowing the parameters, or requires revising the TMMBR spec.
>> 
>> 2) REMB
>>    Multiple SSRCs (good)
>>    Requires most of the algorithm to run in the receiver
>>    Travels over RTCP and is subject to AVPF rules, otherwise can send whenever needed
>>    Pro:
>>        Eases merging congestion information for streams
>>        Lower "extra" packet rate than explicit ack
>>        Can be suppressed when nothing interesting is happening - Lower bandwidth usage
>>    Con:
>>        If RTCP fraction is too low, can be blocked (so don't make it too low)
>>        In extreme congestion, can fail to be delivered.
>> 
>> 3) Explicit RTCP C-ACK packets (Congestion-ACK)
>>    1 packet per incoming packet (or short queuing time before sending to cut packet rate)
>>    Algorithm runs mostly in the sender
>>    Travels over RTCP and is subject to AVPF rules
>>    Pros:
>>        Sender can trigger on failure to receive C-ACKs - though we don't know if there's congestion in the sending direction, just in the feedback direction
>>    Cons:
>>        Extra bandwidth and packet traffic - increases congestion and uses queue slots
>>        If RTCP fraction is too low, can be blocked (and this uses a lot more than 1 or 2)
>> 
>> I'm going to propose a fourth mechanism:
>> 4) CHEX (Congestion Header EXtension) - ok, come up with a better name!
>>    Multiple SSRCs - multiple 'acks' in the extension
>>    Allows most of the algorithm to run in the sender
>>    Piggybacks in header extensions, can only send with an RTP packet (i.e. may be delayed)
>>    Pros:
>>        Extends existing support for actual send time header extensions (XXXX)
>>        Sender can trigger on failure to receive - though we don't know if there's congestion in the sending direction, just in the feedback direction
>>        Minimal additional bandwidth compared to C-ACK (3)
>>    Cons:
>>        Anything that strips header extensions causes failover to basic
>>        Requires waiting for an outgoing packet - fallback to sending via RTCP if we need to send "now" or if we've waited too long for a media packet (or anticipate waiting too long).
>>        Only one header extension per packet may be a small issue.
>>        Cuts max payload some (not a lot), but that may limit the number of updates in a single packet.
>>        Noticeably more bandwidth than REMB (2)
>> 
>> Basically, it would be a combination of the actual send time (like XXXX), and reception data (equivalent to TCP ACKs, but including the time received or the inter-packet delta difference from the send time stamp (i.e. the input to the Kalman filter).
>> 
>> I'm not saying this is my preference (I currently believe it makes more sense to run at least the Kalman filter in the receiver, and probably omit some , but it makes sense to explore the tradeoffs between sender and receiver running the algorithm.
>> 
>> If we feel we want to use explicit acknowledgment or seriously consider it, we'll need to talk more about this and the tradeoffs and make this more fleshed-out.
>> 
>> -- 
>> Randell Jesup
>> randell-ietf at jesup.org
>> 
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> 
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion