Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!petrus!karn
From: karn@petrus.UUCP (Phil R. Karn)
Newsgroups: net.lan
Subject: Re: Problems with IP/UDP speed on Vax75
Message-ID: <25@petrus.UUCP>
Date: Fri, 14-Feb-86 20:13:06 EST
Article-I.D.: petrus.25
Posted: Fri Feb 14 20:13:06 1986
Date-Received: Sun, 16-Feb-86 03:54:23 EST
References: <776@duvan.UUCP> <7300005@ccvaxa>
Organization: Bell Communications Research, Inc
Lines: 41

> The main reason rawIP packets are SO MUCH FASTER than UDP/IP is
> that the UDP layer does a big checksum on the entire data section.
> This can easily be turned off (even if you have binary only) by
> changing the value of a variable in the kernel called:
> 
>      "udpcksum"  (1 for checksum, 0 for no checksum)

	WARNING!   WARNING!   DANGER, WILL ROBINSON!!!!

Quoting from RFC-817, "Modularity and Efficiency in Protocol Implementation"
by David D. Clark:

"There is one area which is generally accepted as causing noticeable and
substantial overhead as part of TCP processing. This is computation of the
checksum. It would be nice if this cost could be avoided somehow, but the
idea of an end-to-end checksum is absolutely central to the functioning of
TCP.  No host implementor should think of omitting the validation of a
checksum on incoming data."

I believe this is just as valid for UDP. The Berkeley routed is a major UDP
user. It already suffers greatly from an endearing naivete regarding
incoming datagrams, and only the end-to-end checksums protect against all
hell breaking loose should an Ethernet controller, bridge, or gateway decide
to corrupt a routing (or any other) packet.  This DOES happen.  I have seen
the buffer memories go bad in an Ethernet controller. This delightful piece
of hardware would gladly corrupt received packets without notice, or garble
outgoing packets (being careful, of course, to put a perfectly valid 32-bit
CRC on the corrupted packet before sending it).

Most recently, some garbage machine names started showing up in our ruptime
listings. The problem turned out to be a flakey Ethernet bridge, and further
investigation showed that all of our SUNs had set udpcksum to zero by
default.  I immediately patched this on as many Suns as I could find,
especially those acting as IP gateways.

The "udpcksum" (and "tcpcksum") "options" in 4.2BSD are, in my opinion,
brain-damaged hacks that should be removed as soon as possible, along with
the blind acceptance of any UDP datagram or TCP segment having a zero
checksum field.

Phil Karn