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@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of John Leslie Sent: Monday, August 13, 2012 10:08 AM To: Stefan Holmer Cc: rtp-congestion@alvestrand.no Subject: [MARKETING] Re: [R-C] Feedback mechanisms Stefan Holmer <stefan@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@jlc.net> _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion