Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC

From: "Phelan, Tom" <[email-masked]>
Date: Mon, 4 Aug 2003 14:08:24 -0400

Hi Brian

> > So, is the right thing to do to ramp up at the beginning of the call
> > to the best rate you can get, then only ramp down?  This overcomes
> > Tom's concerns about probing bandwidth.
> There is no point in "ramping".  You send at the rate you decide 
> (however you decide).  If you have to change, you signal a change,
> disrupt the flow, and change.  There isn't anything elastic here.
> You send at a fixed rate.  If you don't recieve at the correct
> rate you can handle a (small) amount of variation by buffering, but
> mostly, you discard and hope it gets better.

Unfortunately, with slow-start, you can't just start sending at an adequate
rate.  At the beginning of the connection you need to treat the rate that
TFRC sets differently from the way you treat it later, after you've
slow-started up to an adequate rate.  I think that's what Aaron was
referring to.

Tom P.

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

---

From: Mark Handley <[email-masked]>
Date: Mon, 04 Aug 2003 19:36:10 +0100

>slow-started up to an adequate rate.  I think that's what Aaron was

For VoIP, perhaps slowstart at startup is simply unnecessary.  Lets
look at what TCP does.  Assume a 1500 byte MSS, and 200ms RTT.  Thus
the starting rate for a TCP connection will be one packet/RTT, which
is 1500*8/0.2 = 60Kb/s.  And this is assuming an initial window of one
packet, which is pretty conservative these days.

So, a VoIP flow that started at anything up to 64Kb/s (including
headers) would be perfectly reasonable - it's no worse than TCP's
default behaviour.  If the RTT were a lot larger, you'd be expected to
start slower, but if it's a lot larger than 200ms, then you're going
to have interactivity problems anyway.

Now, the question would be what happens when this is too fast?  There
are two cases really:

 - Low stat mux at bottleneck.  Here TFRC will probably build a queue
   pretty rapidly, and a good TFRC implementation would slow down as a
   result of the RTT increasing.  Pretty soon you'll see some loss,
   and things will settle down to the slower steady state.

 - High stat mux at bottleneck.  TFRC won't immediately slow down -
   that will take some loss to achieve.  But the high level of stat
   muxing and the fact that each flow only sends too fast for a small
   fraction of it's duration mean that the overall effect should be
   relatively benign.

Thus neither case seems to be terribly bad.  But this only applies to
VoIP, where the bitrates are relatively benign compared to TCP's
startup behaviour, and even then if the RTT is high, you get to start
more slowly.

Cheers,
	Mark