On 8 November 2011 18:52, Randell Jesup <randell-ietf@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@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion