About SQM and Buffbloat

Hi Guys,
I did some tests on SQM's buffbloat optimization, and here are the results.
The buffbloat problem was not obvious in my network environment, so I set up the following test environment.
image

  1. As shown in the figure, three routers are cascaded through the LAN→WAN connection
  2. Run the iperf3 server on Router A
  3. In order to simulate network congestion, we limit the speed of the MAC address of the Test device on Router B. The lower the rate limit value is, the more obvious the effect will be.
  4. The Test device can open two consoles. One console can ping the gateway address of Router A and observe the ping latency, other console runs the iperf3 command.
  5. As can be seen, when iperf3 is running, the ping latency will rise sharply, as shown in the red box below, which proves that buffbloat exists on the network.

 
 
Now we need to configure qos policies to improve buffbloat. Execute the following script. I am using XE300, the WAN port is eth1, and set the rate to about 70% of the bandwidth.

tc qdisc replace dev eth1 root cake docsis ack-filter bandwidth 40kbps
ip link add name ifb4eth1 type ifb
tc qdisc del dev eth1 ingress
tc qdisc add dev eth1 handle ffff: ingress
tc qdisc del dev ifb4eth1 root
tc qdisc add dev ifb4eth1 root cake bandwidth 40kbps besteffort wash
ip link set ifb4eth1 up # important 
tc filter add dev eth1 parent ffff:  matchall action mirred egress redirect dev ifb4eth1

 
 
Run iperf3 -c 192.168.99.1 -p 3030 -t 10 -P 10 on the test device to measure the uplink data of the Test router.


There will still be latency, but this is much better than before, indicating that buffbloat has improved.

 
 
Run iperf3 -c 192.168.99.1 -p 3030 -t 10 -P 10 -R on the test device to measure the downlink data of the Test router.


Latency is almost the same as before the qos policy was set and has not improved

 
 
For the above test, I refer to the official buffbloat example.https://www.bufferbloat.net/projects/codel/wiki/CakeRecipes/
I tried to configure layer_cake.qos and piece_of_cake.qos scripts directly using sqm-script and got the same results.

SQM's cake strategy improves upstream buffbloat from testing results, but if a device on your network is downloading a large file, your other devices may still encounter buffbloat.

Of course, my knowledge of qos configuration is very limited, and this is a very hasty conclusion. If you have any other test suggestions, please let me know

1 Like

Just a quick note, why did you shape down to 64Kbps?

At that rate it takes 192ms to transmit a single 1538 byte packet.... and even a 98 byte ICMP echo request (ping) packet consumes 12 ms transmission time.

So the observed latencies with SQM seem sane and indicate that there are a few packets ahead of your icmp probes, on egress SQM/cake can move the smaller sparser ping packets to the front of larger data packets, but on ingress SQM depends to a bigger degree on the sequence in which the upstream sends the packets.

It seems like a funny coincidence though, that the latency under load without SQM ended up in the same range....

1 Like

See Why you need at least 3Mbps upload to get good game performance with ~1500byte packets: Doing the math for why latencies are destined to be annoying until you have at least 3Mbps each way.

Try redoing your experiment with at least 3Mbps each way and see how it goes.

1 Like