[Iccrg] Re: [dccp] evaluation of MulTFRC

[Pasi Sarolahti]

Thanks, Wes, for the good review! This was very helpful.

- Pasi


On Jan 19, 2010, at 12:02 PM, Eddy, Wesley M. (GRC-MS00)[ASRC  
AEROSPACE CORP] wrote:

> 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
>
>