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

From: [email-masked]
Date: Wed, 23 Jul 2003 19:43:04 +0200

Hi Tom,

you write:

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

and then latter (still about recorded media):

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

1) I am sorry but *from a network point of view*
I dont see a difference between this and "download"?

Except that to my knowledge all the products doing that use HTTP
since it solves a rather large number of other problems at the same time!

2) Now *from a user point of view*

"download" has a flavor usually called "progressive download"
whereby the downloaded media file has a structure enabling
to start playback before download is finished.

In this mode usually the slide bar that the player
uses to display the media time has 2 colors,
one displaying the current time in the media,
the other the *received* time in the media,
if this second mark stays ahead of the first mark playback is un-interrupted,
otherwise the player stops and displays a message such as "please wait, rebufferring".

So I dont see either, from a user point of view,
how different a behavior the case you describe would have?

****************

I conclude about this use case of the DCCP blocking API you described,
that it is not very attractive at all.

Surely DCCP has better assets to lure implementers?-)...
I think an API providing a target rate would be a good starting point;-)

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 12:42:55 -0700

> I dont see a difference between this and "download"?

The only substantive difference is that the transmitted data may not be
stored statically on the device in the case of streaming.  So if you
have a small embedded device, with limited storage, you can experience
media from the network without having the cache the whole thing on the
device. The problem then becomes one of balancing the use of device
storage (i.e. client buffer management) and congestion control.

> 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: Eddie Kohler <[email-masked]>
Date: Thu, 24 Jul 2003 14:08:28 -0700

> I think an API providing a target rate would be a good starting point;-)

It's been mentioned a couple times deep in emails, but just to make it
explicit:

We absolutely expect APIs to provide the current congestion control state
to applications. This includes, but is not limited to, the maximum allowed
rate.

Eddie