Sebastian Moeller <moell...@gmx.de> writes: > Hi Toke, > >> On Jan 18, 2019, at 14:33, Toke Høiland-Jørgensen <t...@redhat.com> wrote: >> >> Georgios Amanakis <gamana...@gmail.com> writes: >> >>> Yes, exactly. Would be interesting to hear what Jonathan, Toke and >>> others think. I want to see if fairness is preserved in this case with >>> sparse flows only. Could flent do this? >> >> Well, sparse flows are (by definition) not building a queue, so it >> doesn't really make sense to talk about fairness for them. How would you >> measure that? >> >> This is also the reason I agree that they shouldn't be counted for host >> fairness calculation purposes, BTW... > > That leads to a question (revealing my lack of detailed knowledge) if > there is a sufficient number of new flows (that should qualify as > new/sparse) that servicing all of them takes longer than each queue > accumulating new packets, at what point in time are these flows > considered "unworthy" of sparse flow boosting? Or differetly how i > cake going to deal with a UDP flood where the 5 tuple hash is > different for all packets (say by spoofing ports or randomly picking > dst addresses)?
Well, what is considered a sparse flow is a function of both the flow rate itself, *as well as* the link rate, number of competing flows, etc. So a flow can be sparse on one link, but turn into a bulk flow on another because that link has less capacity. I explore this in some detail here: https://doi.org/10.1109/LCOMM.2018.2871457 -Toke _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake