Subject: Re: [rmcat] Colin's feedback bandwidth analysis

From: Colin Perkins <[email-masked]>
Date: Thu, 25 Aug 2016 17:03:43 +0100

Randell,

> On 19 Jul 2016, at 13:51, Randell Jesup <[email-masked]> 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/

---

From: Randell Jesup <[email-masked]>
Date: Fri, 26 Aug 2016 17:27:31 -0400

On 8/25/2016 12:03 PM, Colin Perkins wrote:
>
>> 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?

Definitely not CBR... I'm actually gathering data using VP8 and H264 
which I've been feeding to one of the teams to improve the synthetic 
codec model (both steady-state, and how they respond to bitrate changes 
in the control inputs).

In general, they're somewhat variable frame-to-frame, and within a frame 
 > XXXX bytes, you'll have N XXXX byte packets and then a smaller one, 
generally.

Also you'll get occasional packet retransmissions and/or iframes (likely 
followed by several dropped-frames to compensate for the added bandwidth 
of the iframe.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam