Subject: [rddp] A different thought on CRCs

From: "Williams, Jim" <[email-masked]>
Date: Fri, 22 Nov 2002 15:48:55 -0500

The paper at http://citeseer.nj.nec.com/stone00when.html
is pretty sobering.  Worth reading with respect to 
better understanding CRC design tradeoffs.

It raises the question in my mind of how best to 
define the CRC to get maximum possible coverage
of RNIC internal failures as well as RNIC firmware
and hardware logical bugs.

Is there a way to move CRC computation and checking
as close to the host side as possible so as to get
maximum coverage of NIC internals?

I don't have a proposal or answer, just raising
a question.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Michael Krause <[email-masked]>
Date: Mon, 25 Nov 2002 08:52:18 -0800

>maximum coverage of NIC internals?

Where exactly is that host side?  There can be quite complex intervening 
I/O fabrics between the RNIC and the host I/O agent.  Each of these fabrics 
provide varying degrees of protection but it is not end-to-end.  Thus there 
really isn't an end-to-end argument for data integrity no matter how many 
CRC, etc. any one tries to construct; only a series of fabrics which 
provide end-to-end (optional in some technologies) within their domains and 
thus require all "middle" components, e.g. a RNIC, to protect the data 
inside its implementation.

This is the same logic as to why placement is the scheduling of data into 
endnode memory and not the actual delivery.  One cannot know the data was 
all delivered until the application provides some level of notification to 
the source.  This goes well beyond TCP end-to-end ACKs as TCP only 
guarantees the data was received but not seen by the application and thus 
applications generally implement some form of request / response protocol 
at the ULP level to ensure they can proceed knowing data was really 
delivered as required.

Mike