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

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 24 Jul 2003 15:26:27 -0400

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
penalized for transmitting less than we could.  You're only penalized when
you transmit nothing for some number of roundtrip times.

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.

It might be useful for DCCP to tell the application about rate changes.  For
instance, 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.  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.

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

---

From: Eddie Kohler <[email-masked]>
Date: Thu, 24 Jul 2003 15:09:48 -0700

> Note that, by my interpretation of TFRC at least, we won't be

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.

> It might be useful for DCCP to tell the application about rate changes.  

We absolutely want the API to take care of this.

Eddie

---

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

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
> 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:
> 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]>