Re: [rmcat] Colin's feedback bandwidth analysis

[Colin Perkins <[e-mail]>]

Randell,

> On 19 Jul 2016, at 13:51, Randell Jesup <[e-mail]> wrote:
> 
> Colin - thanks for the analysis!

Thanks for following up!

> Agree with Mo that this implies we're way over the default 5% (which can be bumped, of course, but knowing how far we need to bump it is important).
> 
> As for expected rates... I would expect a common range of rates (especially at the start of a stream) would be 200-500kbps @ 30fps, extending up to 1-3Mbps @ 30fps.  I would expect to see bandwidths scale down to  40-50Kbps @ 30fps (I've deployed videophones operating well down to that (QCIF H264)).  At the high end, I expect to scale up to 5+Mbps @ 30 or even 60fps.  And there may be use for 60fps down in the 500Kbps-2Mbps range for some usecases.

That’s helpful, but how bursty are the codecs? The analysis I did in draft-ietf-rmcat-rtp-cc-feedback-01 assumes CBR video (split the bit rate evenly between frames, assuming all frames are the same size). That’s clearly not right, but is it close enough? And, if not, what’s the pattern of bursts that might be expected?

> This speaks to:
> * improve compression of the feedback data (RLE the loss data (or huffman encode, etc), and delta-encode the arrival times).  I was pretty sure we'd need to do this, and this confirms it.
> ** There's more to win with compressing the arrival times aggressively
> * negotiate the needed resolution and reporting intervals with the sender-side control in some manner.  If need be, do it in-band in RTCP.
> ** while more painful in implementation, even the resolution/range of the timestamps could be negotiated
> * we should consider if there's a way to compress or omit the repeated information that's in every report that Colin enumerated
> ** list of streams etc rarely changes
> 
> The bandwidth implications of this was part of why (for adaptation in the 30-250Kbps @ 30fps) I used sparse receiver-side congestion control in the Ojo, reporting only significant changes in derived bandwidth via RTCP.  The challenge here will be to find a way to fit feedback needed for sender-side congestion control into the available bandwidth.  I'm not concerned with having to increase the 5% default per se, but I am concerned with how much "goodput" we get in two-way traffic.  I don't want 200Kbps @ 30 spending 50Kbps on feedback….

These are all possibilities, certainly. I think we next need to get agreement on the range of scenarios, and the types of RTP packet traces we might get out of them, so we can evaluate the possibilities. 

Cheers,
Colin


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