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

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 24 Jul 2003 21:28:59 -0400

Hi Eddie,

One more problem I see for two-way voice is slow-start.  This is somewhat
related to "rate slows down during idle periods", but you're stuck with it
even if you don't do silence suppression.

I don't have a "TCP-friendly" solution for this yet.

Tom P.

> -----Original Message-----
> From: Eddie Kohler [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 5:59 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: What's wrong with TFRC for VoIP and other apps?
> 
> 
> 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: "Rosen, Brian" <[email-masked]>
Date: Fri, 25 Jul 2003 13:25:30 -0400

In VoIP (audio and video) you NEVER resend.  You drop
and move on. So, the resend mechanism is baggage for us.
It's one of the reasons UDP is used.

Having an agreed upon max rate would be good.
It would be nice to have some kind of negotiation:
	I want to send at 64K
	You can only send at max 40K
	Okay, the max I can use then is 32K
	Fine, 32K it is

Brian

> From: Damon Lanphear [mailto:[email-masked]]
> Sent: Friday, July 25, 2003 12:37 PM
> To: Eddie Kohler
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dccp] What's wrong with TFRC for VoIP and other apps?
> 
> 
> 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:
> > Hi all,
> > 
> >    The TFRC allowed sending rate will drop down to 
> something very small
> >    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
> >    An app might have a discrete set of sending rates. Must 
> it send at the
> > 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]>
> 
> 
> 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
>