WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> 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.)
> 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!
> On 3/5/11 4:20 AM, L.Wood@... 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@... >> http://sat-net.com/L.Wood/ >>
>>> -----Original Message-----
>>> From: dccp-bounces@... [mailto:dccp-bounces@...] 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?