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

[Jonathan Stone]

In message <OE594HIv6EybqfAj81E0000f5ae at hotmail.com>,

"Christopher Forsythe" writes:

>The information that is being stated seems to be all about either hardware,
>or software checksumming. The pro of hardware checksumming, as stated in
>earlier messages, is to speed up the total time of processes. The con (as
>stated earlier) is that once placed into the hardware, it cannot be fixed
>easily if broken.
>
>Software checksumming seems to have the exact opposite effect. It doesn't
>seem to affect hardware performance. But it can be fixed if the software
>doesn't seem to be working properly.
>
>The question is.... why couldn't the two be combined? 

Not to speak for David Reed or Vern Schryver, but that isn't how I see it.

What I've been trying to say is that after spending person-years
analyzing traces of damaged packets, the best model I have is that
errors at the IP or TCP/UDP/SCTP layers aren't due to line noise.
They're primarily due to memory glitches in packet-buffer memory, or
to glitches in the packet-transfer engines which move packets between
packet-buffer memory (including end-host source and sink buffers) and
the MAC/PHY-layer hardware.

I'm not worried about bugs in the outboard checksuming hardware per se.
The issue is that once the checksum computation is moved outboard,
it covers less of the end-to-end path --- and it misses part of the
path which (according to the absurldy tiny data samples which are all
we have) is an important source of packet-level errors: the path
between end-host memory and the end-host NIC.


Yes, there are good market drivers to use outboard checksumming.
What I'd ask for is a knob toy turn outboard checksums off or on,
and that the knob be off by default. That way, after an undetected error
has pervasively curdled your filesystem *and* your recent backups, you
have no-one to blame but the guy who turned the knob on.