The following question occurred to me. It's empirical, not theoretical (though
the theory might be interesting, it's not clear that creating a theoretical
model that matches real hardware is realistic.
I'm a big fan of Cake, and recommend it to everyone that can deploy it on the
router closest to the bottleneck link. But given its complexity (and
interactions with the complex control loops in end-to-end TCP, including things
like minimum cwnd and the number of TCP sessions that are concurrent, etc),
it's hard for me to guess the answer to certain issues that may come up in
practice less commonly.
Here's an example. What if there is a FIFO queue that can build up queueing
delay to a certain extent between Cake and the bottleneck. In a badly setup
DOCSIS 2 system, this can happen due to other traffic into the DOCSIS head-end.
Cake's basic assumption that by setting the max bitrate on the uplink to
slightly less than the claimed "up to" capacity is not fully realistic in such
situations - the queue can build up in the path to the head-end.
The same can happen in a WiFi situation on the airlink to the AP from the STA,
if you were to run Cake with a setting for bandwidth that is set much lower
than the achievable shared airlink bitrate. And on the AP side, the path to
STA's is often forced to go through a FIFO either in the hardware or in the
proprietary driver that can get pretty large (though adding 20 msec. might not
be problematic in most user-interaction cases).
But it would be interesting to assess whether inserting a FIFO delay between
Cake and the actual NIC that could be cranked up in delay causes surprising
results.
A "surprise" would be that either throughput or lag-under-load wih various
traffic mixes (bulk traffic, in particular) would do something other than the
simple thing of staying with the same throughput and adding the FIFO delay into
the lag under load.
Anyone done such an exploration?
One of the reasons I wonder is because I wondered whether just using Cake to
moderate the flows from an AP to STAs in an access point would be good, even if
the hardware doesn't allow one to shorten the queue it builds up inside.
Obviously doing a "distributed Cake" among all the STAs trying to send to an AP
would be not necessarily good, because the STAs can't cooperate efficiently
because they have to go through the AP and get the packets reflected,
encountering all kinds of delay at a scale that would make it hard to
coordinate the flow towards the AP. (that's why 802.11ax is based on AP polling
rather than LBT arbitration, but even in 802.11ax, the polling doesn't provide
any information to the STA's that they could use to manage their flows.).
PS: Make WiFi fast really needs to address 802.11ax (WiFi6), which I suspect
will be *worse* than WiFi in its congestion interactions with TCP and QUIC on
UDP. Sad if a "premium" upgrade becomes a downgrade because of congestion
mismanagement. Polling helps increase usable airtime, but it doesn't help TCP
and QUIC moderate their contributions to creating bufferbloated connections.
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
