[R-C] Why not TFRC?

[Randell Jesup]

On 11/8/2011 4:44 PM, Piers O'Hanlon wrote:
> On 8 November 2011 18:52, Randell Jesup<randell-ietf at jesup.org>  wrote:
>> 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

I haven't tested them myself; but their purpose is to minimize 
oscillations in a particular case, not minimize RTT, and the overall 
smoothing is simplistic.  It's still a loss-based solution, so while it 
might back off some, delay can still wander up until you hit loss - 
which is when you may have seconds of delay.

The algorithm simply didn't have delay as a design goal, so no surprise, 
it doesn't handle it well.

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

We do have variable audio (within a much smaller range), and some video 
streams average << MTU.  My case the nominal "normal" video bitrate was 
110-200K, so packet size varied a LOT.  And IDR/iframes lead to a burst 
of MTU-size packets.

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

Except we need to control delay, so we *can't* let it get to loss if 
there's any deep buffering.  There's also the question of "what is fair" 
if we replace 4 streams with one "combined" stream - it shouldn't have 
its share drop to 1/4 of what it was.

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

It's hard to avoid all oscillations, but we need to make sure they're 
damped.


-- 
Randell Jesup
randell-ietf at jesup.org