[e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything
David P. Reed
dpreed at reed.com
Mon Jun 11 14:27:33 PDT 2001
At 01:00 PM 6/11/01 -0700, Jonathan Stone wrote:
>But outboard checksumming is source of additional uncaught errors:
>errors which would be caught by a software implementation of
>a checksum but not by an outboard implementation of the same checksum,
>because the actual cause of the error was between the hardware checksum
>and the in-memory buffer..
>You and Vern seem to be assuming that is a rare case. The data I have
>indicates that, amonsgt the end-hosts we could directly monitor and
>caught sending errored packets, it is a common case.
I think I was being too subtle. Of course outboard checksumming is not a
good design for detecting errors. But in today's market for network
hardware, reliability has very little effect on purchasing
decisions. Price and performance matter more. So outboard checksumming,
or no checksumming at all, is going to happen if it boosts performance for
a small price. (The first part of this paraagraph may not agree with
Vernon's point of view, but I've always viewed the checksum as a check
from the point that the source process creates the data to the point that
the target process receives it. What I was agreeing with was his statement
that outboard checksumming is the certain result, driven by market forces).
If you could accelerate checksumming with inboard or outboard hardware
assist on the data as presented at the application-protocol interface, that
would be a better design than outboard checksum insertion into datagrams in
a NIC card. Thus it isn't whether the checksum is done in hardware or
software, but when the checksum is calculated and checked relative to the
steps involved in processing the packets in the protocol.
We can talk offline about blind vs. malicious adversaries and error
models. I would point out that there are many kinds of blind adversaries.
WWW Page: http://www.reed.com/dpr.html
More information about the end2end-interest