RE: [rddp] CRC mandatory?

Michael Krause <krause@cup.hp.com> Tue, 06 May 2003 14:31 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24404 for <rddp-archive@odin.ietf.org>; Tue, 6 May 2003 10:31:41 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46EeBC28825 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 10:40:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46EeB828822 for <rddp-web-archive@optimus.ietf.org>; Tue, 6 May 2003 10:40:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24397 for <rddp-web-archive@ietf.org>; Tue, 6 May 2003 10:31:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D3VL-0007OL-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 10:33:15 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D3VL-0007OH-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 10:33:15 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46EdN828737; Tue, 6 May 2003 10:39:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Ecb828645 for <rddp@optimus.ietf.org>; Tue, 6 May 2003 10:38:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24328 for <rddp@ietf.org>; Tue, 6 May 2003 10:29:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D3To-0007NX-00 for rddp@ietf.org; Tue, 06 May 2003 10:31:40 -0400
Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 19D3Tk-0007NN-00 for rddp@ietf.org; Tue, 06 May 2003 10:31:36 -0400
Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id 3C5ED1C01989 for <rddp@ietf.org>; Tue, 6 May 2003 07:32:26 -0700 (PDT)
Received: from mk731915.cup.hp.com ([15.113.161.2]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id h46ESQE15078 for <rddp@ietf.org>; Tue, 6 May 2003 07:28:26 -0700 (PDT)
Message-Id: <5.1.0.14.2.20030506070121.028eb4c0@15.13.130.73>
X-Sender: krause@15.13.130.73
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 06 May 2003 07:32:20 -0700
To: rddp@ietf.org
From: Michael Krause <krause@cup.hp.com>
Subject: RE: [rddp] CRC mandatory?
In-Reply-To: <3356669BBE90C448AD4645C843E2BF289B9073@xbl.ma.emulex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>

At 05:44 PM 5/5/2003 -0400, Williams, Jim wrote:
>I don't have a major problem with mandatory
>CRCs, even if my reasons are a bit different.
>But I do want to push back on some of the arguments,
>though, to see if they hold up.
>
>Jeff Hilland wrote:
> > Caitlin brings out an excellent point below.
> > How is it that CRC32C is acceptable overhead for SCTP,
> > but it is onerous for MPA?
>
>Dwight Barron wrote:
> > Why shouldn't this place the burden of proof
> > on those who oppose mandatory CRCs?
>
>The Internet has grown from a laboritory curiosity
>to a world wide phenominon based on using 16 bit
>checksums.  SCTP, however, is not far beyond the
>labority curiosity stage at the present time.

I believe there has been a clear message delivered on the value of SCTP and 
this workgroup has stated it will define specifications to support SCTP as 
evidenced by the work done by Randall, et. al.  While I strongly support 
the TCP effort from a TTM perspective, SCTP is in the charter and our 
efforts to develop specifications to accommodate both technologies using a 
well layered architecture have been in support of that charter.

>Is the world clamoring that TCP be replaced by SCTP because TCP is 
>corrupting too much data?

The value props provided by SCTP go beyond data corruption as stated 
numerous times within the TSVWG - I don't think we need to repeat them all 
here.  The 32-bit data integrity was viewed as an important improvement 
over the existing 16-bit checksum so it should not be discounted.

>If so, SCTP should quickly become widely deployed, and RDDP should simply 
>ride this transition, and
>use SCTP.

As it has been stated during the entire 32-bit CRC debate in IPS and in 
TSVWG, there is strong motivation to providing better data integrity by 
many companies and their customers.   I have helped create new technologies 
where while the probability of data corruption is relatively small, the 
data rates combined with the impact of just one instance of data corruption 
motivated all to make data integrity (32-bit CRC) a requirement.   This is 
true for local I/O technologies (in the box) such as PCI-X 2.0 which 
provides strong ECC protection and PCI Express which has a 32-bit CRC for 
link-level (hop-by-hop) data integrity and a 32-bit CRC for end-to-end data 
integrity.  Same applies to InfiniBand where we had a 16-bit link-level and 
a 32-bit end-to-end CRCs.  All of the designers I work with across many 
companies understand the value of strong data integrity and have worked to 
make sure this is available from the start.  In one sense, the proof of 
these other specifications shows the value of data integrity in the market 
place and that the cost to implement is not viewed as onerous (PCI* 
technology will be implemented across the entire spectrum of design and 
cost points).

All of our experience to date with high-speed I/O has driven many of us to 
support a mandatory 32-bit CRC for MPA which, as John points out, enables a 
well-layered architecture with the same level of semantics delivered over 
either of the RDDP chartered transports.

>On the other hand, is TCP fine for its current
>uses, but RDDP if fundamentally different and
>requires a higher level of data integrity?

Yes.  TCP implementations target anonymous buffers using local memory 
translations which are not known in the wire.  RDDP uses TO and STag to 
determine the target buffering thus there is the potential for silent data 
corruption from a corruption in the header.  The argument for having a 
single CRC for header / data is that one MUST validate the transport 
checksums which covers the entire payload (RDDP headers and data) prior to 
placement thus a single CRC can be done in parallel and validated at the 
end of the chunk / frame.

>This seems like a difficult case to make given the wide spread use of NFS 
>and CIFS over TCP. Is silent data corruption over RDDP worse than silent 
>data corruption over NFS or CIFS?

Yes.  As noted above.  NFS / CIFS all use anonymous buffers thus there data 
integrity is only impacting their own buffers which isn't guaranteed to be 
true for all RDDP operations.

>Is there a push to add more data integrity to NFS?  If not, then this 
>seems to add credibility to the case that TCP as is provides sufficient 
>data integrity in many cases.

NFS has additional data integrity as an option.  Whether people push to 
deploy is an orthogonal issue.  For many years people did not use the 
existing NFS data integrity methods which were just a checksum using 
similar logic as you but now they always use the base integrity methods.

>Sould RDDP to take the position that TCP is so deficient in data integrity 
>that to NOT use a CRC is irresponsible and therefore the CRC must be 
>mandated?

It is irresponsible for the reasons I've listed above and as noted in the 
other workgroups where this was heavily debated before.

>Are there any other protocols layered on TCP that are a precedent for 
>this?   The CRC for iSCSI is optional.  Given that RDDP proposes something 
>new, I would submit that the burden or proof would be on those supporting 
>mandatory CRC.

The iSCSI CRC being optional was based on discussions that a lower layer 
could provide data integrity, e.g. IPSec can be used to provide strong 
end-to-end data integrity thus many felt they'd rather spend their 
resources on a single pass of the data rather than multiple passes in order 
to deliver good performance (applies to both software and hardware 
implementations).  I don't recall anyone on IPS stating that they would be 
happy using just checksums or that they would be happy for all time without 
providing the ability to provide strong data integrity.

>Because SCTP uses a CRC, it is suggested that that proves a CRC is not too 
>onerous to add to a protocol layered on TCP.

It is not from an implementation perspective.

>This seems a stretch in a couple respects. One being that two data checks 
>are more expensive than one

A software or hardware implementation may make a single pass of the data 
with minimal overhead to calculate (TCP case) the checksum and CRC.  This 
is not viewed as onerous or that expensive to implement though there is a 
slight cost.

>  and not justified if the first (TCP checksum) is sufficient.

It is not viewed as sufficient by many people in this workgroup as well as 
IPS and TSVWG from my recollection of the previous debates on the need for 
strong data integrity.

>Second, the jury is still out on SCTP in a number of respects.  And RDDP 
>is  arguable targetted towards performance critical applications more so 
>than SCTP.

I will not attempt to categorize SCTP usage as focused on performance or 
not.  There is nothing that I have read that would preclude performance 
focused solutions thus I do not concur that RDDP (which has a clear charter 
to support SCTP) should have what is currently a cleanly, well-layered 
architecture permuted to be transport specific when it is not called for by 
any argument presented to date.  RDMAP and DDP layer on top of SCTP or MPA 
in a very clean and precise manner thus allowing simpler implementations 
and future opportunities to leverage all of the work done above the 
transport / framing mechanisms.  I view this as just as important a benefit 
as anything from a technical perspective.  Creating additional options that 
have very little if any value to the protocol suite only creates legacy 
inertia and will slow adoption of this technology.   Given the economic 
conditions, the costs of adding options into solutions (we have already 
debated this), etc. I do not agree with any of your assertions or your 
request to place "the burden of proof" on those that support mandatory CRC 
as though the case of mandatory has not already been made in other 
workgroups within the IETF.

Mike

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp