Re: [Cake] Running Cake at long RTTs

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Jonathan Morton <chromatix99@gmail.com> writes:

> The first change implies that the 10K packets * MTU default (ie. 15MB)
> isn’t big enough, but the 50MB calculated by 4 * RTT * rate is. That’s
> a fairly narrow range, which suggests that the latter calculation is
> correct.
>
> However, have you tried it with just the second change and not the first?
> Conventional wisdom suggests that 15MB (which is slightly more than one BDP)
> should be about the right size for a buffer under these conditions. I don’t want
> to gain a false impression of what the minimum usable buffer size is.

Well, indirectly: The first change was actually to address the problem
that Cake with CoDel turned off (i.e. interval 300s) did not achieve
full throughput. Changing the buffer size fixed that. Guess I can go
back and revert that and try again; will do so tomorrow.

> Limiting it to 10K * MTU was a safety valve to avoid the buffer size
> exploding. With the first change in place, the “interplanetary”
> setting effectively removes any limit on buffer size as well. This
> makes me deeply uncomfortable. Instead, we should arrange to configure
> the safety-valve limit when accommodating LFNs.

I agree that some sort of safety valve is probably needed (as is a
minimum; but that's another matter). Perhaps just setting the limit
higher could be a pragmatic solution?

> The result from the second change is more clearly beneficial, but I’ll
> put it in userspace (ie. tc) rather than in the kernel.

I'm not sure I agree with that. Putting it in userspace means basically
exposing the target. Even if it's not recognised in iproute, it will be
exposed in the netlink API, which sooner or later some other tool is
going to speak. We will then risk ending up in a situation where the
target is set arbitrarily, leading to a need to print out what it
actually is; which in turn brings us back to having exposed target
completely.

Now, I'm not ruling out that exposing target may eventually be the right
thing to do. However, I do like the simplicity of having only the one
parameter; so if we can avoid it I think we should. I guess more
experimentation is needed to answer this.

> I think the patch as given has some unintended consequences. Scaling
> target with interval also means I have to take more care with the
> threshold calculation, since the threshold scales with the product of
> the two.

That is most probably true. :)

-Toke