Re: [Cake] second system syndrome

[Jonathan Morton <chromatix99@gmail.com>]

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

True, and that’s why I’ve been trying to keep flow-isolation work at the front of my queue, at least as far as Cake is concerned.  But I don’t want to be taking steps backwards.  Since I’ve got a theoretical handle on what appears to be the *correct* solution, I don’t want to spend any time working on anything that’s obviously wrong.

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

I might try to revisit the DSCP-to-tin allocations later on.  There are several competing specifications of such allocations in the wild, and I might do better to align Cake with one of the more promising ones.  I’m also fairly keen to have a distinct “network control” class right at the top of the stack, which might result in five tins rather than four.

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

No.  That would be true only if you used “local use” or “experimental” DSCPs (or some other mapping incompatible with the published specifications) in your network.  Cake doesn’t understand those uses, so you should be doing your DSCP re-marking before traffic reaches Cake, if at all.

The DSCPs that Cake understands are those in the RFCs, which can be presumed to be widely understood (if not always widely used).  In particular, they’re consistent with other Cake users and the most obvious interpretation of the PHB specs.

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

If your ISP drops traffic based solely on the DSCP, you have bigger problems.

If your ISP drops BK traffic preferentially during congested periods, however, then they’re more-or-less doing the right thing.  Assuming they’re not permanently congested, that is.

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

In my book, non-experts should definitely *not* be using the “wash” feature.

Early re-marking of DSCP would however be useful on ingress, to deal with the plethora of networks out there which either fail to set appropriate DSCPs at origin, or re-mark them inappropriately en route.  In particular, it would be useful for ingress classification of BitTorrent traffic, since the user has a better chance of identifying this traffic by port number than the ISP does.

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

Yes, that’s true to the extent that I’m putting improved flow isolation above tuning AQM in my todo list.  Good flow isolation means that, in theory, AQM only needs to act to provide courtesy signals to responsive flows - which is exactly what Codel is good at.

However, if AQM can also act to keep unresponsive flows under control, that relieves the overflow handling logic from having to do that job full-time.  Although I did optimise that logic somewhat some time ago, it isn’t as slick or efficient as AQM could be in this role.  The difference between theory and practice...

 - Jonathan Morton