Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Ideally each flow gets its own queue, or, more likely, multiple flows are hashed into a flow queue.
If it's FQ, each flow queue is allow equal share of bandwidth. If WFQ, different flows are permitted unequal shares of bandwidth. NB: even with FQ, normally different flows will be using different amounts of bandwidth, but they are guaranteed access to equal bandwidth.
What FQ does, if there's congestion, each flow queue will fill with packets. How fast depends on flow's attempted bandwidth usage, flow's share of egress bandwidth, and size of packets. In practice, everything else being equal, flows with high attempted bandwidth usage, will fill their queue earlier and drop sooner. I.e. FQ tends to drop packets from the heavy bandwidth flows first.
Yes, you can use RED too, but usually RED is global to the whole class (unless you're using a device that supports FRED). Since FQ "target" heavy bandwidth usage flows before light bandwidth usage flows, if FQ is available, I consider it much better than RED. (In theory, RED is great, in practice, it's difficult to accomplish its intended goals.)
