Let's say we have a host A that is sending 1bit of data (I know it is impossible practically) at at rate of 1bps to host B. Host A and Host B are connected via 2 switches. We assume that the propagation delay is 0 and the delay inside the switches is 0 (ideal case). In addition, in the first case, we apply the store-and-forward policy at the switches input. We apply the formula of the end-to-end delay from host A to host B which is equal to 3 x transmission time (Reference). The same experience is made again but using the cut-through switching policy. We should have an end-to-end delay equal to 1 x transmission time according to the same reference. However, I am not able to understand that the end-to-end delay using the cut-through policy is equal to 1transmission time in our case since I think host A needs 1s to put the 1 bit at the link, than the switch 1 needs another 1s to put it at the link and the same for switch 2 so in total we will have 3transmission time.

What is wrong with my reasoning.

Thank you.

2 Answers 2


We assume that [...] the delay inside the switches is 0. [...] We should have an end-to-end delay equal to 1 x transmission time according to the same reference.

The "delay inside the switches" has a hard lower limit and cannot be zero. With Ethernet, preamble, SFD and destination MAC need to be received. That's at least 14 bytes = 112 bits. Of course, making the forwarding decision and queueing a frame for egress cannot be done in zero time either, but there's no hard limit to that.

In practice, you need to consider the first-in/first-out delay that a switch requires (the processing delay). With store-and-forward that delay also depends on the frame length, but it's generally last-in/first-out delay + serialization delay.

If you ignore that physical limit and assume the processing delay to also be zero then any cut-through switch in the path causes no net delay - any ingress bit is forwarded out of the destination port in the very next bit slot. Effectively, the switch behaves like a cable (which isn't really possible, see above).

Also ignoring propagation, all delay that you've got left is the data serialization by the sender and the deserialization by the destination - these overlap, so you count them as one.

(I use serialization delay instead of transmission delay because it's less ambiguous.)

Your problem seems to be that the bit that is put out by the source needs to cross the first switch, then the second switch and then reach the destination. However, when there's no propagation delay and no processing delay the bit reaches both switches and the destination at the very same time. Obviously, that isn't possible in a real world and your intuition makes you fail to accept those assumptions.

  • Thank you for your response. But, why under those ideal assumptions we don't take into account the transmission delay from switch 1 to switch 2(which is equal to 1bps like in the host A). I mean by this why the output port of switch 1 does not behave like the output port of the host A?
    – tonyjk
    Commented Feb 10, 2023 at 19:33
  • Because with (unrealistic) zero propagation time and zero processing delay on a cut-through switch, that switch outputs a received bit at the same instant. Therefore, the first bit reaches the destination while it is still being output by the source.
    – Zac67
    Commented Feb 10, 2023 at 20:14
  • sorry really but I am not understanding this point. Why the switch outputs the received bit at the same instant? Why the output of the switch does not behave like the output of the host A? I mean if the switch output port has a 1bps why we are neglecting it? I understand that we have at the same time the bit at the output of the host A and at the input of switch 1. Since we dont have any delay inside the switch, the bit will be ready at the output port of the switch 1 but it needs 1s to be transmitted again no?
    – tonyjk
    Commented Feb 10, 2023 at 20:23
  • 2
    @tonyjk All the transmissions happen at the same time. That's what having a cut through delay of 0 means. You're imagining a marginally less unrealistic switch which has a cut through delay of 1 bit, so you wait for the whole bit to be received before you start sending it.
    – richardb
    Commented Feb 10, 2023 at 20:41
  • okay still not that much clear for me. My thoughts are more toward pipelining method. what will be the case if the switch 1 output port has a less bandwidth then
    – tonyjk
    Commented Feb 10, 2023 at 20:47

The assumption of a host sending 1 bit at a rate of 1 bit per second doesn't imply that it takes 1 second to send that bit. It only indicates that 1 bit was sent within a measured period of 1 second. It may have taken as little as .5 millisecond to actually transmit and receive the 1 bit from host A to host B, as is common in real world scenarios, even with transmissions greater than 1 bit in size.

Cut through switching requires specialized hardware or at least hardware configuration, and for peak efficiency even requires some implementation on hosts to maximize the value of the cut through option. Real world usage for cut through is rare in most business and consumer networks because the nature of common traffic is not particularly sensitive to latency on LAN traffic (even on large LANs) and LANs generally have good latency to start with. Additionally, it has been preferable to pursue improvements in throughput and bandwidth which tend to be automatically accompanied by improved latency as a byproduct. Additionally cut through makes no room for bad frame handling and can eliminate features such as policy/ACL, rate limiting and QoS, etc. It improves one specific thing while sacrificing nearly every other modern feature on enterprise switches.

As for the concept of end to end transmission time being less via cut through, yes, it can be massively reduced in a theoretical network because the difference between cut through vs store and forward means that for a single packet, that packet can be forwarded between switches with nearly no time required to receive the entire frame, examine it for any quality or policy requirements, and then retransmit it. It simply starts to receive the frame from the sending host, determines the destination MAC and begins immediately forwarding any data received to the destination MAC (if it has it in its MAC forwarding database).

This process means that the sending host may not have even finished sending the frame before the first switch is already forwarding whatever it has received to the second switch and that second switch may already be forwarding what it has received to the destination host. By the time the sending host finishes sending its frame, the receiving host may already be receiving the bulk of the payload of the frame. Hence the claim that it may reduce latency to near 1 x transmission time (give or take a bit of fudge factor for the destination MAC read, MAC table lookup, etc.).

Of course, if you have any store and forward switch in the path between hosts, the cut through means nothing, a minor improvement at best, since that switch will introduce enough latency that the savings of cut through are lost in the background noise, in real world terms of actual usage (not an imaginary 1 bit transmission, etc.).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.