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
- RE: [rddp] CRC mandatory? Williams, Jim
- RE: [rddp] CRC mandatory? Larsen, Roy K
- RE: [rddp] CRC mandatory? John A. Thodiyil
- RE: [rddp] CRC mandatory? Michael Krause
- RE: [rddp] CRC mandatory? Caitlin Bestler
- RE: [rddp] CRC mandatory? Michael Krause
- RE: [rddp] CRC mandatory? Carrier, John
- Re: [rddp] CRC mandatory? Jeffrey Mogul
- RE: [rddp] CRC mandatory? Somesh Gupta
- RE: [rddp] CRC mandatory? Michael Krause
- RE: [rddp] CRC mandatory? Barron, Dwight
- RE: [rddp] CRC mandatory? Somesh Gupta
- RE: [rddp] CRC mandatory? Barron, Dwight
- RE: [rddp] CRC mandatory? Somesh Gupta
- Re: [rddp] CRC mandatory? Jeffrey Mogul
- RE: [rddp] CRC mandatory? Michael Krause
- RE: [rddp] CRC mandatory? John Hufferd
- RE: [rddp] CRC mandatory? John Hufferd
- RE: [rddp] CRC mandatory? Carl Hensler
- RE: [rddp] CRC mandatory? David Ford
- RE: [rddp] CRC mandatory? Hilland, Jeff
- RE: [rddp] CRC mandatory? Barron, Dwight
- Re: [rddp] CRC mandatory? Stephen Bailey
- RE: [rddp] CRC mandatory? Williams, Jim
- [rddp] Re: Unreliable Transports (was re CRC mand… Caitlin Bestler
- RE: [rddp] CRC mandatory? Somesh Gupta
- RE: [rddp] CRC mandatory? Barron, Dwight
- RE: [rddp] CRC mandatory? Somesh Gupta