[R-C] Why not TFRC?

[Randell Jesup]

On 11/8/2011 12:53 PM, Piers O'Hanlon wrote:
> 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?

In addition to the below, I'll note that the requirements when you have 
multiple streams between endpoints and the ability to adjust the split 
of bandwidth between them, and to adjust the parameters of the streams 
directly (resolution, framerate, etc) give more degrees of freedom and a 
more complex set of incoming data than TFRC was designed for.  You could 
run each stream as an independent TFRC stream, but that would result in 
a bunch of sub-optimal use-cases (and they'd fight, which my memory 
indicates tends towards oscillation).

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

My understanding is that Google Talk (and Hangouts) are based on the 
algorithm laid out in Harald's draft, which uses TFRC-equivalent as an 
upper bound more or less, but does not actually implement TFRC.

I personally have seen no uses of TFRC, though on the other hand I 
haven't really looked outside of hardware/software videophones and VoIP 
devices.

> 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've implemented videophones and associated congestion-control regimes 
in the past, and followed the definition of TFRC in the IETF (and 
early-on decided it was not of any utility for my old company).  TFRC, 
as with all loss-based solutions, fails miserably in bufferbloat 
situations, as *seconds* of delay can build up before any loss occurs. 
The problem is probably worse now than when I first ran into it in early 
2004.  I do not consider TFRC a viable candidate for robust realtime 
communication.  Many proprietary solutions have been created in the 
meantime like the one I came up with in 2004, what GIPS (now Google) 
came up with a short while later I believe, what Radvision has recently 
laid out, etc.  Until recently everyone considered these delay-based 
solutions a proprietary value-add; they've only recently "come out of 
the closet".

Also, the 1/RTT reporting requirement was a stumbling block, though 
perhaps a solvable one.  In reality, algorithms need *up to* 1/RTT 
reporting depending on the situation (and sometimes faster than 1/RTT is 
helpful), but at other times (stability) need very little feedback. 
This requires active support at both ends, not just the sender.

> 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

Which is the norm for video.

> - "Very low video bitrates at moderate loss rates" 3GPP tr26.114

A real issue for TFRC I imagine - though delay-based algorithms should 
avoid almost any congestion-based loss except on extreme swings with 
low-buffer devices.

> - 'Oscillatory behaviour'

Also a major issue as my memory indicates, though some oscillation 
(below significant effect on user-noticeable quality) is ok.

But honestly, none of those matter if TFRC doesn't deal with bufferbloat 
and minimize delay, and it doesn't.  It's TCP-friendly UDP, it's not 
delay-sensitive.

-- 
Randell Jesup
randell-ietf at jesup.org