Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching)

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 24 Jul 2003 10:02:01 -0400

Hi Damon,

See inline ...

Tom P.

> -----Original Message-----
> From: Damon Lanphear [mailto:[email-masked]]
> Sent: Wednesday, July 23, 2003 1:52 PM
> To: Phelan, Tom
> Cc: [email-masked]'; Magnus Westerlund; [email-masked];
> [email-masked]; Pasco Anderson, Jay
> Subject: RE: [dccp] natural DCCP sender-side API: (was stream 
> switching)
> 
> 
> Tom,
> 
> Thank you for providing better structure to our discussion.  This is
> precisely what we needed to speak more precisely on these matters!

Thanks :-).

> 
> I haven't been able to work out acceptable scenarios for the other two
> > applications yet.  It seems almost certain to me that TFRC 
> and a blocking
> > API is not at all suitable for two-way media.  It might be 
> suitable for
> > one-way live media, but I haven't figured out how it could 
> be yet.  If
> > anyone has ideas here I'd like to hear them :-).
> 
> I'd like to understand the alternative to a blocking API for two-way
> media.  I assume that in this case the application is responsible for
> managing the transmission rate.  I guess I get confused when 
> I consider
> that some agent in the pipeline will have to block 
> transmission when the
> transmission attempt oversteps the congestion control rate.  What does
> it matter if this agent is DCCP or the application, particularly if we
> have access to the transmit queue in DCCP, as is the case in the ICIR
> implementation ? 

Actually, my big worry here is TFRC, not the API.  I'm baffled about how to
map slow start plus mostly smooth changes but occasional abrupt changes and
a small playout buffer into something workable.

Another thing that concerns me (touched on in the paragraph above) is the
disconnect between a transport protocol making rate decisions and an
application making rate decisions.  It seems to me that these particular
applications are much better equipped to make the rate decisions - they know
about what is possible.  It also seems that the application can make at
least as good a decision about what constitutes network congestion.  The app
will need feedback about the playout buffer state, and this is largely
redundant with the DCCP acks.  If the app is making rate decisions and
detecting network congestion, what do we need DCCP for?

> 
> As regards unidirectional live,  its differs from unidirectional
> on-demand in that there's no data sitting on disk with which to fill a
> post-network buffer to a point where an up shift seems appropriate. 
> Downshifts are straightforward, however, since under sending 
> can just as
> well happen with live streams.  So we need a metric for up shifts that
> does not rely on buffer state.  Perhaps some measure of the 
> stability of
> the available congestion controlled throughput over time?

Yes, this is a problem - downshifts are straightforward, but under what
conditions do you upshift?  If your playout buffer is being depleted you can
downshift at some threshold and stop the depletion.  The problem is that
your playout buffer will never get re-filled, and you're now stuck at the
lower level.  If you upshift and things go bad again, the playout buffer
will go to an even lower level.  Enough of these shifts and the playout
buffer will run out - even if you could have maintained things at the lower
bit rate.

