[R-C] Why not TFRC?

[Wesley Eddy]

On 11/8/2011 12:53 PM, Piers O'Hanlon wrote:
> HI,
>
> I thought it would be useful to understand what people consider are
> the problems with TFRC, and why they mean a new congestion protocol
> would be better for RTCweb?
>
> Clearly TFRC does have some issues though it would be useful for the
> community to understand why TFRC needs to be superseded? Given that it
> is probably the most widely cited standard for real-time media flows
> and appears to have a growing number of 'TFRC based' deployments: e.g.
> GoogleTalk says it is 'based upon TFRC', Gnome's Empathy IM/videoconf
> client has recently put TFRC support into their Farsight library, and
> others (Magor etc) who mentioned their use of it on RTCweb.
>
> I guess I can start with a few well known issues with TFRC:
> - Problems with clocking the packets out for TFRC
> - Issues with using variable packet sizes
> - "Very low video bitrates at moderate loss rates" 3GPP tr26.114
> - 'Oscillatory behaviour'
>
> Once a few of these are clear one would expect the new offering(s)
> would need to show they can demonstrate improvement in these areas.


It's possible to use TFRC in order to compute a bound, and then use
a 2nd algorithm with a focus on delay, operating below the bound set by
TFRC.

The TFRC feedback and equation can be computed based on the aggregate
of media flows rather than per-flow, while adjustments can be made
per flow in order to make the new aggregate conform to the TFRC limit.
There would be some tailoring involved, but overall, I think there
could be a strong basis on TFRC.

Other experimental algorithms could (and should!) be developed that
might be more aggressive, but at the moment, if there is some great
urgency, TFRC seems to be the closest Standards Track tool for the job.
I think the protocols could be tooled in order to support swap-out of
CC mechanisms over time, with some reasonable expectations of what the
CC mechanism needs as inputs (e.g. delays, loss events, etc) and what
types of levers it needs to use as outputs (e.g. adjusting rates,
packet sizes, etc.).

-- 
Wes Eddy
MTI Systems