Cut-Through or Store and Forward

Store and forward. Full stop.

With higher speeds, FE/GBE, it is less of an issue. This along with the move to TCP (from IPX) mens that the issue has pretty much gone away for almost everyone.

Additionally it is impossible to efectively do cut through from a slow medium to a faster one. Well pretty much anyway, so 10 -> 100 cut through has never been done for example. AFAIK.

Thanks for your input. I understand that this is not an issue these days, but still, is it store-n-forward? Also, can this be configurable?

Can you elaborate more on your statement: "Additionally it is impossible to efectively do cut through from a slow medium to a faster one."

10x

anybody43:

Store and forward is used these days, yes.

No, because there is really no point in doing "cut through" and similar schemes.

Consider what happens after the first N bytes (enough to perform "cut through") have been received. If the transmitter on the faster medium starts to transmit, what will it do after those N bytes have been transmitted?

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

:anybody43: :>> current implementation on the catalyst series :>> Cut-Through or Store and Forward :> Store and forward. Full stop.

:I understand that this is not an issue these days, but still, is it :store-n-forward?

'anybody43' said it was. "Store and forward. Full stop."

:Also, can this be configurable?

Not on any modern switch that I am aware of.

:Can you elaborate more on your statement: :"Additionally it is impossible to efectively do cut through from a slow :medium to a faster one."

To which I would add that it is also difficult (and sometimes not possible) to cut through from link to a half-duplex link; and that the converse of anybody43's statement is true, that it is difficult to cut through from a faster medium to a slower one.

Cut-through: once you have seen enough of the packet to see the destination MAC and have figured out which port (or ports) to send to, you start sending out the bits to the destination port without waiting for the rest of the packet to be received. The destination MAC is the first 6 octets after the preamble and start-frame (8 octets total). Therefor, 14 octets after starting to receive the packet the switch should start to send it onward.

Now what happens if the destination port is half duplex and is currently receiving a packet or is in the subsequent intra-packet gap? Then you cannot start transmitting the new packet. As the destination port collision detection and back-off scheme could end up delaying the available transmit slot by a number of packets, you might well not be able to cut through and so may end up having to store the whole packet anyhow.

Suppose though that the destination is clear but is running 10 times as fast as the sender. By the time the port decision is made, there are

14 octets to transmit. Add a bit of latency in the decision making and call it an even 20 octets -- e.g., that the receiver is starting to get the 21st octet at the time the switch is ready to transmit the first 20. As the destination medium is hypothetically 10 times faster than the source, the time to transmit those waiting 20 octets is going to be the same as the time to receive only an additional 2 octets (20/10) from the source -- the receiver will be getting the start of the 23rd octet at the time the transmitter has sent the first 20 and is ready to send the 21st and 22nd. The time to transmit those next 2 octets to the destination is (2*8/10) = 1.6 bit-times for the source, so after the transmitter has sent on the 21st and 22nd octets, the source is still only part-way through the second bit of receiving the 23rd. There would then be 4 bit times on the destination before the 23:2 source is available ... what is the transmitter to send then?

One could hypothesize an encoding scheme to the destination, something along the line of "send a NUL if there isn't a character available yet, send 0xFF followed by a NUL to represent a real NUL in the source, send 0xFF 0xFF for a real 0xFF is to be followed by an "idle" NUL. If one did this, then at the 23:1.6 point, the transmitter would send an "idle" octet of 0x00, which would take it to the 23:2.4 point. It still wouldn't have a full octet to send, so it'd have to send:

23:1.6 - idle 23:2.4 - idle 23:3.2 - idle 23:4.0 - idle 23:4.8 - idle 23:5.6 - idle 23:6.4 - idle 23:7.2 - idle 24:0 - source octet 23 24:0.8 - idle 24:1.6 - idle .... 24:7.2 - idle 25:0 - source octet 24

That'd be 9 "idle" octets between each source octet. If the source was the full 1512 (or whatever it is) octets long [including preamble and post-amble] then this would explode the destination packet to about 14880 octets on the destination -- far larger than the 9 Kb "jumbo frames" that Cisco implements on select devices. And clearly the destination device would have to know how to decode the encoding scheme in order to strip out the idles.

Do you see now why cut-through is effectively only useful in an environment that environments that are effectively "hubs"? They aren't even very good in single-speed full-duplex environments because at the time that one went to cut-through, some -other- switched port might be busy transmitting to the destination.

I guess I missed that 'full stop' at the top :-) Thank you so much for the detailed and interesting answer, Walter. I appreciate it a lot!

Yaron

Walter Roberson:

octets

currently

octets,

Thank you for your input on this! Understood.

Yaron

Steinar Haug:

similar

There is an old white paper on my web site ("Performance Impact of Backbone Speed in Switched Backbone Architectures") which discusses the theoretical limits on performance with cut-through versus store-and-forward and the impact of mismatches in interface speed.

To sum it up in a nutshell, cut-through is only meaningful between ports running at about the same speed and unless your application is rediculously delay sensitive, cut-through versus store-and-forward is irrelevant at speeds of 100 Mbps and above.

Good luck and have fun!