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

From: [email-masked]
Date: Wed, 23 Jul 2003 20:12:18 +0200

Damon, you write:

>I assume that DCCP will pace data
>to the lower layers at the rate required of the associated CCID spec.
>For the application to do this pacing as well would be redundant work.

I am assuming it is a *different job*, they live on different planets,
the DCCP stack cares about "real seconds",
the application cares about "media seconds".

>What I don't quite understand about your position is the role played by
>the application in pacing data.  Do you maintain that the application
>should pace data, or DCCP or both?

Both, but differently?

Streaming means that 1 second of content MUST be sent for
every elapsed "real time" second (at least on the average).
So the application cannot "pace seconds"...
but I am assuming the application job contract
does not say how many bytes one second of media is.

In short I am assuming that the sending application
can change the media data rate in order to
*follow* the network data rate.

For conferencing -the media being encoded in real time-
I assume that the DCCP stack will be used to pilot
the encoder (tell it which rate to produce).

For pre-recorded media delivery the solution is stream switching
(or download! see the other mail)

For live "TV" (very large number of receivers) changing
the rate is either not relevant (e.g. end to end SSM)
or it uses a relay server which folds the issue as being
like pre-recorded media playback -each receiver maintaining
a private server connection- then one should use stream switching,
each stream "flavor" being simultaneously produced by a different encoder.

regards,

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

                                                                                                                                       
                                                   To:   Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                     
                                                   cc:   Magnus Westerlund <[email-masked]>                            
                                                    [email-masked]                                                                      
                                                    [email-masked]                                                                    
               Damon Lanphear                      Subject:    Re: [dccp] natural DCCP sender-side API: (was stream switching)         
               <[email-masked]>                                                                                                     
                                                   Classification:                                                                     
               23/07/2003 19:42                                                                                                        

Philippe,

No one is really taking the position that a DCCP API should not make the
transmission rate available to the application.  This is quite a
straightforward issue. DCCP can easily expose this key piece of
information.

I am more concerned with how an application meets DCCPs transmission
limits (i.e. transmits at the required rate).

Let's put the issue of adaptation aside for a moment and just concern
ourselves with how an application paces data to the network. My view is
that DCCP offers the application both congestion control AND the ability
to manage the transmission schedule.  I assume that DCCP will pace data
to the lower layers at the rate required of the associated CCID spec.
For the application to do this pacing as well would be redundant work.

What I don't quite understand about your position is the role played by
the application in pacing data.  Do you maintain that the application
should pace data, or DCCP or both? That is, is the use of the transmit
rate to the application purely informative of a rate adaptation process,
or of the transmit process as a whole?

On Wed, 2003-07-23 at 04:59, [email-masked] wrote:
> 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
>
--
Damon Lanphear <[email-masked]>

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

---

From: Damon Lanphear <[email-masked]>
Date: 23 Jul 2003 12:38:47 -0700

> the application cares about "media seconds".

I don't share that assumption.  Probably because the domain in which I
work is on-demand and unidirectional live media delivery.  I view the
delivery time line in terms of a rate. That rate is determined by the
attributes of the session: the state of the network, and the state of
the client side buffer. The media time line may shift relative to the
transmission time line.  So my application cares about "media seconds"
only to the extent that it needs that information to know when and how
to adapt. 

> every elapsed "real time" second (at least on the average).

I don't agree with the MUST.  It MAY if the congestion control will
allow it.  Or it may send more if the congestion control, session type
(i.e. on-demand), and buffer state allows. Or it may send less if there
is too much buffer stored up at the client. The application should be
constantly adapting its transmission pattern to meet a broad set of
requirements, that include congestion control.

> *follow* the network data rate.

I agree.  But how closely you want to follow the network rate  is
determined by the application type, and the state of the client buffer.
Oscillating the transmission pattern with congestion control
fluctuations can be a really bad thing for the user.