Garrett D'Amore writes: > On Tue, 2007-07-31 at 13:37 -0400, James Carlson wrote: > > (say) broken switches that corrupt the gate. That viewpoint (minor > > and temporary performance hack to the detriment of correctness) held > > out in UDP and, because protocols live long, we're stuck with it. > > > It seems to me that they could have figured a better way to provide this > information than by overloading the meaning of the checksum field > though... perhaps a boolean bit value somewhere in the IP flags? I > dunno, I wasn't part of the discussion.
Possibly so, but that's not what was done. > > Similarly, I don't think it's a great idea to push the end-to-end > > checksum generation or verification down into hardware that's further > > away from the endpoint, nor is it in the long term good to add more > > complexity to the system, but that's exactly what the feature we're > > talking about does. > > Nobody who cares about data integrity puts too much stock in UDP or TCP > checksum, or least they shouldn't. The checksum is incredibly fragile. > For example, swapping two bytes is a trivial way to corrupt a packet > without changing its checksum. Adding more zeros is another way. Agreed; it's imperfect. The surprising thing is that it *does* catch a number of gross errors and has done so over time. We had a spectacular incident here some years ago when a "switch" (bridge) flaked out and started mangling packets. Since most bridge designs are cavalier with the Ethernet FCS (regenerating it on transmit rather than keeping it intact; yes, I know VLANs throw a wrench in this), none of the other mechanisms detected the problem, but plain old 1s-complement checksum did it. There've been other reports of faulty DMA hardware that truncated packets as well as various software bugs that are caught by it. I agree that it's nowhere near as robust as one could design today, but it's still better than nothing. It's a "we assume everything else is working, but while we're here, we might as well check" sort of mechanism. > > I think it's a fair bet to say we'll be back here again. > > > > Maybe. The protocols are, as you say, long lived. Moving as much of > this kind of trivial work into hardware is usually a good thing. More > modern NICs are offloading more and more features, and L3/L4 checksum is > just one of them. Future generations get to pay the price and ask these same questions. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