> 
> On Wed, 2003-07-23 at 07:43, Phelan, Tom wrote:
> > Hi Phillipe,
> > 
> > In thinking about your draft on stream rate switching and 
> this discussion on
> > APIs I've come to the conclusion that there are actually 
> three different
> > applications being discussed, with three different sets of 
> requirements.
> > One of these applications can be reasonably satisfied with 
> a blocking API
> > (although there could be some efficiencies with other 
> capabilities).  For
> > the other two I'm not sure yet what would work.
> > 
> > Excuse me if I'm re-inventing something here, but the three 
> applications I
> > have in mind are:
> >  o	One-way pre-recorded media
> >  o	One-way live media
> >  o	Two-way interactive media
> > 
> > The relevant difference, as far as this discussion goes, 
> between recorded
> > and live media is that recorded media can be transmitted 
> from the sender as
> > fast as the network allows (assuming buffering at the 
> receiver).  Live media
> > can only be transmitted at the rate that it's generated.
> > 
> > The difference between one-way (live) and two-way is the 
> size of the playout
> > buffer.  In one-way media you can use a playout buffer 
> that's hundreds of
> > times larger than the round trip time.  In two-way media 
> the playout buffer
> > is on the same order of magnitude as the round trip time.
> > 
> > So, it seems to me that one-way pre-recorded media can be 
> reasonably served
> > by DCCP with TFRC and a sockets-like (blocking) API.  For 
> example, assume
> > that the sender has a media stream in two bit rates, high 
> and low.  Also
> > assume that the sender is able to estimate the depth of the 
> receiver's
> > playout buffer (either via feedback from the receiver or 
> some other means).
> > Now set three thresholds in the playout buffer, a low 
> threshold, a playback
> > start threshold and a high threshold, in order of increasing depth.
> > 
> > To start the connection, the sender begins transmitting 
> data from the high
> > bit rate stream as fast as TFRC allows (blocking the 
> transmit thread for
> > rate control).  Since TFRC is in slow-start, this is 
> probably too slow
> > initially, but eventually the rate might increase to fast 
> enough and past.
> > The receiver buffers data until the playback start 
> threshold is reached, and
> > then begins playback.
> > 
> > If the TFRC rate never gets fast enough, or a packet loss 
> makes TFRC drop
> > the rate, the receiver will drain the playout buffer faster 
> than it's being
> > filled.  If the playout buffer drops below the low 
> threshold, the sender
> > switches to the low bit rate stream.  Assuming that the 
> network has a little
> > bit more capacity than the low bit rate stream requires, 
> the playout buffer
> > will begin filling again.
> > 
> > When the buffer crosses the high threshold the sender 
> switches to the high
> > bit rate stream.  Assuming that the network still doesn't 
> have enough
> > capacity for the high bit rate stream, the playout buffer 
> will drain.  When
> > it reaches the low threshold the sender switches back to 
> the low bit rate.
> > The sender will oscillate back and forth like this until 
> the connection is
> > terminated.
> > 
> > So, in this scheme, the sender doesn't need to know the 
> rate that TFRC has
> > determined, it simply always sends as fast as TFRC allows.  
> TFRC shapes the
> > stream to the network's requirements, and the feedback 
> about the playout
> > buffer allows the sender to shape the stream to the application's
> > requirements.
> > 
> 
> > 
> > Tom P.
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]]
> > > Sent: Wednesday, July 23, 2003 7:59 AM
> > > To: Magnus Westerlund
> > > Cc: Damon Lanphear; [email-masked]; [email-masked]
> > > Subject: Re: [dccp] natural DCCP sender-side API: (was stream 
> > > switching)
> > > 
> > > 
> > > 
> > > Magnus,Damon,
> > > 
> > > let us forget a minute about the exact application,
> > > (because my point is *not* specific to stream switching)
> > > let us instead concentrate on the following problem:
> > > 
> > > you write:
> > > 
> > > "the server can simply switch to a lower bit-rate"
> > > 
> > > This is an indication we are on agreement on one thing:
> > > DCCP is about rate-driven applications.
> > > 
> > > This is why my concern has been from the very start:
> > > how is the sending application (what ever it is)
> > > going to know what rate it must use?
> > > 
> > > The answers you gave so far seem to indicate you are confident
> > > the application can "compute" such a rate based on the 
> > > behavior of a blocking API...
> > > 
> > > (ok, allow me now to *also* put aside my humble opinion that  
> > > trying to achieve that is not a good idea)
> > > 
> > > I advocate that it would be a shame **because the information 
> > > is already available**!
> > > 
> > > Allow me to quote Section 3 of RFC 3448:
> > > 
> > > "   Generally speaking, TFRC's congestion control 
> mechanism works as
> > >    follows:
> > > 
> > >    o  The receiver measures the loss event rate and feeds this
> > >       information back to the sender.
> > > 
> > >    o  The sender also uses these feedback messages to measure the
> > >       round-trip time (RTT).
> > > 
> > >    o  The loss event rate and RTT are then fed into 
> TFRC's throughput
> > >       equation, giving the acceptable transmit rate.
> > > 
> > >    o  The sender then adjusts its transmit rate to match the 
> > > calculated
> > >       rate.
> > > "
> > > 
> > > This seems to imply that a "natural" sender-side API for DCCP 
> > > would explicitely
> > > inform the application ("sender") about this "acceptable 
> > > transmit rate".
> > > 
> > > It also happens to be the *best thing* that can be provided to
> > > an application designed to perform network adaptation.
> > > 
> > > 
> > > regards,
> > > 
> > > Philippe Gentric
> > > Software Architect
> > > Philips MP4Net
> > > [email-masked]
> > > http://www.platform4.philips.com
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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]>
> 

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

