Subject: [MMUSIC] RE: [dccp] One-way live media with DCCP/TFRC

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

Hi Eddie,

See inline ...

Tom P.

> -----Original Message-----
> From: Eddie Kohler [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 6:10 PM
> To: Phelan, Tom
> Cc: [email-masked]'; [email-masked]'; Pasco Anderson, Jay
> Subject: Re: [dccp] One-way live media with DCCP/TFRC 
> 
> 
> > Note that, by my interpretation of TFRC at least, we won't be
> > penalized for transmitting less than we could.  You're only 
> penalized when
> > you transmit nothing for some number of roundtrip times.
> 
> My understanding is, you are not penalized -- you still get 
> to send at your
> (allowed) rate -- but your maximum allowed transmit rate 
> doesn't continue
> to increase. THe maximum allowed transmit rate is bounded 
> above by some
> multiple of the current transmit rate. This is essentially 
> the same as in
> the idle case.

Oh, I missed this.  So if the high rate is more than twice or so the low
rate you'll have to slow-start up to it when you upshift, regardless of how
low the RTT has become.  I think that the scheme I described still works,
though.  You just have some transmit buffer buildup as the rate ramps up,
like in slow-start at the beginning of the connection.

> 
> > It might be useful for DCCP to tell the application about 
> rate changes.  
> 
> We absolutely want the API to take care of this.
> 
> Eddie
> 

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

---

From: [email-masked]
Date: Fri, 25 Jul 2003 16:10:07 +0200

Tom,

first thank you for this detailed and clear description of how a typical system would work!

I agree it  is useful to insist that streaming is about "seconds" rather than "bytes";-)

I share your belief  that the same scheme applies to one-way pre-recorded media.

I also share your hope hat an application transmitting data *below* the TFRC rate is not penalized,
because, as you demonstrate, this is what a streaming application will *have* to do.
By the way can someone give a confirmation about that ?

*****
one remark:

you write:

> ... when DCCP/TFRC has decided on a rate too low for the high rate
>encoding the application could make the change to the low rate immediately.
>This would work, but it might lead to unnecessary switches to the lower
>rate.

Let me give my interpretation of what  "unnecessary switches to the lower rate" are.

For me the "risk" (of reduced quality seen by the user) is the direct result of the congestion control policy.

TFRC is already designed to give you a rate that changes in a "less drastic" manner than  TCP divide-by-two,
and in general to give "smoother" rate variations etc...

In other words, if I dont like the risk associated with using a given congestion control
(say TRFC) the right thing to do should be to design another one, no?

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

---

From: "Phelan, Tom" <[email-masked]>
Date: Fri, 25 Jul 2003 10:28:49 -0400

Hi Philippe,

From an e-mail from Eddie it appears that I wasn't totally correct that
there's no penalty for sending below the maximum rate, but I don't think it
changes my scheme.

From what Eddie said, and from looking at the TFRC RFC again, I think that
while you're sending below the TFRC max rate the max rate doesn't grow (even
if it could).  So if you want to now increase your sending rate, the maximum
you can send in the next RTT is twice what you just sent, regardless of how
low the RTT is.  You need to slow-start up to the rate that you could have
been sending if you were greedy.

Tom P.

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Friday, July 25, 2003 10:10 AM
> To: Phelan, Tom
> Cc: [email-masked]'; [email-masked]'
> For me the "risk" (of reduced quality seen by the user) is 
> the direct result of the congestion control policy.
> 
> TFRC is already designed to give you a rate that changes in a 
> "less drastic" manner than  TCP divide-by-two,

---

From: "Phelan, Tom" <[email-masked]>
Date: Fri, 25 Jul 2003 14:27:53 -0400

Hi Damon,

Yes, the application can pick its "upshift probe" period based on its
knowledge of the user perception of rate shifts (the one up to probe and the
possible one down if the probe fails).  I suspect many apps might choose to
never probe up.

Tom P.

