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

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 23 Jul 2003 10:43:32 -0400

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.

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

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
> 

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

---

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

Tom,

Thank you for providing better structure to our discussion.  This is
precisely what we needed to speak more precisely on these matters!

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

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?

-- 
Damon Lanphear <[email-masked]>

---

From: "Sean Robinson" <[email-masked]>
Date: Wed, 23 Jul 2003 16:22:32 -0700

I agree that Tom's contribution has provided a good basis for this
discussion.  The decision is further complicated by the inclusion of media
composition.  Consider we following media availablity constraints (which can
be applied to each of the named media application, On demand, live and
2-way)

- A single fixed rate media source
- multiple discrete media encodings
- a fully scalable media encoding (such as MPEG-4 FGS)

Now, given that in the second case we could add as many rates as we desire
and that the third case doesn't really exist (no codec is infitely
scalable), we can treat these as the same for the purposes of this
discussion.  We can view this from the application level as a series of
decision points in which the application concludes the best media data to
send at a given moment given the current network conditions.  The design of
the media is obviously a critical factor in the succcess of the application
as some media may work better in some application than others.  It is
assumed that low latency applicaiton will require more frequent decision
points where an on-demand application may require fewer.  We can think of
the media transmitted between these decision points as a media unit.

Here I would like to bring up a point that I feel has been neglected in the
discussion to this point.  That is the perspective of resource efficiency in
the interaction between a user level media application and a kernel level
protocol.  From this perspective the frequency of interaction between the
two sides should be minimized.  Also we would further hope that the need for
user level packet scheduling would also be minimized.

If the 2 above points are agreed to, we can then conclude that in the ideal
case we would want the interaction with the protocol to match as closely as
possible with those media decision points.  In other words, the application
should only have to interact with the dataflow when there is some meaningful
action to be taken.  This seems to me to be the best method for evaluation
of an API semantic.

First, let's take the simple blocking semantic.  The first question we
should ask (which is not specified in the DCCP user manual) is what triggers
that the block has cleared?  If we take the naive assumption that the file
descriptor is cleared for writing after the transmission of each datagram,
then our interaction with the protocol will also be on every datagram (if we
are instantly responsive to the signal).  This is likely more than we would
like in all but the very most scalable solutions.  Keep in mind, however,
that flow control through file descriptors is a well supported concept
throughout different OSes and this is very attractive in the design of a
protocol. Further, if we define parameters for when the desriptor is marked
for writing we can get greater control over its scalability.  It should also
be noted that this mechanism is not really optional, since the prtocol must
support blocking when the pre-netwqork buffer is full.

Now the rate-signalling approach has also been proposed, but it implies a
network-driven scheduling model over a media-driven model.  TFRC will
generate a new throughput claculation once per round trip time and if this
is the frequency at which the rate would be signalled, then we could either
find this to be too frequent or too sparse depending on the underlying
network.  Certainly an agrument could be made, media decision points should
be syncronized with network condition and if this is possible, this is a
more attractive solution.  It is important to note, however, that at a fine
grained level over delivery rate is not that relevant to the delivery
characteristcs, but rather the data size of individual media units.  So, if
TFRC reports 20kbs at a given window, it doesn't necesicearily mean that the
application should choose the 20kbs stream, but should evaluate the data to
be transmitted for available streams at that decision point.

Another option outside of direct feedback would be a polling approach,
whereby the application set interupt timers to evaluate the dataflow at
appropriate points in the application.  This method could work well in
stuations in which the throughput has a low degree of variance, since the
evaluation interval could be tailored to the desired media.  As the variance
increases, the effectiveness of this approach decreases since the data in
the pre-network queue may be delivered faster or slower than expected,
causing an increased number of "wasted" check in which no action is taken.

Another approach could be to tag specific datagrams for signalling on
transmission.  Then DCCP would signal (using some means) when a given
datagram is transmitted.  If one datagram per media unit, then we could get
a notification at every media unit, which is what we want.  The semantics of
defining this within an API could be quite complex, however.

Which brings me to a final important point.  As mentioned in several points,
we must consider the method in which the information is signalled.  Some
OSes have more advanced signalling mechanism than others and the more
digression from standard mechanisms, the less integrated into the OS the
protocol becomes.  This is an extremely imprrtant factor in this discussion
and should not be treated likely.

S
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Damon Lanphear
> Sent: Wednesday, July 23, 2003 10:52 AM
> To: Phelan, Tom
> Cc: [email-masked]'; Magnus Westerlund; [email-masked];
> [email-masked]; Pasco Anderson, Jay
> Subject: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream
> switching)
>
>
> Tom,
>

---

From: "Sean Robinson" <[email-masked]>
Date: Thu, 24 Jul 2003 13:26:55 -0700

S