Date: Wed, 25 Mar 1998 12:55:44 -0500 (EST) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: freebsd-hackers@FreeBSD.ORG Subject: Re: ARP REQUEST question Message-ID: <Pine.SUN.3.91.980325124900.9569B-100000@terra> In-Reply-To: <E0yHry1-0004SP-00@ash2.doc.ic.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Mar 1998, Niall Smart wrote: > The "ascent" and "descent" through the protocol stacks, e.g., the > demultiplexing of an ethernet packet to IP to TCP, is done entirely in > software (or "reliable" hardware). Any corruption here is due to bugs > in the networking code which should be eliminated. The reason IP has > checksum field is that it cannot rely on the underlying network, be it > ethernet, token ring or a VPN, to reliably deliver the data. That is > the raison d'etre of TCP/IP. I don't think that is the whole story. Checksums or CRCs should be end-to-end. We've learned that the hard way often enough. Ethernet CRCs are not end-to-end. It's not an issue of reliable delivery. It's an issue of being able to detect data corruption. That's why udp checksums are always left turned on for NFS in so many sites. Niall is right that corruption "should not" happen. The real question is whether it does (and it does). So you need some sort of end-to-end checking. The first time I saw this was a router with an undetected memory error. Of course, it was in high memory, and of course, only occasionally did packets get tromped, since high memory was only used heavily under heavy offered load. Turning UDP checksums on for NFS would catch the problem, when there was enough load. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.980325124900.9569B-100000>