Nice summary, some comments inline.<br><br><div class="gmail_quote">On Wed, Aug 8, 2012 at 6:35 PM, Randell Jesup <span dir="ltr"><<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, there are a few possible feedback mechanisms (regardless of the exact algorithm):<br>
<br>
1) TMMBR<br>
Has issues in that it's SSRC-specific<br>
Requires most of the algorithm to run in the receiver<br>
Travels over RTCP and is subject to AVPF rules, otherwise can send whenever needed<br>
Pro:<br>
Already exists, has some chance of being useful in interop situations (iffy)<br>
Con:<br>
In extreme congestion, can fail to be delivered.<br>
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.<br>
<br>
2) REMB<br>
Multiple SSRCs (good)<br>
Requires most of the algorithm to run in the receiver<br>
Travels over RTCP and is subject to AVPF rules, otherwise can send whenever needed<br>
Pro:<br>
Eases merging congestion information for streams<br>
Lower "extra" packet rate than explicit ack<br>
Can be suppressed when nothing interesting is happening - Lower bandwidth usage<br>
Con:<br>
If RTCP fraction is too low, can be blocked (so don't make it too low)<br>
In extreme congestion, can fail to be delivered.<br></blockquote><div><br></div><div>You could sent one REMB for each "congested" packet received and thereby further reduce the chance of losing important REMBs due to congestion on the feedback channel.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3) Explicit RTCP C-ACK packets (Congestion-ACK)<br>
1 packet per incoming packet (or short queuing time before sending to cut packet rate)<br>
Algorithm runs mostly in the sender<br>
Travels over RTCP and is subject to AVPF rules<br>
Pros:<br>
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<br>
Cons:<br>
Extra bandwidth and packet traffic - increases congestion and uses queue slots<br>
If RTCP fraction is too low, can be blocked (and this uses a lot more than 1 or 2)<br>
<br>
I'm going to propose a fourth mechanism:<br>
4) CHEX (Congestion Header EXtension) - ok, come up with a better name!<br>
Multiple SSRCs - multiple 'acks' in the extension<br>
Allows most of the algorithm to run in the sender<br>
Piggybacks in header extensions, can only send with an RTP packet (i.e. may be delayed)<br>
Pros:<br>
Extends existing support for actual send time header extensions (XXXX)<br>
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<br>
Minimal additional bandwidth compared to C-ACK (3)<br>
Cons:<br>
Anything that strips header extensions causes failover to basic<br>
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).<br>
Only one header extension per packet may be a small issue.<br>
Cuts max payload some (not a lot), but that may limit the number of updates in a single packet.<br>
Noticeably more bandwidth than REMB (2)</blockquote><div><br></div><div>The fallback to RTCP is particularly important for receive-only clients.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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).<br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Randell Jesup<br>
<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a><br>
<br>
______________________________<u></u>_________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no" target="_blank">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/<u></u>mailman/listinfo/rtp-<u></u>congestion</a><br>
</font></span></blockquote></div><br>