[R-C] Feedback mechanisms

[Randell Jesup]

On 8/11/2012 6:50 PM, Mo Zanaty (mzanaty) wrote:
> 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.

I *may* agree, though I also agree it may be unpopular.

I've had to do it because of using SBCs configured not to pass RTCP at 
all and didn't like RTCP on the RTP port, and I needed it for PLI/etc.  
But that was a rare homegrown (though ISP-wide) SBC; even misconfigured 
SBCs typically support RTCP-mux I imagine.  And I did it before RTCP-mux 
was defined, and was part of why I supported RTCP-mux.

Once you start pushing enough data to double the normal packet rate, the 
per-packet overhead can get to be a problem, especially if you're on a 
low-bandwidth link.  Instead of (say) 30 video + 50 audio packets per 
second, you have an additional 80.  Sending them in header extensions 
would save around 20Kbps, perhaps a little more - marginal if you have 
250Kbps or up, but significant if you have (say) 128Kbps, and already 
are losing around 25Kbps to overhead.  My old phones would run 30fps 
down to total bandwidth of as low as 60-80kbps, though it was running 
QCIF down that low (plus iLBC 20ms - 15Kbps+overhead, so video payload 
got as low as 40, even 30Kbps). At those bitrates, 20Kbps is huge.

I'll admit given RTCP-mux (and assuming nothing interferes with 
negotiation of it!), the argument is largely one of efficiency in 
bandwidth and packet-rate.  And this is much less of an issue if you're 
not sending circa 1 feedback message per packet.

I assume this would fall in CORE.

> 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.

I think there was a generic ACK in an earlier draft, but it was removed 
(I think a hole in the code list was left to avoid breaking people 
working with the draft).

> 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.

Quite true.  The toughest part is to define when such a thing should be 
used over RTCP-mux.  It would make using other header extensions tricky 
(though possible), and it would imply a circa up to 20, 30, perhaps in a 
few cases 100ms delay in sending feedback (avg circa 1/2 that; less if 
they can piggyback on other RTP streams).  If there's "important" data 
you could send a direct RTCP and not wait.

-- 
Randell Jesup
randell-ietf at jesup.org