Subject: [MMUSIC] Re: [dccp] what is DCCP for? (was: natural DCCP sender-side API)

From: [email-masked]
Date: Fri, 25 Jul 2003 14:43:56 +0200

Damon,

you write:

> ?!? How does DCCP guarantee on time delivery?

(let me first check something, I define "on time delivery" as:
the amount of time its takes for data to transit
from sender to receiver is constant. do you agree?)

My understanding of DCCP is that it would tell the sender at which max rate to send.

Then I assume that *if the sender does its part of the job*,
(which is to abide by the max rate indicated by DCCP)
then the system (application + DCCP) will run "in the best possible way"
...
which is: *avoid congestion*
(if DCCP does not do that, please change the name!-)
...
which means on time delivery of data!

so I conclude that DCCP "allows" on time delivery, right?

**

the reason one could go from "allow" to "guarantee" would be (king of ad absurdum):

I have been assuming (this is the "contract" I would wish DCCP to operate under)
that when DCCP gives the sending rate indication it does so based on
the *best possible knowledge about the network*.

Therefore I would like to be able to assume that if the network "behavior"
is such that even DCCP cannot fulfill the "contract" then *nothing* would do the job.

In other words I am assuming that if an application strictly doing its job
(strictly respecting the MAX send rate indicated by DCCP)
does not get on time delivery ... then the application would "fail" in any case.
(my definition of "fail" for streaming is: playback is interrupted)

Am I putting irrealistic hopes in DCCP?

but then what would it be good for?

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: Eddie Kohler <[email-masked]>
Date: Fri, 25 Jul 2003 08:09:04 -0700

Phillipe

> which means on time delivery of data!

DCCP traffic is still best effort traffic. Best effort traffic must expect
loss. That's the only way the network can signal congestion currently.
(DCCP will then avoid congestion *collapse* by backing off its send rate.)
Furthermore, there may be variable delay, depending on the network. There
is no magic "do not drop or delay my packets" button in the Internet today.

Except that when ECN is deployed in routers, DCCP packets will get marked
when UDP packets would get dropped.

> Am I putting irrealistic hopes in DCCP?

Yes. DCCP cannot predict congestion in the network. It sounds like you want
intserv (a guaranteed bandwidth reservation).

You can get some of what you want, in that DCCP will tell the app the best
rate it is currently allowing, and if that's not good enough, your app can
quit.

Eddie