[e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything else?

[David P. Reed]

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.

- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html