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

From: [email-masked]
Date: Wed, 23 Jul 2003 13:59:17 +0200

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

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

---

From: Damon Lanphear <[email-masked]>
Date: 23 Jul 2003 10:42:08 -0700

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?

-- 
Damon Lanphear <[email-masked]>

---

From: Kamlesh Talreja <[email-masked]>
Date: Wed, 23 Jul 2003 12:32:05 -0700

Without discounting the need to convey the transmission rate available to 
the application, we also need to
point out the immediacy of a socket block, as opposed to an intermittent 
reading of the transmission rate.
Since the transmission rate would be changing at a much finer granularity, 
and the congestion control
mechanism would make sure the application does not exceed. If the 
application intends to exactly track
the transmission rate changes, it would end up spending too much time as 
part of an out-of-band
notification process. A blocking API allows the application to pace its 
delivery in an integrated manner
without the overhead of asynchronous callbacks or other mechanisms to 
notify it continuously of
transmission rate changes.
However, to prevent the kind of oscillatory behavior that Tom talked about, 
the application could read the
available transmission rate at a much less frequency to make sure that the 
media rate does not exceed the available
throughput over a longer period of time.
Kamlesh

> > http://www.platform4.philips.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Kamlesh T. Talreja                     E-mail: [email-masked]
  Software Development Engineer          Phone:  206-892-6193
  HelixServer Product Development
  RealNetworks, Inc.                     http://www.real.com/