My experience with Spectrum is that they allow a large accumulation of in-transit packets when traffic rate is near the provisioned capacity. Some people call t

My experience with Spectrum is that they allow a large accumulation of in-transit packets when traffic rate is near the provisioned capacity. Some people call this "buffer bloat". Some background: If you study traffic shaping, you'll discover that TCP behaves poorly if packets are simply dropped when throughput approaches the limit (congestion collapse). So traffic shaping usually _delays_ packets rather than dropping, at least initially. This works in that TCP backs off its send rate gracefully and throughput approaches the provisioned limit. However you've now introduced a large delay into every packet's transit through the shaper box. This isn't a problem for bulk TCP flows -- they work ok in the presence of latency but it is problematic for unrelated latency sensitive traffic (e.g. UDP, SSH). To work around this problem traffic shaping usually introduces some notion of delay per flow. This can be done in a few different ways e.g. RED (random early detection), or per-flow queues. Ok so back to Spectrum: my experience has been that their shaper box does not do anything good as far as per-flow queues, RED etc. It seems pretty basic and dumb. The result is that latency approaches infinity as throughput approaches the provisioned limit. I work around this by deploying my own shaping on my edge router. Through experiment, I have configured it to limit at just below the threshold where Spectrum begins severely delaying my traffic. I use RED on my router to give good latency for traffic unrelated to bulk flows. You'll need a router capable of traffic shaping, e.g. Mikrotik, Linux iptraf, Cisco IOS.