[R-C] Feedback mechanisms

[Michael Welzl]

On 13. aug. 2012, at 16:07, John Leslie wrote:

> Stefan Holmer <stefan at webrtc.org> wrote:
>> 
>> Worth noting that we have the option of only sending frequent feedback
>> (e.g. once per packet) when we experience congestion. The rest of the time
>> we can simply trigger the feedback periodically.
> 
>   This, alas, is optimizing the wrong thing.
> 
>   We can, indeed, send very-short feedback when no congestion is evident
> to the receiver. But in the absence of a heartbeat, we're at the mercy
> of Murphy's law whether the signal of congestion detected reaches the
> sender. (Indeed, one of the likely sources of congestion is a wireless
> link which is likely to show congestion in both directions.)
> 
>   Thus, I recommend continuous feedback on a heartbeat schedule, so that
> the absence of feedback could start a backing-off of send rate. We're
> working in unreliable IP packets, not reliable "circuits".

I agree, but Stefan already wrote "The rest of the time we can simply trigger the feedback periodically", which covers what you call a "heartbeat schedule", I guess?


>   The feedback in the absence of congestion could be essentially zero
> length -- and I hope we will consider folding it into a reverse path
> media packet (where the "receiver" detecting congestion is "sender" of
> a corresponding media stream in the other direction). This _will_ be
> a common case, and quite possibly the most-common case.

I do think that people are considering that - I have the impression that there is mostly agreement with the idea of piggybacking feedback onto RTP packets in some (but which, is not yet clear) way whenever that's possible.

Cheers,
Michael