I have a hot take. Switching is boring, I honestly don’t really find the same joy in setting up a switch as I do setting up routing. Alas, it’s an imperative part of our networks and one that is absolutely foundational in a latency sensitive environments. In fact in a latency sensitive network it might be advantageous to push the boundary on your switched infrastructure to ‘eek’ out as much performance as you can.

There’s an old adage that rings true to this day.

…switch where you can, route where you must…

I’m not going to bury the lead here, you saw it in the title. Switching is efficient and certainly helps achieve lower latency than routing but it’s when combined with cut-through switching that we truly benefit from the lowest possible latency in switched infrastructure. Cut through switching provides two obvious benefits when building low latency networks.

The first benefit is how efficient it is at processing frames. Store-and-forward buffers the entire frame before forwarding it. Cut through switching only reads in the first 6 bytes of the frame to identify the destination MAC before forwarding. The second reason is determinism, the last thing we want from an environment where latency/jitter minimization is crucial is to introduce variables into our switching infrastructure. In the context I’m describing, determinism give us an assurance as to how long it will take a switch to process a frame. When talking about cut-through I know that no matter how big the frame is, the switch only need the first 6 bytes before forwarding it to the destination, there are no other variables are at play. The alternative is store-and-forward and that does introduce variables that we cannot control for. With store-and-forward there is a difference in performance between a 64 byte frame and a 1500 byte frame being buffered on the interface and having their CRC checked, that variability is jitter. Cut through provides that deterministic behavior we require.

Cut through great, but…

As with anything, there are trade-offs. Cut through gets us a tactical edge on latency and jitter but at the cost of error checking. A switch acting in store-and-forward would silently drop a frame that has CRC errors, but when cut through is enabled that frame is going to travel all the way to its destination before the destination decapsulates the frame, identifies the error and drops it. This is inefficient but it’s the trade-off we accept in lieu of the tactical advantage in latency and jitter.

Closing thoughts

If you’re trying to build a low latency network segment, consider implementing cut through switching. It’s probably not appropriate for your entire layer 2 environment, but definitely for the most latency sensitive parts and as with anything, balance is key. Store-and-forward where you have more flexibility to do so, cut through where performance is the key performance indicator.