>> If the relative load from the flow decreases, BLUE’s action will begin to >> leave the subqueue empty when serviced, causing BLUE’s drop probability to >> fall off gradually, potentially until it reaches zero. At this point the >> subqueue is naturally reset and will react normally to subsequent traffic >> using it. > > But if we reach a queue length of codel’s target (for some small amount of > time), would that not be the best point in time to hand back to codel? > Otherwise we push the queue to zero only to have codel come in and let it > grow back to target (well approximately).
No, because at that moment we can only assume that it is the heavy pressure of BLUE that is keeping the queue under control. Again, this is an aspect of Codel’s behaviour which should not be duplicated in its alternate, because it depends on assumptions which have been demonstrated not to hold. BLUE doesn’t even start backing off until it sees the queue empty, so for the simple and common case of an isochronous flow (or a steady flood limited by some upstream capacity), BLUE will rapidly increase its drop rate until the queue stops being continuously full. In all likelihood the queue will now slowly and steadily drain until it is empty. But the load is still there, so if BLUE stopped dropping entirely at that point, the queue would almost instantly be full again and it would have to ramp up from scratch. Instead, BLUE backs off slightly and waits to see if the queue *remains* empty during its timeout. If so, it backs off some more. As long as the queue is still serviced while BLUE’s drop probability is nonzero, it will back down all the way to zero *if* the traffic has really gone away or become responsive enough for Codel to deal with. Hence BLUE will hand control back to Codel only when it is sure its extra effort is not required. - Jonathan Morton _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
