[R-C] Why not TFRC?

[Piers O'Hanlon]

On 8 November 2011 22:46, Randell Jesup <randell-ietf at jesup.org> wrote:
> 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.
>
I think you're right there - I was curious if anyone had tried to play
with it all - as it does seem that some people are attempting use
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...
>
> 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.
>
Ok.

>>>> - "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.
>
Sure though I guess we're probably in a lucky position if we're the
only flow on the link that might have control over whether there is
actually delay or not? I'd have thought that a lot of links are going
to have share with at least the odd TCP flow that has already brought
the delay up.

The fairness issues can be tricky - I guess there's lots of tricks
that have been played with trying to multiple streams to gain on
single streams. It depends how fair you want to be and on what terms.
Should we go Conex or just flow fair...?


>>>> - '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
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>