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.w...@surrey.ac.uk 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.w...@surrey.ac.uk
http://sat-net.com/L.Wood/
-----Original Message-----
From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On
Behalf Of Michael Welzl
Sent: 05 March 2011 09:48
To: 'dccp' working group
Subject: Re: [dccp] 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
