[R-C] Feedback mechanisms

[Bill Ver Steeg (versteb)]

I also like the direction this is heading. A few detailed comments-

There are two competing requirements - 
1- The upstream/return traffic is (generally) assumed to be a precious resource by the RTP community. This is partially due to multicast considerations (which we can mostly ignore here) and partially due to asynchronous networks. Note that the CableTV community has found it necessary to play games with TCP acks in Cable Modems because of upstream bandwidth limitations, even for unicast TCP traffic. This is an ugly hack that I will not defend here, but it is indicative of the problem space. The net-net is that we have to be somewhat conservative in our sending of acks, or we will end up in similar trouble.
2- The receiver/sender would like to be able to get enough information about loss and delay to sense congestion. In the RTP case, the receiver knows the one-way delay and loss rate every time it gets a packet. In an overly-simple model, the receiver would just ack very single packet with a short packet (containing the a summary of the last few packets to protect against loss), and the sender would then know all of the gory details of the downstream delay/loss and the upstream delay/loss. This is clearly overkill.

So, our challenge is to design a feedback mechanism that is timely and information rich, yet does not break the bandwidth budget.

I suggest that we think along the lines of a message that conveys something like " I got N1 packets over T1 time with L1 loss and D1 delay and J1 jitter, then N2 packets over T2 time with L2 loss and D2 delay and J2 jitter, yada, yada, yada". In the simplest case, there is constant delay and no drop, and the packet is infrequently sent. In the more complex cases, a more verbose packet is sent - probably at a more frequent interval. 

If we have a way for the sender to define the grouping of these semantics, it COULD send a series of shaped bursts that probe the network. For instance, it could send large packets at a certain rate for the steady state, then occasionally send back-to-back packets to probe for additional BW (this is the hard part of any rate adaptive algorithm....). It does not need the timing of every packet, but if it can define the feedback summary intervals, a sophisticated sender could do some pretty advanced things. A simple sender could choose to do simple things.

Note that the time intervals can overlap between successive feedback reports, thus providing some protection against loss of feedback packets.

Also note that we need to be crisp in our definition of these "delay", "jitter", etc in such summarized report. Are they max, min, average, mean? For the purposes of this email, I gloss over this detail, but it is important and will need to be addressed

Bill VerSteeg

-----Original Message-----
From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Mo Zanaty (mzanaty)
Sent: Saturday, August 11, 2012 6:51 PM
To: Michael Welzl (michawe at ifi.uio.no); Randell Jesup; rtp-congestion at alvestrand.no
Subject: Re: [R-C] Feedback mechanisms

Michael Welzl <michawe at ifi.uio.no> wrote:
> ...piggybacking ACKs on RTP payload...

Randell Jesup <randell-ietf at jesup.org> wrote:
> ...use header extensions as an alternate channel for RTCP...

Several implementations do either or both of these things, in proprietary ways obviously. I think both should be standardized, although this may be an unpopular view in AVT.

Note that there is no standardized generic ACK. I just submitted an errata to the RFC 4585 ABNF to clarify that "ack" (without parameters) is invalid since there is no generic ACK. There is only "ack rpsi" which is specific to H.263 Annex N, and "ack app" which is proprietary.

Beyond ACK, many other types of RTCP feedback would benefit from the efficiency of piggybacking in RTP header extensions. (NACK, ECN, FIR, TMMBR, PLI, SLI, etc.) So a general mechanism for all RTCP feedback may be more useful than a single mechanism for ACKs.

Mo

_______________________________________________
Rtp-congestion mailing list
Rtp-congestion at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtp-congestion