[R-C] Feedback mechanisms

[Randell Jesup]

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.

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)

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 at jesup.org