[email protected] writes: >> On the contrary, even if a particular flow is sparse, the relevant >> quantum calculation should involve the number of *bulk* flows >> attached to the same host. Though there is possibly an argument for >> making it the *sum* of the sparse and bulk flows, making it just the >> sparse ones is wrong. > > I was about to point out that my assumption is obviously wrong. > cake_enqueue() can still assign a packet to a bulk flow. Will try with > the sum of the flows and report.
From a fairness perspective it doesn't really matter whether you count the sparse flows or not. You use this for assigning a single quantum's worth of initial deficit; any flow that actually needs fairness enforced is going to be backlogged anyway, and the deficit increase in bulk state is what matters for enforcing fairness. What the initial quantum does is that it limits how big packet(s) a sparse flow can send before it is demoted to bulk. There are certainly some esoteric cases where this might matter (things like, can a DNS flow get two small back-to-back packets through in one go); but this is going to vary with the traffic conditions anyway, so I doubt it matters in practice. Given this, and given that the state tracking is already plenty complicated, I'd suggest not counting per-host sparse flows at all, and just using the bulk count. I'm pretty sure you'll get the same fairness behaviour in this case. Care to try that? :) -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
