(forwarded on behalf of Lachlan who's not subscribed
to DCCP)
---------- Forwarded message ----------
From: Lachlan Andrew <lachlan.andrew@xxxxxxxxx>
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@xxxxxxxx
>
Date: Wed, 20 Jan 2010 13:02:13 +1100
Subject: Re: [Iccrg] evaluation of MulTFRC
2010/1/20 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
<wesley.m.eddy@xxxxxxxx>:
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.
Thanks, Wes. My review (also my opinions, not ICCRG consensus) is
below.
My technical concerns with MulTFRC are:
- The formula for the rate is quite complex. This makes it likely for
implementation errors. It also makes it hard to check for complete
safety. This is especially so since the draft does not specify which
reference describes the derivation.
- The formula has many operations which ideally cancel each other out,
but may cause overflow when implemented in fixed-point arithmetic, as
done in kernels. In particular, in congestions, 1-p may be small,
and so having it in the denominator of z is likely to cause
overflow. Since z is then multiplied by (1-p) anyway, it seems
sensible to do the division instead in the second re-calculation of
q. At the very least, there should be some discussion of how the
specified sequence of operations is more robust to overflow than
alternatives.
- MulTFRC, like MulTCP, simply seems to increase (or decrease) the
aggressiveness, without regard for how large or small the BDP is.
Since TCP is (too?)aggressive on small-BDP paths, but not aggressive
enough on large-BDP paths, it is not clear that a "safe" setting of N
will be useful. I think even extremely aggressive algorithms are
unlikely to cause congestion collapse in the Internet, and so from
that point of view, MulTFRC is "safe". However, if the
user/application can set N, then it could easily become part of the
"Linux beats Microsoft" arms race Michael described at PFLDnet.
To clarify the point Wes mentioned about rate based vs window based, I
don't think that rate based algorithms inherently cause more problems.
However, in my limited experience, they are more susceptible to
errors in assumptions about the network, and so we need to be
particularly careful.
However, if the second point above is eventually addressed, I think
that the algorithm is sufficiently "safe" than the DCCP wg can go
ahead and assess it on its merits as a congestion control algorithm.
Cheers,
Lachlan
--
Lachlan Andrew Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan
>
Ph +61 3 9214 4837
--
Lachlan Andrew Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan
>
Ph +61 3 9214 4837
