[R-C] Why not TFRC?

[Justin Uberti]

On Tue, Nov 8, 2011 at 1:52 PM, Randell Jesup <randell-ietf at jesup.org>wrote:

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


There is no standard spec for doing RTP over TFRC currently, although there
is a draft floating around. And while Talk and Hangouts currently use a
TFRC-based algorithm, this algorithm has been tweaked substantially to use
delay-based congestion control, instead of the typical loss-based
congestion control from TFRC (since losses can cause bad things in
real-time applications).

As Randell says, since what we want is TCP-friendly UDP, it probably makes
more sense to come up with a new mechanism that can provide this
friendliness, instead of reworking TFRC to fit our needs. Harald's draft
proposes such a mechanism.

>
>
>  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
>
> ______________________________**_________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20111108/4a27f419/attachment.html>