> "Louis A. Mamakos" wrote:
> >
> > >
> > > It seems to me to be kind of moot to check the same value twice, unless
> > > you suspect hardware problems. Aren't you talking about two different
> > > checks over the same data instead of checksum off-loading?
> >
> > Suspect hardware problem? Of course you should! That's why memory
> > systems have parity or ECC, and I/O buses are similarlly protected. At
> > least on real computers.
> >
> > The link-level CRC only protects the data as it goes over the link
> ^^^^^^^^^^
>
> After reading the rest of his messages, I'm not so sure, but I would
> think he was talking about _transport_ level check sum, and verifying
> that with hardward (NIC) instead of software (IP stack).
If I'm not mistaken the message that started this thread inquired
about adding an option to prevent TCP from doing a checksum, since
the fancy gigabit hardware performed reliable link-level error detection
itself. I argue that since TCP is an end-to-end transport protocol that
individual error detection on a per-hop basis is not sufficient either
theoretically or practically. My last message illustrated a number of
cases where the transport of the packet over a link was reliably
done, but the contents of the packet were corrupted by malfunctioning
software or hardware which the end-to-end TCP checksum detected.
I have less of an issue with the endpoints of the TCP connection
offloading checksum computation to the NIC card, though you're
still exposed to a certain class of error, like the PR I referenced.
The problem is what happend to your data in intermediate network
elements (routers, etc.) between the endpoints of the TCP connection.
Louis Mamakos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
