[Cake] New to cake. Some questions

[moeller0]

Hi Jonathan,


> On Jun 10, 2016, at 00:17 , Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> On 10 Jun, 2016, at 00:36, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
>> 
>>> 5. Is there still the udp packet dropping problem? e.g. games that are using udp.
>>> If yes does it make sense to apply diffserv classes manually? How to do this?
> 
>> What udp packet problem?
> 
> He’s probably referring to the tendency of non-flow-isolating AQMs to drop packets indiscriminately when under load.
> 
> Cake is flow-isolating and thus applies a separate AQM algorithm to each flow.  As such, UDP gaming/VoIP traffic won’t get dropped unless it exceeds its fair share of the link, which is unlikely for a well-designed, lightweight protocol.
> 
> We really should make an effort to put a more intuitive GUI interface on this.  These questions indicate a v.

	Let me be frank to the level of impoliteness, let’s tests things first and once they work as described in the mostly missing documentation then let’s work on a GUI (a GUI is the wrong place to fix up a bad CLI interface for instance). I am sorry that I have to be so blunt, but I fear due to me not being a native english speaker, we will not be able to unambiguously communicate.

So here is my top five list of cake related topics that I would appreciate if you could address them:

1) the isolation options:
	Does triple-isolate really work, and what is the theoretical prediction how it should exactly work? 
		The last test indicates we might have problems there
	Do the dual isolation options work as intended, and what exactly is intended? 
		Recent tests indicate they might work, but they are nasty to set up for users, due to the NAT issue.
	How much additional CPU load do these options cause, or what is the computational cost expressed in lost bandwidth or additionally gained latency under load?

	We are currently trying to distribute a few test scripts to openwrt volunters to help answer these question, but before they are answered I vote to not further exposing anything isolation related in the sqm-scripts GUI. We (well at least I do) plan to use the results of these tests to decide whether to change the defaults for cake under sqm-scripts. But even if the tests work out we need the man page to describe reasonably well what tho expect, so users can decide about the applicability of the isolation option based on there needs.

2) auto-rate:
	The same recent test indicated that auto-rate might not work well on a fixed rate link. This is somewhat unexpected as a fixed rate can be easily seen as a corner-case for a variable rate. I would vote for researching why this is, and anyway documenting the suitability for variable or fixed rate links more prominently so our users can make informed policy choices for their home networks.

3) the dreaded encapsulation keywords
	Please address the issues I raised in too many mails this months… which boil down to questions of scope “why are the vdsl options suffixed with _ptm, but the atm options are not?” and of minimality “is the currently selected set of keywords minimal and complete?” and transparene “will a user of a compund keyword be easily able to predict all side effects?” and confusion “why name something conservative that will for all peop;e not using an ATM link cost between 9 to 40% of goodput?”. Since all of this is a question for tc and not so much core cake, things should be relatively quick to sort out, but they should be sorted out before distributing cake wider/ or exposing the currently marginally consistent state to more users. As if we expose to much it becomes API and immutable…

4) documantation:
	I fully agree with your conclusion that a “user overwhelmed by many options without guidance”. So please write/improve the “missing” man page and description of algorithms already. Given that you designed all the core of cake you are the best qualified person to do this.

5) development focus/sequence:
	My understanding is that cake currently contains a fair number of interesting and relevant functions that our users certainly want and will appreciate. Unfortunately, some of those do not seem to be adequately documented (see 4) and some might actually be not ready for primetime (that requires further coformatory testing that I am willing and in the process of helping with). I would be really happy if you could give a tentative development priority list, so that we can harmonize testing features with your development, so that the testing actually helps you in your process.

But please do not drag in GUI before cake and tc are fully “baked”.


Best Regards
	Sebastian


> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake