[rmcat] Colin's feedback bandwidth analysis

[Randell Jesup <[e-mail]>]

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

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