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:[email protected]] 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
_______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
