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

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 24 Jul 2003 21:25:57 -0400

Hi Eddie,

If DCCP conflicts with an application's requirements, then the application
won't use it, whether DCCP is network friendly or not.  Note that I think
that network-friendly reaction to congestion is absolutely one of my
application's requirements (my app is two-way voice).  I hope that I can use
DCCP to get that, but I'm having difficulties making it work.  Not that I've
given up hope, mind you.  I think I've managed to work out reasonable ways
to use DCCP for similar, but not quite identical apps.  And I intend to keep
trying for my app.

I think it's very important for DCCP to know whether it's really useful for
two-way voice or not.  All of the DCCP documents mention it as a primary
target application.  Some people on this list might already know how to make
it work, but I don't yet, and I haven't seen anyone give a credible scheme
for it yet, so I'll keep trying.

Tom P.

> -----Original Message-----
> From: Eddie Kohler [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 5:27 PM
> To: Phelan, Tom
> Cc: 'Damon Lanphear'; [email-masked]'; Magnus 
> Westerlund;
> [email-masked]; [email-masked]; Pasco Anderson, Jay
> Subject: Re: [dccp] natural DCCP sender-side API: (was stream 
> switching)
> 
> 
> 
> > Another thing that concerns me (touched on in the paragraph 
> above) is the
> > disconnect between a transport protocol making rate decisions and an
> > application making rate decisions.  It seems to me that 
> these particular
> > applications are much better equipped to make the rate 
> decisions - they know
> > about what is possible.  It also seems that the application 
> can make at
> > least as good a decision about what constitutes network 
> congestion.  The app
> > will need feedback about the playout buffer state, and this 
> is largely
> > redundant with the DCCP acks.  If the app is making rate 
> decisions and
> > detecting network congestion, what do we need DCCP for?
> 
> My take:
> 
> Your paragraph was written from the application's point of 
> view, not that
> of the network. DCCP is about implementing congestion control that is
> appropriate for the network: in other words, currently, 
> TCP-friendly CC.
> This may conflict with application "requirements".
> 
> 
> For example:
> 
> > It seems to me that these particular
> > applications are much better equipped to make the rate 
> decisions - they know
> > about what is possible. 
> 
> What is possible for the application may not be TCP-friendly 
> or appropriate
> for the network (if the app has a minimum rate, for example).
> 
> > It also seems that the application can make at
> > least as good a decision about what constitutes network congestion. 
> 
> The app should make a decision that is TCP-friendly -- in 
> which case you've
> got DCCP all over again. You need acks, probably ECN Nonces, ....
> 
> 
> We have a congestion control problem, for which we need a congestion
> control solution. Avoiding DCCP doesn't avoid the problem.
> 
> So we should solve the problem! And I think we can solve it!
> 
> 
> Now, it may end up that DCCP is not appropriate, once the congestion
> control problem is solved. I'm not against UDP with application-level
> congestion control. But CC is a hard problem, which we are 
> trying to solve
> for you.
> 
> 
> Also:
> 
> > The app will need feedback about the playout buffer state, 
> and this is
> > largely redundant with the DCCP acks.
> 
> The app should be able to extract this information from the 
> DCCP API, so no
> app-level acks are necessary.
> 
> 
> Eddie
> 

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

---

From: Eddie Kohler <[email-masked]>
Date: Thu, 24 Jul 2003 23:49:34 -0700

Hi Tom,

> won't use it, whether DCCP is network friendly or not. 

Totally agree. And totally agree that we must figure out whether DCCP is
really useful for two-way voice. But, for example, an application with a
requirement "must achieve a minimum bandwidth" would not be appropriate for
DCCP, because it requires non-TCP-friendly congestion control.

Nothing that you have discussed is that far out, but some of it is getting
far out enough that I wanted to make the concern explicit. (For instance,
we've been talking about apps that can transmit only at a discrete set of
rates---unless 0pps was one of those rates, such an app would have a
minimum bandwidth requirement.)

> Note that I think

FYI I really appreciate this discussion!!!

Eddie