On Feb 13, 2007, at 4:56 AM, Baruch Even wrote:
According to claims of Doug Leith the cubic algorithm that is in the
kernel is different from what was proposed and tested. That's an
important issue which is deflected by personal attacks.
It is not the algorithm "untested" -- it is the implementation not
fully tested. This is exactly the reason we are proposing to build a
common, convenient,
accessible testbed equipped with a full set of automated testing
scenarios. This
would be useful to crack out these bugs. There could be a weakness in
an algorithm, but
there is no bug in the algorithm.
My main gripe is that there is a run to make an untested algorithm the
default for all Linux installations. And saying that I should test it
is
not an escape route, if it's untested it shouldn't be made the default
algorithm.
My skimming of the PFLDNet 2007 proceedings showed only the works by
Injong and Doug on Cubic and Injong tested some version on Linux
2.6.13(!) which might noe be the version in the current tree. Doug
shows
some weaknesses of the Cubic algorithm as implemented in Linux.\
That version we tested is patched w/ our implementation of CUBIC. You
can get
the patch from our site so it is a correct implemenation.
The linux implementation is ever evolving and it is
hard to keep track of everything at an instance. So we are using our
own version
for our paper publishing. But we also test existing versions of Linux
implementation.
The version that D. Leith has tested is a version that fixes the
earlier bug.
Note that having bugs in the implementation does not warrant attacks on
the algorithm itself.
Some "weakness" of CUBIC.. please read my rebuttal
on that paper in my website: http://www.csc.ncsu.edu/faculty/rhee/
The slow convergence issue of CUBIC has been inherent
feature of CUBIC -- that is a design tradeoff we make when we design
BIC and CUBIC. Depending on the testing environment, CUBIC has
very fast convergence, but only in a very low statistical multiplexing
environment,
the conversion is slow. WE HAVE ADMITTED THAT SIN.
So he did not exactly FIND that problem. Also on the
other issues he just raised..just please read that rebuttal.
I am just sick and tired of hearing all these nonsenses that people
spray based on some
incidental observation on the behavior of protocols without proper
comparison
and reasoning why a protocol could behave in that environment being
tested.
Do you still think that making Cubic the default is a good idea?
Do you think H-TCP could make a good candidate? I remember there are
bugs in
H-TCP implementation (which went on unnoticed for a long time) -- Leith
claims
his team found the bugs -- but it seems a little of coincidence that
after we post
our report on a strange behavior on H-TCP, D. Leith came back saying
they
found the bugs (no attribution..hmm). We also found some problem
in the weakness of H-TCP algorithm
(not implementation) as well (please read our Convex ordering
paper in PFLDnet07). Based on the same argument of yours, then H-TCP
does not make the cut. I guess none of TCP protocols would have made
the cut
either.
Baruch
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
