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
