Nice summary, some comments inline. On Wed, Aug 8, 2012 at 6:35 PM, Randell Jesup <randell-ietf@jesup.org>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.
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.
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)
The fallback to RTCP is particularly important for receive-only clients.
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@jesup.org
______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>