Cut-through switching is mentioned as a requirement for datacenter switches. Originating from high performance computing (HPC) environments, cut-through switching was aimed to reduce network latencies to the minimum. In this article, we review the background behind cut-through switching, and examine the effectiveness of the cut-through scheme in typical datacenter networks.
What is Cut-through Switching?
Cut-through is a switching method for packet-switching systems, wherein the switch starts forwarding a packet before the entire packet has been received, normally, as soon as the destination address is processed. This technique reduces latency through the switch. Cut-through is compared to store-and-forward switching, that, as its name reflects, requires storing the entire packet before its transmission begins.
Cut-through switching became popular again in InfiniBand networks, since these are often deployed in symmetric environments such as supercomputer clusters, where latency may be a concern.
Latency gain for small-medium packets
The overall computing performance of an HPC system may be sensitive to the low latency of control packets. These packets are typically short (used for synchronization), and thus they are the focus of interest for cut-through switching. Long packets have less significance in this discussion.
When evaluating the performance of cut-through switching versus store-and-forward switching for small-medium packets (up to 256B/512B) both methods have about the same performance. This is because even a cut-through switch accumulates/stores 64B-512B chunks, depending on the micro-architecture, before it forwards it to the egress port.
For instance, note that Cisco’s Nexus 5000 series switches have cut-through switching and specify a minimum latency of 3.2us, a value that is equivalent to modern store-and-forward switches with packets up to 1KB.
Cut-through between ports of different speeds
Cut-through switching cannot operate when sending traffic from a slow port to a faster port. This, however, is a typical case as packets flow from servers through the datacenter access switches (top-of-rack or end-of-row).
Let us evaluate uplink traffic in a top-of-rack (TOR) switch attaching up to 40 servers each connected with a 10 Gigabit Ethernet (GbE) port. The uplink ports connecting the TOR switches to an aggregation/core switch are 40GbE, going to 100GbE.
Traffic from the slower 10GbE server connection to the faster 40GbE/100GbE uplink port cannot support cut-through. The uplink port sends the packet faster than the rate it is being received from the slower port. Transmission cannot start before the packet is fully received. Otherwise the uplink port TX FIFO might under-run. Hence, packets between a slower port and a faster port are store-and-forward even in a cut-through capable switch.
Cut-through between equal port speeds
Cut-through is not likely to occur between two ports of the same speed.
By definition, a packet can be cut-through only if the egress port is empty. As packet traffic is bursty, a few under-utilized ports sending cut-through traffic to the same egress port will experience intermittent egress port congestion. One can show that even networks with low utilization — as little as a few percentages — would not be able to use cut-through in most cases, and would not permit the establishing of deterministic low-latency bound that cut-through switching allegedly guarantees. Furthermore, with today’s server virtualization technologies the server port is unlikely to be under-utilized.
To conclude, under most utilization scenarios, packets between a few ports of the same speed are store-and-forward even in cut-through enabled switches.
Summary
The key value of cut-through is to enable low latency for traffic switched across the datacenter network. After examination, it seems that cut-through does not have a practical use in Ethernet-based datacenter switches. The new generation of store-and-forward switches present latencies that are equivalent and deterministic for the small-medium packets that matter. Latencies of new store-and-forward switches have no impact on the performance of real applications versus cut-through switches.
Cut-through switching does not come for free. Devices that support cut-through typically do not support: (a) large buffers for congested TCP traffic, (b) system capacity scalability, and (c) clear channel 40G and 100G ports across the fabric — or if they do then fallback to store-and-forward.
Typical datacenter networks are multi-tier, multiplying delay with the number of hops. This is why system vendors focus on building large, strictly non-blocking switches. If the switch is not strictly non-blocking (e.g., XAUI based switch), the probability for a packet to be unnecessarily delayed multiplies, not just due to intermittent oversubscription to one port, but also due to artificial (i.e., blocking) oversubscription. As a result, the original drive to provide cut-through switching actually produces increased delay and latency, contradicting the objective.
In conclusion, when building a datacenter switch, it is far more important to have an architecture that provides deterministic latency under all traffic conditions, strictly non-blocking configurations from 10’s to 1,000’s of ports, effective 40GbE and 100GbE port support, and buffers that ensure reliable network operation under real network conditions.