from http://ethernethistory.typepad.com/papers/EthernetPaper.pdf http://ethernethistory.typepad.com/papers/EthernetPaper.pdf (1975): > Recognizing the costline

from http://ethernethistory.typepad.com/papers/EthernetPaper.pdf http://ethernethistory.typepad.com/papers/EthernetPaper.pdf (1975): > Recognizing the costliness and dangers of promising "error-free" communication, we refrain from guaranteeing reliable delivery of any single packet to get both economy of transmission and high reliability averaged over many packets [Metcalfe, 1973b]. Removing the responsibility for reliable communication from the packet transport mechanism allows us to tailor reliability to the application and to place error recovery where it will do the most good. This policy becomes more important as Ethernets are interconnected in a hierarchy of networks through which packets must travel farther and suffer greater risks. The Ethernet CRC works at the right timescales / data rates and does not depend on information or assumptions about above layers. It works mostly OK at quickly knocking out packets that got grossly mangled in transit -- to avoid bothering hosts with corrupted packets and to avoid transmitting them further -- but that's it. There's no retransmissions, no acknowledgement/negative-acknowledgement mechanisms, no negotiating, no dependence on address schemes. Implementing the physical layer's error correction/detection mechanisms in a minimal way appropriate to that specific physical medium was a master stroke of design. This sort of end-to-end aware design gave higher layers freedom to do what they wish (in terms of latency or reliability) but also let the Ethernet frame standard remain useful for networks far beyond 10Base5. Some Ethernet switches are in a great hurry and don't want to wait to fully receive (and CRC-check) an incoming frame before starting to output it. They start outputting a frame as soon as they know where to output it: when they've finished hearing the full destination MAC address. This is kinda iffy, because the switch hasn't seen the end of the frame, so it can't know the CRC value of the incoming frame! How are they to cope with a corrupt inbound packet, if they've already started transmitting it out? There's no way to undo transmitting it, so the switch takes the next best approach -- spitefully ruining the outgoing frame, by setting its CRC field to something intentionally incorrect. It'll never checksum right, and will be discarded at the first device capable of doing so.