Re: [rmcat] Colin's feedback bandwidth analysis

[Randell Jesup <[e-mail]>]

Adding avtext:

On 7/19/2016 8:51 AM, Randell Jesup wrote:
> Colin - thanks for the analysis!
>
> 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.
>
> 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


I'll add:
* at lower bandwidths relax the reporting interval to reduce effects of 
overhead and improve compression of the data, at the cost of 
less-reactive results in the congestion control
** Implies the need to test the algorithms for sensitivity to 
less-than-ideal feedback intervals
* look at (with some annoying complexity implied) piggybacking this data 
on RTP packets in header extensions
** shares overhead with reverse-direction RTP (good), may add to delay 
in receiving them (bad), but given that packets may be queued in both 
directions, piggybacking may work well in practice at higher 
framerates.  If we need to send feedback and the next anticipated packet 
going out isn't for a "while", we'd send an RTCP.  If we're pacing 
packets out or likely to send one "soon" relative to the reporting 
frequency, piggyback it.
** size of the extension might be an issue (packet size limits)
** this definitely adds complexity, but can save a considerable amount 
of overhead

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

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