[R-C] Feedback mechanisms

[Stefan Holmer]

Nice summary, some comments inline.

On Wed, Aug 8, 2012 at 6:35 PM, Randell Jesup <randell-ietf at 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 at jesup.org
>
> ______________________________**_________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120809/33046b3f/attachment-0001.html>