On 5 Mar 2011, at 15:30, Eddie Kohler wrote: > Well, TFRC is only one of DCCP WG's four chartered areas.
but it's the only one that doesn't treat DCCP as an (increasingly internally focused, imo) end in itself. > DCCP implementation and deployment experience seems to show that rate-based > protocols are simply harder to implement than ack-paced protocols. But that experience has also shown that newly-assigned protocol numbers are rather limited on the public Internet. (SCTP has the same problem, despite being rather older - but SCTP has history and installed base outside the public NATted Internet.) > You > shouldn't want TFRC, which is a means to an end. What end? Unreliable > congestion control? Indeed, because congestion control and avoiding congestion collapse (but without massive reengineering of the underlying network) remains a significant concern. Well, a significant concern of the IESG. > DCCP is a mechanism for experimenting with TFRC and with potential > alternatives -- different AIMD parameters, etc. That we agree on. > I don't think I'll respond to another of your emails, however. Oh no! he's killfiled Larry! > Eddie > > > On 3/5/11 4:20 AM, [email protected] 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 >> [email protected] >> http://sat-net.com/L.Wood/ >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] 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 Lloyd Wood [email protected] http://sat-net.com/L.Wood