> From: Damon Lanphear [mailto:[email-masked]]
> Sent: Friday, July 25, 2003 12:54 PM
> To: Phelan, Tom
> Great way to frame this problem.  I like this approach.  I have one
> apprehension:
> 
> On Thu, 2003-07-24 at 12:26, Phelan, Tom wrote:
> At this point (perhaps after a slight delay) the sender can 
> switch back
> to
> > the higher rate.  If the new rate can't be sustained the 
> transmit buffer
> > will fill again (and the playout buffer will drain).  When 
> the switch
> > encoding threshold is reached the sender goes back to the 
> lower encoding
> > rate.  This oscillation continues until the stream ends or 
> the network is
> > able to support the high rate for the long term.
> 
> I think we'd like to avoid the oscillation you describe.  Or at least
> extend the period over which it can occur.  But that all comes down to
> understand the impact of the oscillation on the subjective 
> experience of
> the user.  If we're delivering video, and there is a perceivable
> difference in the distortion of the high and low rates, then switching
> back and forth over even 20s intervals could be truly annoying. 
> 
> I think of this oscillation problem as being kind of like 
> that which we
> encounter with congestion control algorithms.  Where there is some
> unknown upper bounds against which we have to test periodically at a
> cost.  I'm not sure what a good solution is.  I think 
> whatever solution
> is put forward will have to be dependent on the attributes of 
> the media,
> and perhaps tie upshift attempts to a combination of buffer state and
> some measure of stability of the upper bounds rate. 
> 
> 
> 
> On Thu, 2003-07-24 at 12:26, Phelan, Tom wrote:
> > Hi,
> > 
> > I've been continuing to think about the one-way live media 
> case and have
> > come up with the following scheme for using DCCP with TFRC. 
>  Recall that
> > one-way live differs from one-way pre-recorded media by having a max
> > possible sending rate equal to the encoding rate (except 
> for very short
> > bursts, perhaps), and differs from two-way interactive 
> media by being
> > tolerant of delay.
> > 
> > So, for this scheme we have a playout buffer at the 
> receiver and transmit
> > buffer at the sender.  Note that these buffers contain 
> media streams, not
> > packets, and their lengths are measured in seconds, not 
> bytes or packets.
> > 
> > The transmit buffer is filled at the encoding rate and 
> drained at the TFRC
> > transmit rate.  The playout buffer is filled at the network 
> arrival rate and
> > drained at the decoding rate.  The playout buffer has a 
> playback start
> > threshold and the transmit buffer has a "switch encoding" 
> threshold.  These
> > thresholds are on the order of a few to several seconds and 
> switch encoding
> > is less than playback start.
> > 
> > Assume that the encoder can encode at two rates, a high 
> rate and a low rate.
> > At the start of a connection, the sender places data into 
> the transmit
> > buffer at the high encoding rate.  The buffer is drained at 
> the TFRC rate,
> > which at this point is in slow-start and is probably slower than the
> > required rate.  This will cause a backup in the transmit 
> buffer.  Eventually
> > TFRC will slow-start to a rate slightly above the rate 
> necessary to sustain
> > the encoding rate.  When this happens the transmit buffer 
> will drain and
> > we'll reach a steady-state condition where the transmit 
> buffer is empty and
> > we're transmitting at a rate that is probably below the 
> maximum allowed by
> > TFRC.  Note that, by my interpretation of TFRC at least, we won't be
> > Meanwhile at the receiver, the playout buffer is filling, 
> and when it
> > reaches the playback start threshold playback will start.  
> After TFRC
> > slow-start and the transmit buffer is drained, this buffer 
> will reach a
> > steady state where packets are arriving from the network at 
> the encoding
> > rate (ignoring jitter) and being drained from the buffer at 
> the (equal)
> > decoding rate.  The depth of the buffer will be the 
> playback start threshold
> > plus the maximum depth of the transmit buffer during slow start.
> > 
> > Now assume that network congestion forces TFRC to drop its 
> rate to below
> > that needed by the high rate encoding.  The transmit buffer 
> will begin to
> > fill and the playout buffer will begin to drain.  When the 
> transmit buffer
> > reaches the switch encoding threshold, the sender switches 
> to the low rate
> > encoding, and converts all of the data in the transmit 
> buffer to low rate
> > encoding.  I'll ignore issues of how to do this 
> efficiently, but it's
> > important not to discard this data, and to convert it.
> > 
> > Assuming that the network can support the new, lower, rate 
> (and a little
> > more) the transmit buffer will begin to drain and the 
> playout buffer will
> > begin to fill.  Eventually the transmit buffer will empty, 
> the playout
> > buffer will be back to its steady-state level, and we'll be 
> transmitting
> > data at the new, lower, encoding rate.
> > 
> > At this point (perhaps after a slight delay) the sender can 
> switch back to
> > the higher rate.  If the new rate can't be sustained the 
> transmit buffer
> > will fill again (and the playout buffer will drain).  When 
> the switch
> > encoding threshold is reached the sender goes back to the 
> lower encoding
> > rate.  This oscillation continues until the stream ends or 
> the network is
> > able to support the high rate for the long term.
> > 
> rate changes.  For
> > instance, when DCCP/TFRC has decided on a rate too low for 
> the high rate
> > rate.  In particular, when DCCP decides on a new rate, it 
> has no way of
> > knowing whether this is a transient or a long-term change.  If it's
> > transient the transmit buffer might be able to absorb the 
> problem, and a
> > change to the lower rate might unnecessarily reduce the 
> quality seen by the
> > user.  If we wait for the switch encoding threshold we can 
> be more sure that
> > the rate change is long-term.  Also, if we rely on rate 
> indications for the
> > downshift, we need to ignore it during slow-start.
> > 
> > It might be more useful to know when DCCP has raised the 
> rate sufficiently
> > to switch to the high rate (after the transmit buffer has 
> been drained).
> > 
> > Note that this scheme is also suitable for one-way 
> pre-recorded media, as
> > long as the transmit buffer is only filled at the encoding 
> rate, not at the
> > disk read rate.  Overall I'd say that this is better than 
> the previous
> > scheme (for one-way pre-recorded media), and I think that 
> some of the
> > commenters on the previous message must have had something 
> like this in
> > mind.
> > 
> > I still don't know how to do the two-way interactive media.
> > 
> > Tom P.
> > 
> > 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]>
>