In response to the interest in possibly specifying MulTFRC as a mechanism for DCCP, and the call for reviews in the ICCRG, I've looked at the available material. This is my personal review, and not an ICCRG consensus. I know at least Lachlan has also been looking at this, and may have come to a different conclusion. I think there's no reason to block this if there's momentum to do the work in DCCP. While there are definitely some concerns with the goal and approach, it seems to me that they aren't likely to cause any serious damage to the Internet. It's certainly not as dangerous as things people have done in the past, which the Internet survived :). That's the executive summary, some more detailed listing of thoughts is below. Chatting with Lachlan helped to formulate some of these positions of mine (in response to points he made), but I think he should probably post his own thoughts separately as he may not agree with my overall feelings. One concern is that this is equation-based rather than window-based, and thus will not back-off as quickly as TCP under loss. However, if it works correctly, then it will respond as TFRC flows do, and TFRC has been around for a while without disaster, so this doesn't really worry me. A related concern that came to light when I was discussing this with Lachlan is that there may be difficulties with fixed-point math in implementation, leading to errors or border cases that may be hard to ferret out in testing. This is probably a concern that applies to many/most advanced congestion control techniques, however, so I don't see it as a reason to throw a "danger" flag, personally. The issues around this may be one thing we can learn more about as a community from pursuing this. Another concern is that the equations involved with MulTFRC and their derivation, seem much more complex than for TFRC. Granted, I'm not a mathematician, but TFRC equations are at least somewhat intuitive, whereas MulTFRC doesn't seem to be as easily comprehensible to me, even though the basic premise is simple. However, I think that it's been reasonably-well documented and validated in the TR: http://heim.ifi.uio.no/michawe/research/publications/dragana_tech_rep.pdf and that the most productive way to discover if there are any flaws is to pursue further work, such as in DCCP. Overall, while I think there's probably a high risk of something being "not quite right" in an implementation, I also think the impact of that upon the Internet will be negligible. A major factor in this is that for it to cause trouble would likely require fairly wide penetration of DCCP and conscious application choice to use MulTFRC ... Yes, this could happen overnight in "Internet time" with the way that code is deployed to desktops these days. But, even if this happened AND something went horribly wrong, we would at least gain some cultural knowledge of how careful we really need to be (or not) with either equation-based mechanisms or mechanisms with complex derivations, and whether bugs are derived from implementation or specification. For reference, the original solicitation for review is: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2009-November/000716.html which also has pointers to some of the primary material. -- Wes Eddy MTI Systems
