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