The problem with ABR is that the client device, such as a smartphone or tablet, is in charge of the bandwidth and isn’t fair about how that capacity is allocated. If an iPhone is the first device on the home network to request a video stream, it will typically receive a high bit-rate version — perhaps more than it really needs. Then, when a connected HD television requests a stream, it tends to get the scraps, resulting in a crummy-looking pixel-icious image.
From Wikipedia on WFQ:
WFQ is a generalization of fair queuing (FQ). Both in WFQ and FQ, each data flow has a separate FIFO queue. In FQ, with a link data rate of , at any given time the active data flows (the ones with non-empty queues) are serviced simultaneously, each at an average data rate of . Since each data flow has its own queue, an ill-behaved flow (who has sent larger packets or more packets per second than the others since it became active) will only punish itself and not other sessions.
As opposed to FQ, WFQ allows different sessions to have different service shares. If data flows currently are active, with weights data flow number will achieve an average data rate of
It can be proven  that when using a network with WFQ switches and a data flow that is leaky bucket constrained, an end-to-end delay bound can be guaranteed. By regulating the WFQ weights dynamically, WFQ can be utilized for controlling the quality of service, for example to achieve guaranteed data rate.