Retro networking / WAN communities

Paul Koning paulkoning at comcast.net
Tue Apr 12 09:19:47 CDT 2022



> On Apr 12, 2022, at 12:52 AM, Grant Taylor <cctalk at gtaylor.tnetconsulting.net> wrote:
> 
> ...
> I vaguely remember that there were three main forms of switching:  store and forward, cut-through, and a hybrid of the two.  My understanding is that S&F had the ability to sanity check (checksum?) frames and only re-send out valid / non-corrupted frames.  Conversely C.T. could not do this sanity checking and thus could re-send corrupted frames.  The 3rd form did a sanity check on the first part of the frame.  --  I think.

The normal type of bridge / switch is the store and forward type, which discards bad packets and forwards only good ones.

Cut through means starting to forward a packet before the end of it has been received.  That necessarily means forwarding it without knowing if it's a good frame (good CRC, length, alignment if applicable).  

The remaining question is what happens with the cut-through frame when the end of packet arrives and is seen to be bad.  One possibility is to propagate the received packet exactly, in which case (barring an unfortunate additional data error) it will be seen as bad by the eventual recipient.  The other possibility is to force an explicit abort of some sort to make sure the packet is seen as bad.  For a mixed LAN type bridge, only the second option is valid (because you aren't doing CRC forwarding in that case).  Of course, a lot of mixed type bridges are also mixed speed, where cut through isn't really an option.  Theoretically you could have, say, 100 Mb/s Ethernet to FDDI, but in practice I don't know if those existed and doubt that, if so, they used cut through.

You can't do sanity checking on the frame beginning; there isn't anything that gives you a clue whether the start is valid or not.  At least not apart from trivial checks like "source address can't be a multicast address".  The only data link protocol I can think of that lets you check the frame beginning is DDCMP.

	paul



More information about the cctalk mailing list