Subject: [MMUSIC] What's wrong with TFRC for VoIP and other apps?

From: Eddie Kohler <[email-masked]>
Date: Thu, 24 Jul 2003 14:58:46 -0700

Hi all,

I just wanted to try to summarize the issues people have brought up, in
other threads, about why TFRC and/or DCCP will be inappropriate for VoIP
and other apps. I agree with Tom Phelan's comment that the biggest issues
have to do with TFRC, not the API. I've left off the solutions people have
proposed to these problems.

1. Rate slows down during idle periods

   The TFRC allowed sending rate will drop down to something very small
   (2-4 packets/RTT) when the sender is idle. This may cause problems
   particualrly with VoIP conversations, which are naturally idle-one-way
   then idle-the-other-way. The rampup from the small rate to the fair rate
   may take several to many RTTs, ouch.

2. Rate will not increase during app-limited period

   This is essentially the same problem as above. Say the application is
   sending at rate R. The allowed rate will not increase much beyond R
   (say, more than 2R) until the app transmits at a faster rate. 

3. Apps with fixed sets of rates

   An app might have a discrete set of sending rates. Must it send at the
   highest app rate <= the TFRC allowed rate? Would be very nice to allow
   some flexibility, so that it could send at, say, the highest rate <=
   1.8*TFRC_allowed_rate.

4. Rate changes/oscillations

   There are application costs, possibly significant ones, associated with
   changing rates. If the app has to change its rate frequently, because of
   CC, that's a problem.

Have I missed anything?

Eddie

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Damon Lanphear <[email-masked]>
Date: 25 Jul 2003 09:37:24 -0700

Eddie,

I would add that when ECN is not available loss becomes a considerable
factor that bounds the TFRC rate.  The TFRC algorithm periodically
touches the upper bounds of the link capacity, at which point loss is
induced, and the algorithm decreases the rate.  The result is periodic
distortion. 

This distortion can be mitigated through a resend mechanism.  But when
you combine a resend mechanism with adherence to the TFRC rate, you get
a more complicated solution. You have to define a trade off between
delay for satisfying resends and minimizing distortion. 

Of course, congestion induced loss is a fact of life in the best effort
internet.  But we can at least define a way by which TFRC can further
minimize periodic loss.  I understand that TFRC as it is currently
defined has been designed to significantly dampen periodic oscillations.
I think, however, that we may want to go a step further and say that
TFRC can optionally limit itself to some maximum rate, that may vary
over the duration of the session, but is defined by the application.  

The intent in doing so is to obviate the requirement that TFRC
constantly push against an unknown upper bounds.  So unless congestion
causes the upper bound to be close to the defined maximal rate, periodic
loss will be eliminated.  If the maximal rate is close to the link rate
(due to congestion, or otherwise) then we are no better off than
before.  But at least there is an opportunity to specifically provision
sessions for known media rates.

On Thu, 2003-07-24 at 14:58, Eddie Kohler wrote:
> dccp IETF mailing list: [email-masked]
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
-- 
Damon Lanphear <[email-masked]>