[R-C] Feedback mechanisms

[Bill Ver Steeg (versteb)]

Sorry for the spasm of email--- I am getting caught up correspondence.

Note that the periodic feedback can convey more than a single temporal datapoint. As I discussed in a previous email, the receiver can inform the sender about trends or discontinuities in the data. This is particularly useful if the sender and receiver can both recognize/signal discontinuities in the data. 

So, I am arguing for periodic feedback that has a structure that allows a rich information flow back to the sender. Based on such data flows, the sender would like to glean "I am OK when I send at 2 Mbps or 3 Mbps, but the buffers are slowly building when I burst at 4 Mbps and catastrophically congested when I burst at 5 Mbps". It could also glean "I am sending at a constant rate, but I seem to be getting sporadic cross traffic (or fade) that occasionally drives delay". It obviously can also glean "Based on increasing delay and the onset of loss, the channel can no longer support this rate, I need to downshift" and "no loss and constant delay --- I am fine" with some very short, infrequent messages. Knowing the statistical/temporal detail about delay is important, and worth some resources. 

Note that in addition to periodic feedback, timely feedback when anomalous conditions occur is probably desirable.

So --- IMHO, this is not a "do we do congestion control in the sender or the receiver?" question. It is a question of cooperation between the two to detect and set the correct rate. Knowing when to upshift is as important as knowing when to downshift. 

bvs


-----Original Message-----
From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of John Leslie
Sent: Monday, August 13, 2012 10:08 AM
To: Stefan Holmer
Cc: rtp-congestion at alvestrand.no
Subject: [MARKETING] Re: [R-C] Feedback mechanisms

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

   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.

--
John Leslie <john at jlc.net>
_______________________________________________
Rtp-congestion mailing list
Rtp-congestion at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtp-congestion