[R-C] Feedback mechanisms

Mon Aug 13 10:12:03 CEST 2012

Maybe I wasn't clear. I wasn't saying limit the feedback; rather let's not worry about optimising transport of the feedback until we know what feedback we want. 

Colin

On 13 Aug 2012, at 10:28, Michael Welzl wrote:
> Hm, I think I don't agree with considering such optimizations later: the way I read the charter, we're providing a framework for cc. algorithms, i.e. *the* algorithm doesn't exist.
> 
> It's not hard to construct cases where limiting feedback may be a bad idea. For example: the queue grows => before the sender can notice it or react, you lose just the few feedback packets that are sent, the sender has to resort to a timeout => even more queue growth due to slow reaction; this may seem a bit artificial, but do we already want to make a decision to live with this situation?
> 
> If decisions follow the sequence:
> 1) first algorithm: has limited feedback
> 2) define feedback just for that algorithm, assume it works for all
> 3) more algorithms...
> 
> ... then we may be putting ourselves in a corner that we can't get out of, making it impossible to define a mechanism that would solve problems like the one above.
> 
> Cheers,
> Michael
> 
> 
> On 13. aug. 2012, at 07:00, Colin Perkins wrote:
>> It might be more productive to consider this sort of optimisation later, once we've defined the congestion control algorithm, and seen if it's needed. Optimising the header overheads on a not-yet-defined protocol seems premature, and it's not clear that we need enough feedback to require this sort of optimisation.
>> 
>> Colin
>> 
>> 
>> 
>> On 13 Aug 2012, at 02:03, Harald Alvestrand wrote:
>>> 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.
>>>> 
>>> 
>>> _______________________________________________
>>> Rtp-congestion mailing list
>>> Rtp-congestion at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>> 
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> 

-- 
Colin Perkins
http://csperkins.org/