Cut-through switching is a method used in packet switching systems, such as Ethernet switches, to forward frames or packets through the network. It involves starting the forwarding process before the entire frame has been received, typically as soon as the destination address and outgoing interface are determined. This is in contrast to store-and-forward switching, which waits until the entire frame has been received before forwarding it. One advantage of cut-through switching is that it may reduce the switching delay of Ethernet frames, since the switch can begin forwarding the frame as soon as it has enough information to do so. However, cut-through switching also has some potential disadvantages, such as a higher error rate compared to store-and-forward switching, since it does not check the entire frame for errors before forwarding it. In this showcase, we will demonstrate cut-through switching and compare it to store-and-forward switching in terms of delay.
Cut-through switching reduces switching delay, but skips the FCS check in the switch. The FCS is at the end of the Ethernet frame; the FCS check is performed in destination host. (This is because by the time the FCS check could happen, the frame is almost completely transmitted, so it makes no sense). The delay reduction is more substantial if the packet goes through multiple switches (as one packet transmission duration can be saved at each switch).
Cut-through switching makes use of intra-node packet streaming in INET’s modular Ethernet model. Packet streaming is required because the frame needs to be processed as a stream (as opposed to as a whole packet) in order for the switch to be able to start forwarding it before the whole packet is received.
The default is store-and-forward behavior in hosts such as StandardHost.
The example simulation contains two TsnDevice nodes connected by two TsnSwitch’ nodes (all connections are 1 Gbps):
In the simulation,
device1 sends 1000-Byte UDP packets to
device2, with a mean arrival time of 100ms,
and X ms jitter. There are two configurations in omnetpp.ini,
which only differ in the use of cut-through switching.
Here are the two configurations:
The default EthernetInterface in Ethernet switches doesn’t support cut-through. In order to use
cut-through, we replace the default interface with EthernetCutthroughInterface. Cut-through is
disabled in this interface by default, thus it needs to be enabled by setting the
In addition, all necessary components in the switch need to support packet streaming. The cut-through interface in the switches supports packet streaming by default; the default PHY layer in hosts need to be replaced with EthernetStreamingPhyLayer, which support packet streaming.
The following video shows the store-and-forward behavior in Qtenv:
The next video shows the cut-through behavior:
The following sequence chart excerpt shows a packet sent from
device2 via the switches,
for store-and-forward and cut-through, respectively (the timeline is linear):
We compared the end-to-end delay of the UDP packets in the case of store-and-forward switching vs cut-through switching:
We can verify that result analytically. In case of store-and-forward, the end-to-end duration
3 * (transmission time + propagation time), around 25.296 ms. In the case of cut-through,
the duration is
1 * transmission time + 3 propagation time + 2 * cut-through delay, around 8.432 ms.
Use this page in the GitHub issue tracker for commenting on this showcase.