[Cake] Running Cake at long RTTs

[Sebastian Moeller]

Hi Toke, hi Jonathan,

On Oct 28, 2015, at 00:57 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:

> Jonathan Morton <chromatix99 at 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?

	Might I propose again to actually expose the hard maximal limit somehow to user space? Both 15MB as well as well as 50MB will wreck havoc on my poor 64MB wndr3700v2. I believe other qdiscs allow to control the maximum buffering (at least approximately, since a buffer limit in packets will ignore all the sib overhead that seems relevant; ideally I would like cake to honor what ever hard limit the user set).

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

	I believe it already is exposed, so if this is unwanted we should change this back before upstreaming?

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

	If I might repeat my opinion here, let’s expose it, it is one thing to be pro-active and have well working defaults that do not need manual intervention, but it is a totally different thing saying “trust me I know what is best for you”.

> 
> 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 would argue that cake should do what we consider to be ideal by default without user intervention, and if the user starts specifying things it should honor them (still using its heuristics for the parameters not explicitly specified), though cake might complain to syslog that it thinks the user requested something silly. It is fine to reject the impossible ;). The advantage of exposed knobs is that it allows experimentation without recompilation from source...

Best Regards
	Sebastian

> 
>> 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
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake