Hi Toke, thanks for the pointer to your paper, I had not seen it before. I agree that could be a candidate algorithm. It is certainly simple. It may not be the only (or perhaps even the best) solution for the dual-queue case though. I'm thinking in the context of an L4S TCP flow, which can respond quickly to "new" ECN markings and achieve link saturation with ultra low (but not zero) queuing delay. A good property for a queue protection algorithm would be that these L4S flows could be consistently placed in the NQB queue. I think that the simple approach you mentioned would result in many L4S flows being deemed Queue Building.
Additionally, we've observed applications that send variable sized "messages" at a fixed rate (e.g. 20 messages/second) where the message sometimes exceeds the MTU and results in two closely spaced (possibly back-to-back) packets. This is a flow that I think should be considered to be NQB, but would get flagged as QB by the simple approach. You described this case in your paper, where you state that the first Q bytes of each burst will be treated as NQB (the first packet in the case we're talking about here), but the rest will be treated as QB. Assuming that message latency is important for these sorts of applications, this is equivalent to saying that the entire burst is considered as QB. In the fq_codel case, the message latency would be something like Q(n-1)(N+1)/R (assuming no other sparse flow arrivals), something like 1.3ms using the example values in your paper (plus n=2, N=10) which may be ok. In the dual-queue case it is a bigger deal, because the remaining packets would be put at the end of the QB queue, which could have a latency of 10 or 20 ms. So, a queue protection function that provides a bit more (but still limited) allowance for a flow to have packets in queue would likely work better in the dual-queue case. -Greg On 10/29/18, 8:15 AM, "Toke Høiland-Jørgensen" <[email protected]> wrote: 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
