[Cake] Curious regarding Cake sensitivity to hardware queue depth

[David P. Reed]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20200508/3a7cbac8/attachment.html>