---

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

> detecting network congestion, what do we need DCCP for?

My take:

Your paragraph was written from the application's point of view, not that
of the network. DCCP is about implementing congestion control that is
appropriate for the network: in other words, currently, TCP-friendly CC.
This may conflict with application "requirements".

For example:

> It seems to me that these particular
> about what is possible. 

What is possible for the application may not be TCP-friendly or appropriate
for the network (if the app has a minimum rate, for example).

> It also seems that the application can make at
> least as good a decision about what constitutes network congestion. 

The app should make a decision that is TCP-friendly -- in which case you've
got DCCP all over again. You need acks, probably ECN Nonces, ....

We have a congestion control problem, for which we need a congestion
control solution. Avoiding DCCP doesn't avoid the problem.

So we should solve the problem! And I think we can solve it!

Now, it may end up that DCCP is not appropriate, once the congestion
control problem is solved. I'm not against UDP with application-level
congestion control. But CC is a hard problem, which we are trying to solve
for you.

Also:

> The app will need feedback about the playout buffer state, and this is
> largely redundant with the DCCP acks.

The app should be able to extract this information from the DCCP API, so no
app-level acks are necessary.

Eddie

---

From: Mark Handley <[email-masked]>
Date: Thu, 24 Jul 2003 15:46:18 +0100

>detecting network congestion, what do we need DCCP for?

[I'm just dropping back into a discussion I haven't been following, so
forgive me if this duplicates previous discussion]

There seem to be two obvious sorts of apps that might use TFRC:

 - streaming media
 - videotelephony

That isn't to say that there are different apps, but these two typify
two classes of apps.  Both are fine with variable packet rates.  But
streaming media has significantly more playout buffer available.

Streaming media apps can run the codec (or choice of pre-encoded
stream) at approximately constant bitrate, and send at variable
bitrate, using the playout buffer to deal with the temporary
mismatches.  

Videotelephony apps don't have sufficient delay budget to fix things
at the receiver, but they do have the luxury of encoding live, so they
can change the compression parameters on the fly.  They usually don't
have luxury of re-encoding twice though, so if their choice of
quantization parameters gives a rate that is different from what is
expected (because the video content was unpredictable), then they
might be in trouble.  Also, if the TFRC bandwidth envelope changes
unexpectedly, you can be in trouble.

So, why do I say all this?

My assumption is that streaming media apps will normally send at the
TFRC rate.  What they need is sufficient advance warning that the
playout buffer is running low so that they can switch down to a lower
rate.  And if the playout buffer is starting to get rather large, then
they can switch up to a higher rate.  Assuming rate switching is not a
trivial operation, and that the rate can only be switched at certain
re-sync points, then there is some danger that if congestion suddently
gets really bad, then the playout buffer will be exhausted before the
codec can be switched.  My assumption here is that a really good API
would allow the sender to send above the TFRC rate for a period of
time, so long as the rate mismatch isn't too bad.  A factor of two
might be reasonable as an upper bound on the oversending rate.

Videotelephony apps probably can't send at precisely the TFRC rate
without sacrificing delay to an undesirable extent.  This means two
things. First, the app needs to be allowed to send at rates above the
TFRC rate for a period of time (again, bounded to avoid extreme
unfairness).  Second, if the app sends under the TFRC rate for a short
period, it shouldn't lose it's ability to send faster later, so long
as it didn't undersend by too much.  For such apps, the TFRC rate is a
guide rate - the app should be capable of varying around the guide
rate, so long as it stays within reasonable bounds, and so long as the
long-term average is close to the TFRC rate.

Anyway, in both cases, if the kernel strictly enforces the TFRC rate,
app designers will either not use DCCP, or they'll pad their signal
with redundant data so they can operate within a more predictable
codec envelope.  Both are undesirable.

I'm not sure how we best design an API to satisfy this, but I think
it's really important that we do think about how this can be achieved.

The general philosophy that the TFRC rate is a guide-rate to be
followed loosely will probably also apply with TFRC-PS and VoIP, but
we know a lot less about this space.

Cheers,
	Mark