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

From: [email-masked]
Date: Thu, 24 Jul 2003 20:03:36 +0200

Hi Mark,

>My assumption is that streaming media apps will normally send at the
>TFRC rate.

Could it be "at a rate equal or inferior to the TFRC rate"?

What will happen if an application "does not use" the
bandwidth indicated by TFRC?

Often there will be no other choice,
for example if my application can do 200 kb/s and 400 kb/s
and TFRC indicates 380 kb/s then I must still use the media
at 200 kb/s and SEND it at 200 kb/s because if I try
to send my 200 kb/s media at 380 kb/s I will simply explode
the player buffers very rapidly?

>What they need is sufficient advance warning that the
>playout buffer is running low so that they can switch down to a lower
>rate.

yes on advance warning about the TFRC rate,
but I see the need for the sender to monitor
the playout buffer as unnecessary complexity:

I think that if the application *generates* (and sends) data at
(or below) the TFRC rate then data will arrive on time
and the playout buffer will always remain stable?

>And if the playout buffer is starting to get rather large, then
>they can switch up to a higher rate.

you are assuming that the application sends data
at a data rate larger than the media data rate...

then yes! if you play with this fire you will
need to monitor the player side buffers very carefully!

The only advantage I can see with that trick
is that *if you are lucky* during the first minutes of streaming
you can play this trick to build up your player-side buffer
using the positive gaps between the TFRC rate and the highest available
media rate smaller than the TFRC rate; which means that playback can be started
with minimal lead time i.e. it shortens the time the user waits between the streaming
request and movie starts to play...unfortunately if you are unlucky
you will underflow...

do you seen any other advantage?

anyway it is a more complicated solution.

I would simply stream at the first available
media rate smaller than the TFRC 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.

Let us compare:

if you switch "in a hurry" it maybe that the result
for the end user does not look very good,
however the alternative (keep on sending at the same rate)
is not very attractive either for the end user,
since the player will drain its buffers anyway.

the difference is that it is worse for the network!

>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.

I though if you wanted to do that you would declare it as a new
rate control policy (since it is one, no?) i.e. give it another CCID ?

What would be the point of defining TFRC and then "cheat on it" ?

How would you define "TFRC conformance" then?

>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.

Do you mean send garbage?
what kind of gain would that bring ?
what is a predictable codec envelope?

regards,

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

                                                                                                                                       
                                                   To:   "Phelan, Tom" <[email-masked]>                                          
                                                   cc:   "'Damon Lanphear'" <[email-masked]>                                        
                                                    Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                          
                                                    Magnus Westerlund <[email-masked]>                                 
               Mark Handley                         [email-masked]                                                                      
               <[email-masked]>             [email-masked]                                                                    
                                                    "Pasco Anderson, Jay" <[email-masked]>                                    
               Sent by:                            Subject:    Re: [dccp] natural DCCP sender-side API: (was stream switching)         
               [email-masked]                                                                                                        
                                                   Classification:                                                                     
               24/07/2003 16:46                                                                                                        

>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?

[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

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

---

From: Damon Lanphear <[email-masked]>
Date: 24 Jul 2003 12:15:59 -0700

> yes on advance warning about the TFRC rate,

How can you ever get an advance warning about TFRC rate changes.  These
changes are response to immediate stimuli, to my knowledge that are not
predicted by the current suite of algorithms.

> and the playout buffer will always remain stable?

so you are assuming that the application is generating the data on the
fly.  This is a very different scenario that certain other streaming
media applications.  So, again, the streaming model that one applies is
tied directly to the sort of application. 

You need to monitor the playout buffer in some way for applications that
can not adapt closely to the congestion controlled rate. Since there may
be other, more coarse grained, adaptations you can make to maintain the
continuity of playout.

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

---

From: Mark Handley <[email-masked]>
Date: Thu, 24 Jul 2003 23:01:06 +0100

>bandwidth indicated by TFRC?

OK, my assumption here was that streaming media was coming from disk.
Thus you can always send faster then the receiver is consuming.  This
isn't always true - live broadcast fits in the spectrum between
streaming media and teleconferencing.  But you can do your own
extrapolation - my high level point that the for many apps the TFRC
rate should be treated as a reference rate rather than an absolute
mandate is still the case.

>What would be the point of defining TFRC and then "cheat on it" ?

You have to understand that TFRC is only an approximation.  It
"cheats" on TCP on short timescales.  And at high loss rates, even
different TCP implementations aren't very fair to each other. If the
apps "cheat" on TFRC on shortish timescales, but in such a way that it
generally averages out in the end, then this is very similar to what
TFCR is doing anyway relative to TCP.  Our goals for TFRC were that it
was within a factor of two of TCP's average rate on medium timescales.
Thus it doesn't make sense to argue about an app being (say) 10% over
the TFRC rate on short timescales - the app's constraints are more
important than a small factor of fairness in rate.  What matters is
that no-one loses badly (from a fairness point of view) and that the
goodput through the bottleneck is close to 100% (so we don't want to
encourage unnecessary padding to keep the app's rate up to the TFRC
rate).

Cheers,
	Mark