Re: [Cake] second system syndrome

[moeller0 <moeller0@gmx.de>]

Hi Jonathan,


> On Dec 21, 2015, at 16:36 , Jonathan Morton <chromatix99@gmail.com> wrote:\
[...]
> The “dual flow isolation”, which after a great deal of thought I’ve decided to rename “triple flow isolation” (for reasons that will become clear later), is within scope because it improves the flow-isolation feature.  If and when I can get my head around all the little changes that keep (potentially) breaking everything behind my back, I’ll be able to actually implement it some day.

	From supporting users on the openwrt forums I know that an easy way to compartmentalize bitttorrent traffic would find lots of users. And if in an initial implementation a host with too many flows suffers increasing delay under load, that might not be too bad, given that bitterness can use this added delay to throttle itself back. It is not about perfect here, just about good enough.

[...]
> 
> The most difficult function to define and scope has been the priority queue, due in no small part to the hilariously weak specification that is Diffserv.  I have tried to carve a fresh path of clarity here, interpreting the existing specifications into a coherent implementation in the hope that it’ll actually get used as such in future.

	I would argue differently, instead of trying to make lemonade why not collect the few actual constraints (probably 0=BE, 1=BK and XX=EF should be sufficient to account for al actual marking encountered in a typical home) and come up with something simple that will just work? Simplicity wise I believe the classic precedence 3-bit patterns are simple enough, but they fail; the CS1=BK test...

> 
> In that context, the “squash” and “wash” features truly baffle me.  I’d prefer to see them both gone.  Either you want to *use* Diffserv, in which case downstream networks might also benefit from the same markings, or you want to *ignore* it, in which case you might as well leave the existing marks alone, or you want to do something more sophisticated that Cake’s core feature set doesn’t support.

	A home router is a typical DSCP-domain, so clearing internally valid marks on network egress seems quite prudent, no?  Also it seems not a bad idea to use DSCP at home to push bitterness in the BK without giving an ISP a convenient marker to drop packets, but since I rarely use bitterness I am making this argument up...

> 
> In short, Cake is *not* the right place to change the DSCP field.  A separate qdisc could be written to do that job with minimal overhead and a dedicated configuration interface, and be inserted either before or after Cake as required.  Or we could wait for pre-ingress-qdisc firewall rules to become available.

	Both of these are decidedly not-easy, and as far as I am concerned cake’s reason to be is to make commonly wanted but due to the involved complexity rarely configured home-network setups easy. So if cake would offer this we can make non experts use it, which I would count as a win...

> 
> The AQM layer is also apparently a source of controversy.  Codel is really, *really* good at dealing with single, well-behaved TCP flows in the congestion-avoidance phase.  It’s also really, *really* bad at dealing with unresponsive UDP flows, and somewhat mediocre at dealing with TCP in slow-start or multiple TCP flows in the same queue.  This is a problem that we need to address, one way or another - whether by modifying Codel or finding some way to switch between two or more different AQM schemes based on traffic characteristics.  In the meantime, we have to experiment.

	The beauty of fq, as I understand, is, given enough flows, the misbehaving flows will mainly help themselves to a healthy portion of delay before the dropper ramps up, no?

Best Regards
	Sebastian

> 
> I am happy to see optimisations go in, as long as they’re clearly beneficial, don’t change the logic, and don't preclude changes to areas that are not entirely settled.  For anything else, please make it a separate branch with a pull request, so that I don’t have to be distracted by reverting stuff that doesn’t work.
> 
> - Jonathan Morton
>