<br><br><div class="gmail_quote">On Tue, Nov 8, 2011 at 1:52 PM, Randell Jesup <span dir="ltr"><<a href="mailto:randell-ietf@jesup.org">randell-ietf@jesup.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11/8/2011 12:53 PM, Piers O'Hanlon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I thought it would be useful to understand what people consider are<br>
the problems with TFRC, and why they mean a new congestion protocol<br>
would be better for RTCweb?<br>
</blockquote>
<br></div>
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).<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Clearly TFRC does have some issues though it would be useful for the<br>
community to understand why TFRC needs to be superseded? Given that it<br>
is probably the most widely cited standard for real-time media flows<br>
and appears to have a growing number of 'TFRC based' deployments: e.g.<br>
GoogleTalk says it is 'based upon TFRC'<br>
</blockquote>
<br></div>
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.<br>
<br>
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.</blockquote><div><br></div><div>There is no standard spec for doing RTP over TFRC currently, although there is a draft floating around. And while Talk and Hangouts currently use a TFRC-based algorithm, this algorithm has been tweaked substantially to use delay-based congestion control, instead of the typical loss-based congestion control from TFRC (since losses can cause bad things in real-time applications).</div>
<div><br></div><div>As Randell says, since what we want is TCP-friendly UDP, it probably makes more sense to come up with a new mechanism that can provide this friendliness, instead of reworking TFRC to fit our needs. Harald's draft proposes such a mechanism.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Gnome's Empathy IM/videoconf<br>
client has recently put TFRC support into their Farsight library, and<br>
others (Magor etc) who mentioned their use of it on RTCweb.<br>
</blockquote>
<br></div>
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".<br>
<br>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess I can start with a few well known issues with TFRC:<br>
- Problems with clocking the packets out for TFRC<br>
- Issues with using variable packet sizes<br>
</blockquote>
<br></div>
Which is the norm for video.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- "Very low video bitrates at moderate loss rates" 3GPP tr26.114<br>
</blockquote>
<br></div>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- 'Oscillatory behaviour'<br>
</blockquote>
<br>
Also a major issue as my memory indicates, though some oscillation (below significant effect on user-noticeable quality) is ok.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Randell Jesup<br>
<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a></font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no" target="_blank">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/<u></u>mailman/listinfo/rtp-<u></u>congestion</a><br>
</div></div></blockquote></div><br>