From a6a88dc6bb09f94f3c140c7823137f0a30cefd9f Mon Sep 17 00:00:00 2001
From: Daniel Micay <danielmicay@gmail.com>
Date: Sun, 27 Dec 2020 23:12:28 -0500
Subject: [PATCH] explain why Diffserv is not as useful as it seems

---
 static/articles/server-traffic-shaping.html | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/static/articles/server-traffic-shaping.html b/static/articles/server-traffic-shaping.html
index 32c9ef7a..8cd84f1d 100644
--- a/static/articles/server-traffic-shaping.html
+++ b/static/articles/server-traffic-shaping.html
@@ -164,13 +164,20 @@
 
                 <pre>tc qdisc replace dev eth0 root cake bandwidth 1995mbit besteffort</pre>
 
+                <p>On a server, setting it to use 100% of the provisioned bandwidth may work fine
+                in practice. Unlike a local network connected to a consumer ISP, you shouldn't
+                need to sacrifice anywhere close to the typically recommended 5-10% of your
+                bandwidth for traffic shaping.</p>
+
                 <p>This also sets <code>besteffort</code> for the common case where the server
-                doesn't have Quality of Service markings via Diffserv. If you actually have
-                traffic marked as bulk, video or voice to differentiate it consider changing that.
-                On a server, setting it to use 100% of the provisioned bandwidth may work fine in
-                practice. Unlike a local network connected to a consumer ISP, you shouldn't need
-                to sacrifice anywhere close to the typically recommended 5-10% of your bandwidth
-                for traffic shaping.</p>
+                doesn't have appropriate Quality of Service markings set up via Diffserv. Fair
+                scheduling is already great at providing low latency by cycling through the hosts
+                and streams without needing this kind of configuration. The defaults for Diffserv
+                traffic classes like real-time video are set up to yield substantial bandwidth in
+                exchange for lower latency. It's easy to set this up wrong and it usually won't
+                make much sense on a server. You might want to set up marking low priority traffic
+                like system updates, but it will already get a tiny share of the overall traffic
+                on a loaded server due to fair scheduling between hosts and streams.</p>
 
                 <p>You can use the <code>tc -s qdisc</code> command to monitor CAKE:</p>