Less_rfc_expr_$random_%_$last__rfc.txt

title: less rfc`expr $RANDOM % $LAST_RFC`.txt date: 2005-05-28 09:18:37

My, how things change... RFC 528, SOFTWARE CHECKSUMMING IN THE IMP AND NETWORK RELIABILITY, written by John McQuillan, was published in June of 1973. It's a surprisingly readable document that introduces packet checksums on the Internet. From TFRFC:

Our idea of the Network has evolved as the Network itself has grown. Initially, it was thought that the only components in the network design that were prone to errors were the communications circuits, and the modem interfaces in the IMPs are equipped with a CRC checksum to detect "almost all" such errors. The rest of the system, including Host interfaces, IMP processors, memories, and interfaces, were all considered to be error-free. We have had to re-evaluate this position in the light of our experience.

IMP stands for Interface Message Processor, and was what we'd now call a router. Having grown up with TCP/IP (drawn from me ma's teat, bye!), it's hard for me to imagine a protocol without some kind of checksum, or assuming that nearly all of your equipment would be error-free -- but then again, I have the benefit of 30 years of network research. It's fascinating to find out where your assumptions come from. Knowing his audience, the author threw in a good war story:

One of the earliest problems of this kind was discovered in 1971. The Harvard IMP was sometimes crashing in an unknown manner so that all the other IMPs were affected. It was finally determined that its memory was faulty and sometimes the routing messages read out from memory by the modem output interfaces were all zeroes. The adjacent IMPs interpreted such an erroneous message as stating that the Harvard IMP had zero delay to all destinations -- that it was the best route to everywhere! Once this information propagated to the other IMPs, the whole network was in a shambles.

(Lest we think that we've left this sort of thing behind, there are BGP flaps and such to keep us honest.) Tales like this weren't just there to entertain, though; he was anticipating serious objections about whether checksumming was worth it.

On of the major questions about such approaches is their efficiency. We have been able to include the software checksum on all packets without greatly increasing the processing overhead in the IMP. The method described above involves one checksum calculation at each IMP through which a packet travels. We developed a very fast checksum technique, which takes only 2 msec per word.

And in case the breakup of The Beatles, the Nixon presidency and the sight of a man playing golf on the moon at taxpayers' expense was not enough to convince you that, yes, it was a very different time, check out this approach to data collection:

On March 13, a new version of the IMP program was released with software checksum code. In this program, when a packet is found to have an incorrect checksum it is discarded, and a copy of the data is sent to the NCC.

Ah, the things you can do on a research network. And lastly, we have a foreshadowing of RFC 761, the first RFC to describe TCP:

Finally, we are looking into the structure of an optional IMP- Host/Host-IMP checksum to complete Host/Host end-to-end checksum. Under such an arrangement, the IMP and Host could agree to verify the checksums on the messages transferred over the interface between them, and the appropriate signalling mechanisms would be provided to handled errors. With this technique in effect, two Hosts could be certain that their messages were delivered error-free or else they would be notified of an error, and could then retransmit their message if desired.