[R-C] Feedback mechanisms

[Harald Alvestrand]

Is there value in going completely extreme and define a generic header 
extension for piggybacking RTCP in RTP packets?

That way, whatever we define in RTCP can also be carried as a header 
extension, if it makes sense to do so.

Of course, it may rarely make sense.

On 08/12/2012 06:26 AM, Randell Jesup wrote:
> 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.
>