Jonathon-

I think you meant to say “method/algorithm for limiting the depth of a given queue” rather than “CoDel”. 8-).

As we have been discussing, driving the queue management implementation towards a given specific algorithm is fraught with danger. For instance, some deployment models simply can’t do work at de-queue time. Specifying a specific algorithm that does work at de-queue time will be counterproductive.

Other than that nit, I think your statement is on track…… I would add in a classifier to get packets into the correct QOS bucket, and perhaps a few additional modules. In some deployments, one or more of those modules may be NULL – but that is also OK. As long as the model is general enough to handle the various permutations, we should be OK.

Bill VerSteeg






From: Jonathan Morton [mailto:chromatix99@gmail.com]
Sent: Thursday, February 26, 2015 3:43 PM
To: Bill Ver Steeg (versteb)
Cc: Dave Taht; bloat; Mikael Abrahamsson
Subject: Re: [Bloat] RED against bufferbloat


> We need to be careful to specify behaviors, as opposed to implementations. If we start to specify implementation details, the process will get bogged down in intractable differences.

I understand these sorts of requirements. Since I'm waiting for one of my computers to do something substantial, I'll have a quick stab at the problem.

I suspect a modular approach might work best. Different modules can be assigned to separate design teams, and a diagram can show how they fit together. So a shaper module, a Codel queue module, a fair queue module.

- Jonathan Morton