[R-C] Why not TFRC?

[Piers O'Hanlon]

On 8 November 2011 18:52, 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).
>
As regards cross-flow congestion behaviours there is the ongoing work
on mulTFRC within ICCRG which may provide some solutions, though the
issue here is somewhat different as the multi-flow behaviour is
working with different trade-offs and the transport path probably
isn't different, though of course it could be. I guess the other
multi-path adaptation work going elsewhere like MTCP and SCTP would
could help with some aspects - one may be able adapt the resource
sharing algorithms...


>> 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.
>
Yes I was going on Google's own description:
http://code.google.com/apis/talk/call_signaling.html#Video_Rate_Control
"We use a mechanism based on TCP Friendly Rate Control (TFRC) to
determine the available bandwidth and adjust the rate accordingly."
But as I mentioned it was "based on TFRC" which could mean one of few
things... Though they also mention that they used some of the old TFRC
on RTP. As you're probably aware the draft has recently been reissued
(though I imagine it won't change vastly):
http://tools.ietf.org/html/draft-gharai-avtcore-rtp-tfrc-01


> 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".
>
True bufferbloat can be a major issue with realtime apps.Though TFRC
is not entirely loss based - it does have some mechanisms in it to
backoff as the RTT increases - presumably you found these inadequate?
http://tools.ietf.org/html/rfc5348#section-4.5

> 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.
>
I'm not sure that packet sizes actually vary that much. Video frames
typically consist of a number of MSS sizes frames followed by a
'random' sized packet (to make up the the frame size from NxMSS
packets). I guess if the video is low rate then the packets can be
more variable sized overall. And audio is usually bunch of small
packets of the same [small] size. Though I guess Skype and other have
developed variable sized packet based audio codecs...

>> - "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.
>
It's not clear why the rates should be considered as 'very low' -
given that you're usually competing with some if not alot of TCP
traffic that should using approximately the same rate (if you're going
to be TCP friendly) determined by the loss rate (ie according to the
TCP equation).

>> - '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.
>
The oscillatory behaviour seems to be general problem in this area...

> --
> Randell Jesup
> randell-ietf at jesup.org
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>