Hi Greg Since Dave's email prompted me to read your draft, I thought I'd chime in with this comment:
Section 3.2 of the draft reads: > 3.2. Queuing behavior analysis > > Similar to the queue protection function outlined in the previous > section, it may be feasible to devise a real time flow analyzer for a > node that would identify flows that are causing queue build up, and > redirect those flows to the QB queue, leaving the remaining flows in > the NQB queue. To me, this sounds exactly like a description of what the sparse flow optimisation of FQ-CoDel, so I'm puzzled why you don't believe this to be the case? Sure, FQ-CoDel uses its per-flow queueing system as a mechanism to achieve this, but if you really can't do per-flow queueing, it is conceivable that the mechanism could be implemented without it. The high-level logic is basically (in your terms) "on enqueue, does this flow already have a packet queued? if yes, it's a QB flow, if no, it's an NQB flow". It is simple, but quite effective. I've recently analysed the behaviours that fall out of this simple mechanism in some detail, which may be relevant to your efforts. See this publication in IEEE Communication Letters: https://doi.org/10.1109/LCOMM.2018.2871457 -Toke _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
