[R-C] Feedback mechanisms

[Randell Jesup]

On 8/13/2012 3:28 AM, 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.

I believe that we don't need to decide *now* on whether to ask for such 
a mechanism or to assume it's available.  I do think that decision 
weighs into how we evaluate certain fundamental aspects of answering the 
questions posed to the assumed Working Group, such as on whether the 
algorithm runs (primarily) on the sender or receiver sides.

We can base an algorithm option on this proposal, with the assumption 
that we can either rev RTCP/AVPF to allow use to send RTCP feedback 
packets every RTT (or so) and live with this limiting the algorithm to 
somewhat higher-bandwidth connections (if you prefer, to have lower 
quality at the same bandwidth/link), or we can define a header extension 
to limit the cost of such an algorithm.

I think we have a pretty clear idea what the general high-feedback 
options are.  Note my previous bandwidth comparison assumed RTP/RTCP, 
not SRTP/SRTCP: without spending a bunch of time, it's roughly 32Kbps 
base overhead for 30fps low-bandwidth SRTP, around 68Kbps for low-RTT 
low-bandwidth SRTP+feedback, and somewhere around 45Kbps for 
SRTP+header-extension-feedback.  (This makes many assumptions about 
frequency and size of feedback.)

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

You may, but I wouldn't want to pre-answer that question.  Quality 
overall (especially in normal situations) and overall stability 
(including edge/corner-cases) is (likely) a significant measurement for 
this protocol.  Note that we may well be able to have poor performance 
in corner cases if normal-case quality is higher.

-- 
Randell Jesup
randell-ietf at jesup.org