[Iccrg] Answer to MulTFRC reviews

[Michael Welzl]

Hi,

First of all, I would like to deeply thank the reviewers
for their efforts. It is extra cool that they all ended up
sending their comments at almost exactly the same
time, this makes things quite efficient  :-)

Since the comments overlap quite a bit, I'll try to answer
them all with a single email and hope that the review
authors agree that their concerns are amply represented
here.


Concern #1: "The equation doesn't look very intuitive / is quite  
complex"
(Wes, Dirceu)

This is very hard to address. The derivation is quite
straightforward, but the outcome just doesn't look
intuitive; we'll do our best to address this, e.g. by
providing some basic hints about how the derivation
works.

This is maybe connected to:


Concern #2: "The draft does not state which reference describes
the derivation"
(Lachlan, Dirceu)

This is easy to fix, and we'll do that (that reference is [Dam+08]).


Concern #3: "It will be hard to ensure that this is correctly
implemented, e.g. there may be issues with fixed-point math"
(Wes, Lachlan, Dirceu)

About implementation problems resulting from the complexity
of the equation, our suggestion is to provide more hints in
the draft - e.g. we could add a table with input / output values
that correct implementations should yield, for easier testing.

About the fixed-point math issue, Dirceu mentioned "how to
work around the lack of floating point operations in Linux Kernel,
for instance", and Lachlan provided more details about the
equation calculation, saying that some operations ideally cancel
each other out but "may cause overflow when implemented in
fixed-point arithmetic, as done in kernels".

We believe that this concern is very valid, but the problem
surely can be solved. We will develop an explanation on
how to implement the equation with fixed-point arithmetic,
making use of the helpful hints provided by Lachlan (e.g.
we'll reconsider the sequence of operations).


Concern #4:

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.
(Lachlan)

I would like to work out a solution for the small-BDP vs. large-BDP path
concern, but for this, I would need some more details about your
statement that "TCP is (too?) aggressive on small-BDP-paths".
Could you elaborate, maybe with a reference to a study showing
that TCP is too aggressive on small-BDP paths, and what exactly
you mean by "small"?

About the arms race concern: one way to work against this
is to have a uniform system-wide non-user-accessible
upper limit, which we recommend to have.

One could argue that the value of this system-wide upper
limit could itself be a part of the arms race, no matter
what the specification recommends. However, we believe
this to be unlikely. As we state in the draft:
"Thus, setting N to a much larger value than the values
mentioned above will only yield a marginal benefit in
isolation but can significantly affect other traffic."


Concern #5: "The abstract has a rather weak motivation and should
be strengthened"
(Dirceu)

We'll do that.


Concern #6: "it's important to get an idea of the range of
rates produced by the equation"
(Dirceu)

We'll address that.


A big thanks again to all 3 of you!

Any comments are more than welcome. At this point, my
major concern is whether there is enough interest - so, for
those of you subscribed to the DCCP list, raise your voice
there, let us know whether you think if MulTFRC should
be a WG item or not. Thanks!

Cheers,
Michael