Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!DECWRL.DEC.COM!dcrocker From: dcrocker@DECWRL.DEC.COM (David Crocker) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP Fletcher Checksum Option Message-ID: <8911302213.AA00404@volition.pa.dec.com> Date: 30 Nov 89 22:13:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 Jack, I have always had the impression that the TCP and IP checksums were intended ONLY as a backstop for the link-level checksum. The theory, as I have understood it is: If there is any interesting likelihood for data corruption, use strong, hardware-based checksum and retransmission mechanisms. This is best done at the data-link layer. For example, such corruption problems usually involve noise and are localized to a given segment; use mechanisms specific to that segment. Further, you can get more immediate response, since you do not incur the end-to-end delay before detecting and then retransmitting. The TCP and IP-level mechanism then becomes the safety valve, to catch the errors that slip in between the data-link interface cracks. This, then, justifies the requirements that the TCP and IP checksums be end-to-end and cheap in software. Hence, the question is how likely transposition is for these in-between the cracks points of exposure? Dave Brought to you by Super Global Mega Corp .com