Cut-Through Switching ===================== Goals ----- In conventional store-and-forward switching, each switch must receive and buffer the entire frame before forwarding it to the next hop. This store-and-forward process adds delay per hop that is proportional to the frame size, as the switch cannot begin transmission until the complete frame has been received. When packets traverse multiple switches, these delays accumulate, resulting in significant end-to-end latency. .. figure:: media/storeandforward.png :align: center :width: 50% Cut-through switching addresses this problem by starting the forwarding process as soon as the destination MAC address and outgoing interface are determined, typically after receiving just the frame header. This allows the switch to begin forwarding the frame while it is still being received, substantially reducing switching delay, especially in multi-hop scenarios. .. figure:: media/cutthrough.png :align: center :width: 50% However, cut-through switching involves trade-offs compared to store-and-forward switching. Since forwarding begins before the entire frame is received, the frame check sequence (FCS) cannot be verified at each switch, potentially leading to a higher error rate as corrupted frames may be forwarded through the network. The FCS check is instead performed at the destination host. In this showcase, we will demonstrate cut-through switching and compare it to store-and-forward switching in terms of delay, highlighting the performance benefits of this forwarding method. | Verified with INET version: ``4.6`` | Source files location: `inet/showcases/tsn/cutthroughswitching `__ The Model --------- .. Cut-through switching reduces the 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 the 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 intranode 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. .. note:: The default is store-and-forward behavior in hosts such as :ned:`StandardHost`. The example simulation contains two :ned:`TsnDevice` nodes connected by two :ned:`TsnSwitch` nodes (all connections are 1 Gbps): .. figure:: media/Network_.png :align: center In the simulation, ``host1`` sends 1000-Byte UDP packets to ``host2``, with a mean arrival time of 200ms, and 50ms jitter. There are two configurations in omnetpp.ini, ``StoreAndForward`` and ``CutthroughSwitching``, which only differ in the use of cut-through switching. Here are the configurations: .. literalinclude:: ../omnetpp.ini :language: ini The default :ned:`LayeredEthernetInterface` in :ned:`TsnDevice` and :ned:`TsnSwitch` has cut-through disabled by default. In order to use Cut-through is enabled by setting the :par:`hasCutthroughSwitching` parameter to ``true``. Results ------- The following video shows the store-and-forward behavior in Qtenv: .. video:: media/storeandforward.mp4 :width: 80% :align: center The next video shows the cut-through behavior: .. video:: media/cutthrough1.mp4 :width: 80% :align: center The following sequence chart excerpt shows a packet sent from ``host1`` to ``host2`` via the switches, for store-and-forward and cut-through, respectively (the timeline is linear): .. figure:: media/storeandforwardseq2.png :align: center :width: 100% .. figure:: media/seqchart2.png :align: center :width: 100% We compared the end-to-end delay of the UDP packets in the case of store-and-forward switching vs cut-through switching: .. figure:: media/delay.png :align: center :width: 90% We can verify that result analytically. In the case of store-and-forward, the end-to-end duration is ``3 * (transmission time + propagation time)``, around 30.246us. In the case of cut-through, the duration is ``1 * transmission time + 3 propagation time + 2 * cut-through delay``, around 10.534us. Sources: :download:`omnetpp.ini <../omnetpp.ini>`, :download:`CutthroughSwitchingShowcase.ned <../CutthroughSwitchingShowcase.ned>` Try It Yourself --------------- If you already have INET and OMNeT++ installed, start the IDE by typing ``omnetpp``, import the INET project into the IDE, then navigate to the ``inet/showcases/tsn/cutthroughswitching`` folder in the `Project Explorer`. There, you can view and edit the showcase files, run simulations, and analyze results. Otherwise, there is an easy way to install INET and OMNeT++ using `opp_env `__, and run the simulation interactively. Ensure that ``opp_env`` is installed on your system, then execute: .. code-block:: bash $ opp_env run inet-4.6 --init -w inet-workspace --install --build-modes=release --chdir \ -c 'cd inet-4.6.*/showcases/tsn/cutthroughswitching && inet' This command creates an ``inet-workspace`` directory, installs the appropriate versions of INET and OMNeT++ within it, and launches the ``inet`` command in the showcase directory for interactive simulation. Alternatively, for a more hands-on experience, you can first set up the workspace and then open an interactive shell: .. code-block:: bash $ opp_env install --init -w inet-workspace --build-modes=release inet-4.6 $ cd inet-workspace $ opp_env shell Inside the shell, start the IDE by typing ``omnetpp``, import the INET project, then start exploring. Discussion ---------- Use `this `__ page in the GitHub issue tracker for commenting on this showcase. .. 1054B; 8.432us; 25.296+propagation time (1000 + 8 + 20 + 18 + 8) * 8 / 1E+9 * 3 / 1E-6 (1000 + 8 + 20 + 18 + 8) * 8 / 1E+9 / 1E-6 + 22 / 1E+9 / 1E-6 * 2