Well, TFRC is only one of DCCP WG's four chartered areas.
DCCP implementation and deployment experience seems to show that rate-based
protocols are simply harder to implement than ack-paced protocols. There are
a lot of good implementation reasons for this. As a result, TFRC isn't a
convincing algorithmic success, and praying for its deployment is weird. You
shouldn't want TFRC, which is a means to an end. What end? Unreliable
congestion control?
DCCP is a mechanism for experimenting with TFRC and with potential
alternatives -- different AIMD parameters, etc.
I don't think I'll respond to another of your emails, however.
Eddie
On 3/5/11 4:20 AM, L.Wood@xxxxxxxxxxxx wrote:
The point of asking the question? It's an economics argument, using terms from that discipline - the recognition of "opportunity cost"; that continued effort spent on e.g. improving DCCP specifications or doing DCCP-over-UDP could be going elsewhere to greater benefit and effect.
Lots of important work was done on e.g. ATM adaptation layers or on the ISO OSI model. (Or on Adobe Flash.) But that doesn't mean that those "sunk costs" (the time and effort spent on the important work already done) have to continue to be maintained by further development if the benefits aren't there.
Do the "prospective benefits" of a protocol that can't be deployed outweigh the "sunk costs"? Or is the problem of applications sending traffic without considering congestion control better solved by e.g. 'here's an open-source library that runs directly over UDP for your UDP-using application to implement its own endpoint congestion control'?
Insofar as DCCP tests TFRC algorithms and acts as an example, it has some useful role for experimentation (rather than standards track) -- but wider deployment of TFRC, in whatever form, is what matters, while widespread DCCP deployment for applications to rely on appears to me to be a lost cause even with the kludging to make DCCP run over UDP.
It's an algorithm deployment issue, not a protocol deployment issue. The goal is widespread TFRC use, and widespread DCCP deployment to get to widespread TFRC use is unlikely to happen. How best to get widespread adoption of TFRC itself?
Lloyd Wood
L.Wood@xxxxxxxxxxxx
http://sat-net.com/L.Wood/
-----Original Message-----
From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On
Behalf Of Michael Welzl
Sent: 05 March 2011 09:48
To: 'dccp' working group
Subject: Re: AD review: draft-ietf-dccp-tfrc-rtt-option-03
constructive: when, or *at least* after developing a
protocol, think about deployment: why would people use it,
how can we get them to use it, how can we make it easier for
the protocol to pass through middle- boxes etc?
destructive: when the perhaps most important work is done -
thinking about actual deployment - call it a futile effort already.
i wonder, what's the point of being destructive?
michael
