From mailnull@www1.ietf.org Thu May 1 16:49:39 2003 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 QAA10411 for ; Thu, 1 May 2003 16:49:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Kto708343 for rddp-archive@odin.ietf.org; Thu, 1 May 2003 16:55:50 -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 h41Kto808340 for ; Thu, 1 May 2003 16:55:50 -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 QAA10379 for ; Thu, 1 May 2003 16:49:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BL1T-0006gs-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 16:51:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BL1S-0006gn-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 16:51:18 -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 h41Kt5808316; Thu, 1 May 2003 16:55:05 -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 h41Ks2808262 for ; Thu, 1 May 2003 16:54:02 -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 QAA10233 for ; Thu, 1 May 2003 16:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BKzU-0006eR-00 for rddp@ietf.org; Thu, 01 May 2003 16:49:16 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 19BKzO-0006ds-00 for rddp@ietf.org; Thu, 01 May 2003 16:49:10 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 1 May 2003 13:48:29 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 May 2003 13:48:29 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 May 2003 13:48:28 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 May 2003 13:48:28 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 1 May 2003 13:48:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rddp] Marker Consensus Proposal Date: Thu, 1 May 2003 13:48:27 -0700 Message-ID: Thread-Topic: [rddp] Marker Consensus Proposal Thread-Index: AcMLTo3/9NLpd7Q0TyevMaoK9NxgegEsXv5g From: "Jim Pinkerton" To: , X-OriginalArrivalTime: 01 May 2003 20:48:27.0979 (UTC) FILETIME=[045FC1B0:01C31023] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41Ks2808263 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit After lengthy discussion, I have to agree that this seems to strike the right balance between flexibility and allowing the receiver to maintain the ability to optimize. Jim -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, April 25, 2003 9:41 AM To: rddp@ietf.org Subject: [rddp] Marker Consensus Proposal WG Chair hat firmly in place ... Looking back on the discussion of markers, I'm going to attempt to propose a way forward and hope the we can get WG rough consensus for it. The core of the proposal is what I originally posted a couple of weeks ago: Make marker usage OPTIONAL, but put control of this option entirely in the hands of the receiver - senders MUST implement both markers and not-markers, receivers MUST implement one OR the other, and each receiver gets to pick which one is used as the benefits of markers are primarily on the receiver side. With the following additions: - When markers are used, the marker interval MUST be 512 bytes. - This proposed rough consensus assumes that we will be forced to do some sort of setup announcement as part of the "proof" requirement, which will provide a place to transmit options (and a version number). Details of exactly how this works so that each receiver gets to pick what is sent to it are TBD. This is not going to be the "perfect" answer for everyone, but it's clear to me that WG rough consensus will not be obtained for the positions at the end of the spectrum, namely: - 512 byte markers MUST be used at all times - Markers are completely optional Further discussion/advocacy of those positions is probably not productive. I believe the above proposal is acceptable for the important classes of implementations, and is technically sound. Further comment to the list, please. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 1 17:55:48 2003 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 RAA13738 for ; Thu, 1 May 2003 17:55:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41M21Q13538 for rddp-archive@odin.ietf.org; Thu, 1 May 2003 18:02:01 -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 h41M21813535 for ; Thu, 1 May 2003 18:02:01 -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 RAA13712 for ; Thu, 1 May 2003 17:55:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BM3U-0007OH-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 17:57:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BM3T-0007OE-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 17:57:27 -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 h41M1G813461; Thu, 1 May 2003 18:01:16 -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 h41M0n813361 for ; Thu, 1 May 2003 18:00:49 -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 RAA13519 for ; Thu, 1 May 2003 17:51:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BLzy-0007Kp-00 for rddp@ietf.org; Thu, 01 May 2003 17:53:50 -0400 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx with esmtp (Exim 4.12) id 19BLzs-0007He-00 for rddp@ietf.org; Thu, 01 May 2003 17:53:45 -0400 Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.12.9/8.12.8) with ESMTP id h41LomLW022498 for ; Thu, 1 May 2003 14:50:48 -0700 (PDT) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 May 2003 17:50:47 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF289B906C@xbl.ma.emulex.com> From: "Williams, Jim" To: rddp@ietf.org Subject: RE: [rddp] Header CRC mandatory? Date: Thu, 1 May 2003 17:50:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , I am not fully convinced either way as to whether CRC should be optional or mandatory. I have seen some arguments for mandatory CRCs that I personally find less that persuasive. This would include the following. 1. Users want the same level of protection for both TCP and SCTP. Why? Users want sufficient protection to insure that silent data corruption does not occur. Naive expectation would be that TCP provides 16 bit checksum and SCTP provides 32 bit CRC. Which is required depends on deployment. If you really want the same, then SCTP should include a 16 bit checksum in the RDDP mapping layer so that both TCP and SCTP will have the combined protection of both a 32 bit CRC and a 16 bit checksum. 2. Performance of software implementations is not important since most all implementations, or at least most all implementations caring about performance, will use hardware acceleration. This argument seems plausible, but also seems contrary to a previous consensus that software implementations were important and should not be short changed. 3. Overhead to negotiate options is too onerous. Mechanisms need to be fully defined, but I think there needs to be a round trip to negotiate use of RDDP in the first place, so piggy-backing additional negotiation items should have small incremental cost. If connection is born in RDDP mode by use of well known port, then option negotiation could be piggy-backed on TCP SYN packets. The following arguments have some merit, but I would like to see more data to back them up. 4. CRCs are not very hard to calculate in software. They do not require an additional data touch. What is the overhead of a typical software TCP stack? For sake of argument, assume NIC offload of checksum calculations. What is the overhead of a CRC computation? How do these two numbers compare (on a per byte basis). My guess is that they are the same order of magnitude which would mean that CRC computation is certainly not negligible. But I could be wrong. As to no additional data touch, that seems possible with an integrated implementation. Not sure how that could work with a layered implementation of new RDDP code on top of existing TCP/IP implementation. The latter seems like an important, if not more likely, scenario. 5. TCP checksum provides inadequate coverage to guarantee correctness. This is certainly true in some cases. Is it true in most all cases? Most common case for deployment of RDDP likely to be two endpoints on the same LAN with one or two switches between. Is TCP checksum alone inadequate in this case given the link CRC? My guess is that TCP checksum is adequate for this case, but more data to shed light on this would be helpful. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 1 18:16:33 2003 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 SAA15742 for ; Thu, 1 May 2003 18:16:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41MMlp15155 for rddp-archive@odin.ietf.org; Thu, 1 May 2003 18:22:47 -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 h41MMl815152 for ; Thu, 1 May 2003 18:22:47 -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 SAA15735 for ; Thu, 1 May 2003 18:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BMNZ-0007cL-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 18:18:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BMNY-0007cI-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 18:18:12 -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 h41MM1815129; Thu, 1 May 2003 18:22:01 -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 h41MLG815111 for ; Thu, 1 May 2003 18:21:16 -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 SAA15545 for ; Thu, 1 May 2003 18:14:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BMLr-0007b1-00 for rddp@ietf.org; Thu, 01 May 2003 18:16:27 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19BMLl-0007Zs-00 for rddp@ietf.org; Thu, 01 May 2003 18:16:22 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 35955244E9E; Thu, 1 May 2003 18:15:48 -0400 (EDT) Date: Thu, 1 May 2003 17:18:13 -0500 From: Caitlin Bestler Subject: RE: [rddp] Header CRC mandatory? To: "Williams, Jim" Cc: rddp@ietf.org X-Priority: 3 In-Reply-To: <3356669BBE90C448AD4645C843E2BF289B906C@xbl.ma.emulex.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/1/03, Williams, Jim wrote: > 5. TCP checksum provides inadequate coverage to > guarantee correctness. This is certainly true > in some cases. Is it true in most all cases? > Most common case for deployment of RDDP likely to > be two endpoints on the same LAN with > one or two switches between. Is TCP checksum > alone inadequate in this case given the link CRC? > My guess is that TCP checksum is adequate for > this case, but more data to shed light on this > would be helpful. Optimizing MPA for deployment within a data center, or other environment with a minimal number of known network elements, strikes me as fundamemtally wrong. The first and foremost reason is that in an environment where there are only a handful of known network elements the transport that SHOULD be used is SCTP. There are many market driven reasons for using TCP rather than SCTP. But to date the only *technically* valid reason I am aware of is to ensure interoperability with unknown already deployed network elements that are SCTP incompatible. In particular, the millions of home firewalls are amost never SCTP compatible. It is unreasonable to define a new service that requires end consumers to upgrade their routers or switches. Expecting a data center to upgrade the firmware on a handful of in-house switches is quite a bit more reasonable. If we were to design RDDP on the assumption of data center deployment, then I believe there is stronger argumenet for why TCP should not be a supported transport at all. The justification for TCP is its compatability with older, widely deployed, networking elements. Especially those that do not have system administrators willing or able to upgrade the firmware. And it is exactly such old, and typically cheap, network elements that probably provide the strongest justification for end-to-end protection. Not to imply criticism for any specific companies or products, but do you really expect five nines quality for something that was in a clearance box for $39.99? Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 1 18:43:45 2003 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 SAA17155 for ; Thu, 1 May 2003 18:43:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Mnxd17280 for rddp-archive@odin.ietf.org; Thu, 1 May 2003 18:49:59 -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 h41Mnx817277 for ; Thu, 1 May 2003 18:49:59 -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 SAA17119 for ; Thu, 1 May 2003 18:43:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BMnt-00007r-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 18:45:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BMns-00007n-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 18:45:24 -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 h41Mn2817241; Thu, 1 May 2003 18:49:02 -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 h41MmM817209 for ; Thu, 1 May 2003 18:48:22 -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 SAA17080 for ; Thu, 1 May 2003 18:41:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BMmK-000079-00 for rddp@ietf.org; Thu, 01 May 2003 18:43:48 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19BMmE-00006y-00 for rddp@ietf.org; Thu, 01 May 2003 18:43:42 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 0A124244BCE; Thu, 1 May 2003 18:44:02 -0400 (EDT) Date: Thu, 1 May 2003 17:46:26 -0500 From: Caitlin Bestler Subject: RE: [rddp] Header CRC mandatory? To: "Williams, Jim" Cc: rddp@ietf.org X-Priority: 3 In-Reply-To: <3356669BBE90C448AD4645C843E2BF289B906C@xbl.ma.emulex.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/1/03, Williams, Jim wrote: > 1. Users want the same level of protection for > both TCP and SCTP. > > Why? Users want sufficient protection to > insure that silent data corruption does not > occur. Naive expectation would be that > TCP provides 16 bit checksum and SCTP provides > 32 bit CRC. Which is required depends on > deployment. If you really want the same, > then SCTP should include a 16 bit checksum > in the RDDP mapping layer so that both > TCP and SCTP will have the combined protection > of both a 32 bit CRC and a 16 bit checksum. > > I doubt that the 16 bit TCP checksum adds much "value" beyond the CRC32c. The concern of providing different levels of protection is that it will de facto encourage ULPs to design on the assumption of TCP's weak protection. Ultimately that makes the added protection from SCTP a redundant cost, which could ultimately cited as a reason against deploying it. I believe that designing RDDP in a way that penalized users of SCTP would be contrary to the intent and direction of the Transport Area WG. > 2. Performance of software implementations is > not important since most all implementations, > or at least most all implementations caring > about performance, will use hardware acceleration. > > This argument seems plausible, but also seems > contrary to a previous consensus that > software implementations were important and > should not be short changed. > Agreed. > > 3. Overhead to negotiate options is too onerous. > > Mechanisms need to be fully defined, but I think > there needs to be a round trip to negotiate use > of RDDP in the first place, so piggy-backing > additional > negotiation items should have small incremental > cost. If connection is born in RDDP mode by > use of well known port, then option negotiation > could be piggy-backed on TCP SYN packets. Agreed. A mode indicator, not necessarily a round trip, is a given based upon points in the consensus (mode matching and marker mode). So clearly a sender based option on what CRCs it would be providing would be trivial. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 1 19:49:16 2003 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 TAA18696 for ; Thu, 1 May 2003 19:49:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41NrsB20972 for rddp-archive@odin.ietf.org; Thu, 1 May 2003 19:53:54 -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 h41Nrr820969 for ; Thu, 1 May 2003 19:53:53 -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 TAA18650 for ; Thu, 1 May 2003 19:47:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BNni-0000Sp-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 19:49:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BNnh-0000Sm-00 for rddp-web-archive@ietf.org; Thu, 01 May 2003 19:49:17 -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 h41Nr6820950; Thu, 1 May 2003 19:53:06 -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 h41Nq2820903 for ; Thu, 1 May 2003 19:52:02 -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 TAA18644; Thu, 1 May 2003 19:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BNlf-0000Sg-00; Thu, 01 May 2003 19:47:11 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19BNlP-0000SX-00; Thu, 01 May 2003 19:46:55 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h41NkGkc237586; Thu, 1 May 2003 19:46:16 -0400 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h41NkGxe138084; Thu, 1 May 2003 17:46:16 -0600 To: Black_David@emc.com, rddp@ietf.org, rddp-admin@ietf.org MIME-Version: 1.0 Subject: RE: [rddp] Marker Consensus Proposal X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Thu, 1 May 2003 16:46:14 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/01/2003 17:46:15, Serialize complete at 05/01/2003 17:46:15 Content-Type: multipart/alternative; boundary="=_alternative 0082919388256D19_=" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0082919388256D19_= Content-Type: text/plain; charset="us-ascii" I also agree with this. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Jim Pinkerton" Sent by: rddp-admin@ietf.org 05/01/2003 01:48 PM To: , cc: Subject: RE: [rddp] Marker Consensus Proposal After lengthy discussion, I have to agree that this seems to strike the right balance between flexibility and allowing the receiver to maintain the ability to optimize. Jim -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, April 25, 2003 9:41 AM To: rddp@ietf.org Subject: [rddp] Marker Consensus Proposal WG Chair hat firmly in place ... Looking back on the discussion of markers, I'm going to attempt to propose a way forward and hope the we can get WG rough consensus for it. The core of the proposal is what I originally posted a couple of weeks ago: Make marker usage OPTIONAL, but put control of this option entirely in the hands of the receiver - senders MUST implement both markers and not-markers, receivers MUST implement one OR the other, and each receiver gets to pick which one is used as the benefits of markers are primarily on the receiver side. With the following additions: - When markers are used, the marker interval MUST be 512 bytes. - This proposed rough consensus assumes that we will be forced to do some sort of setup announcement as part of the "proof" requirement, which will provide a place to transmit options (and a version number). Details of exactly how this works so that each receiver gets to pick what is sent to it are TBD. This is not going to be the "perfect" answer for everyone, but it's clear to me that WG rough consensus will not be obtained for the positions at the end of the spectrum, namely: - 512 byte markers MUST be used at all times - Markers are completely optional Further discussion/advocacy of those positions is probably not productive. I believe the above proposal is acceptable for the important classes of implementations, and is technically sound. Further comment to the list, please. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --=_alternative 0082919388256D19_= Content-Type: text/html; charset="us-ascii"
I also agree with this.

.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Jim Pinkerton" <jpink@windows.microsoft.com>
Sent by: rddp-admin@ietf.org

05/01/2003 01:48 PM

       
        To:        <Black_David@emc.com>, <rddp@ietf.org>
        cc:        
        Subject:        RE: [rddp] Marker Consensus Proposal




After lengthy discussion, I have to agree that this seems to strike the
right balance between flexibility and allowing the receiver to maintain
the ability to optimize.



Jim




-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, April 25, 2003 9:41 AM
To: rddp@ietf.org
Subject: [rddp] Marker Consensus Proposal

WG Chair hat firmly in place ...

Looking back on the discussion of markers, I'm going to attempt
to propose a way forward and hope the we can get WG rough consensus
for it.  The core of the proposal is what I originally posted a
couple of weeks ago:

                Make marker usage OPTIONAL,
                but put control of this option entirely in the hands of
                the receiver - senders MUST implement both markers and
not-markers,
                receivers MUST implement one OR the other, and each receiver
                gets to pick which one is used as the benefits of markers are
                primarily on the receiver side.

With the following additions:
- When markers are used, the marker interval MUST be 512 bytes.
- This proposed rough consensus assumes that we will be forced
                to do some sort of setup announcement as part of the
                "proof" requirement, which will provide a place to
                transmit options (and a version number).  Details of
                exactly how this works so that each receiver gets to
                pick what is sent to it are TBD.

This is not going to be the "perfect" answer for everyone, but
it's clear to me that WG rough consensus will not be obtained
for the positions at the end of the spectrum, namely:

- 512 byte markers MUST be used at all times
- Markers are completely optional

Further discussion/advocacy of those positions is probably
not productive.

I believe the above proposal is acceptable for the important
classes of implementations, and is technically sound.

Further comment to the list, please.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

--=_alternative 0082919388256D19_=-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 2 00:52:37 2003 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 AAA24613 for ; Fri, 2 May 2003 00:52:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h424wx907503 for rddp-archive@odin.ietf.org; Fri, 2 May 2003 00:58:59 -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 h424wx807500 for ; Fri, 2 May 2003 00:58:59 -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 AAA24608 for ; Fri, 2 May 2003 00:52:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BSYr-0001z7-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 00:54:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BSYq-0001z4-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 00:54:16 -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 h424wA807483; Fri, 2 May 2003 00:58:10 -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 h424ve807455 for ; Fri, 2 May 2003 00:57:40 -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 AAA24559 for ; Fri, 2 May 2003 00:50:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BSXL-0001yX-00 for rddp@ietf.org; Fri, 02 May 2003 00:52:43 -0400 Received: from magic-mail.adaptec.com ([208.236.45.100] helo=magic.adaptec.com) by ietf-mx with esmtp (Exim 4.12) id 19BSXG-0001y6-00 for rddp@ietf.org; Fri, 02 May 2003 00:52:38 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h424n6Z09742 for ; Thu, 1 May 2003 21:49:06 -0700 Received: from aimexc07.adaptec.com (aimexc07.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id VAA16198 for ; Thu, 1 May 2003 21:52:09 -0700 (PDT) Received: by aimexc07.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 May 2003 21:52:08 -0700 Message-ID: From: "Carrier, John" To: rddp@ietf.org Subject: RE: [rddp] Header CRC mandatory? Date: Thu, 1 May 2003 21:52:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , On 5/1/03 Jim Williams wrote : > > 1. Users want the same level of protection for > both TCP and SCTP. > > Why? Users want sufficient protection to > insure that silent data corruption does not > occur. Naive expectation would be that > TCP provides 16 bit checksum and SCTP provides > 32 bit CRC. Which is required depends on > deployment. If you really want the same, > then SCTP should include a 16 bit checksum > in the RDDP mapping layer so that both > TCP and SCTP will have the combined protection > of both a 32 bit CRC and a 16 bit checksum. > > Adding additional CRCs or checksums to DDP does not make sense when SCTP already has 32 bit CRC protection. The layering of DDP over its LLP (SCTP or TCP) is cleaner if the CRC is all done at the LLP. Since SCTP already has a CRC, that meant adding a CRC to MPA. As a result, there are no LLP-specific options inside DDP--the same definition of DDP is valid over SCTP as well as TCP/MPA. --jc _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 2 10:01:22 2003 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 KAA14474 for ; Fri, 2 May 2003 10:01:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42E7uG24383 for rddp-archive@odin.ietf.org; Fri, 2 May 2003 10:07:56 -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 h42E7u824380 for ; Fri, 2 May 2003 10:07:56 -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 KAA14445 for ; Fri, 2 May 2003 10:00:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bb7u-0004SV-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 10:03:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bb7t-0004SL-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 10:03:01 -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 h42E76823691; Fri, 2 May 2003 10:07:06 -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 h42E5x823454 for ; Fri, 2 May 2003 10:05:59 -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 JAA14369 for ; Fri, 2 May 2003 09:58:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bb5n-0004RX-00 for rddp@ietf.org; Fri, 02 May 2003 10:00:51 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19Bb5S-0004QN-00 for rddp@ietf.org; Fri, 02 May 2003 10:00:30 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 25CEC9AC5; Fri, 2 May 2003 08:59:17 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 2 May 2003 08:59:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] Marker Consensus Proposal Date: Fri, 2 May 2003 08:59:16 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F872403143161@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] Marker Consensus Proposal Thread-Index: AcMLTo3/9NLpd7Q0TyevMaoK9NxgegEsXv5gACxPZuA= From: "Barron, Dwight" To: "Jim Pinkerton" , , X-OriginalArrivalTime: 02 May 2003 13:59:17.0031 (UTC) FILETIME=[05482370:01C310B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42E6T823476 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I also agree this is a reasonable compromise. It allows each vendor to implement the design they think best matches market needs while establishing a solid interoperability requirement for all implementations. However, I had previously posted a concern that this compromise still might not meet the needs of the not-markers camp and I don't recall seeing any comments one way or the other. Explicit feedback would be appreciated. Regards, Dwight > -----Original Message----- > From: Jim Pinkerton [mailto:jpink@windows.microsoft.com] > Sent: Thursday, May 01, 2003 3:48 PM > To: Black_David@emc.com; rddp@ietf.org > Subject: RE: [rddp] Marker Consensus Proposal > > > > After lengthy discussion, I have to agree that this seems to > strike the > right balance between flexibility and allowing the receiver > to maintain > the ability to optimize. > > > > Jim > > > > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, April 25, 2003 9:41 AM > To: rddp@ietf.org > Subject: [rddp] Marker Consensus Proposal > > WG Chair hat firmly in place ... > > Looking back on the discussion of markers, I'm going to attempt > to propose a way forward and hope the we can get WG rough consensus > for it. The core of the proposal is what I originally posted a > couple of weeks ago: > > Make marker usage OPTIONAL, > but put control of this option entirely in the hands of > the receiver - senders MUST implement both markers and > not-markers, > receivers MUST implement one OR the other, and each receiver > gets to pick which one is used as the benefits of markers are > primarily on the receiver side. > > With the following additions: > - When markers are used, the marker interval MUST be 512 bytes. > - This proposed rough consensus assumes that we will be forced > to do some sort of setup announcement as part of the > "proof" requirement, which will provide a place to > transmit options (and a version number). Details of > exactly how this works so that each receiver gets to > pick what is sent to it are TBD. > > This is not going to be the "perfect" answer for everyone, but > it's clear to me that WG rough consensus will not be obtained > for the positions at the end of the spectrum, namely: > > - 512 byte markers MUST be used at all times > - Markers are completely optional > > Further discussion/advocacy of those positions is probably > not productive. > > I believe the above proposal is acceptable for the important > classes of implementations, and is technically sound. > > Further comment to the list, please. > > Thanks, > --David > > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 2 10:38:21 2003 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 KAA16513 for ; Fri, 2 May 2003 10:38:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42Eist27132 for rddp-archive@odin.ietf.org; Fri, 2 May 2003 10:44:54 -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 h42Eis827129 for ; Fri, 2 May 2003 10:44:54 -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 KAA16499 for ; Fri, 2 May 2003 10:37:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bbhf-0004fG-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 10:39:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bbhf-0004f5-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 10:39:59 -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 h42Ei6827066; Fri, 2 May 2003 10:44:06 -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 h42Ehq827015 for ; Fri, 2 May 2003 10:43:52 -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 KAA16452 for ; Fri, 2 May 2003 10:36:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bbgg-0004eI-00 for rddp@ietf.org; Fri, 02 May 2003 10:38:58 -0400 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bbga-0004cx-00 for rddp@ietf.org; Fri, 02 May 2003 10:38:52 -0400 Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.12.9/8.12.8) with ESMTP id h42EcbLW004061 for ; Fri, 2 May 2003 07:38:38 -0700 (PDT) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 May 2003 10:38:37 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF289B906D@xbl.ma.emulex.com> From: "Williams, Jim" To: rddp@ietf.org Subject: RE: [rddp] Header CRC mandatory? Date: Fri, 2 May 2003 10:38:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Caitlin Bestler wrote: > On 5/1/03, Williams, Jim wrote: > > > 1. Users want the same level of protection for > > both TCP and SCTP. > > > > [...] If you really want the same, > > then SCTP should include a 16 bit checksum > > in the RDDP mapping layer so that both > > TCP and SCTP will have the combined protection > > of both a 32 bit CRC and a 16 bit checksum. > > > > > I doubt that the 16 bit TCP checksum adds much "value" > beyond the CRC32c. I agree. That was my point. If you are not getting CRC escapes, then the 16 bit checksum will catch no errors. (Hypothetically if you were getting CRC escapes, the checksum would have a high probability of catching them.) Likewise if you are not getting TCP checksum escapes, then the MPA layer CRC adds no value. > The concern of providing different levels of protection > is that it will de facto encourage ULPs to design on > the assumption of TCP's weak protection. This might be splitting hairs, but I regard this as one level of protection (the transport plus RDDP WILL be reliable), with an optional number of bits used to get this level of protection. If the CRC were mandatory to implement and optional to use, ULPs will treat the transport as reliable. A more difficult question is how would use of CRC be negotiated? Neither the RDDP layer or the ULP layer will know whether a CRC is needed for a particular network configuration. This punts it all the way up to the system administrator to decide and configure, which is usually not a good thing. Perhaps a compromise position here would be that CRC (both header and payload) are always used UNLESS one end requests no CRCs, and the other end consents. The effectively makes no-CRC mode optional to implement. But it at least creates the negotiation mechanism in case there is market demand for this. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 2 10:47:27 2003 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 KAA16736 for ; Fri, 2 May 2003 10:47:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42Es1C27571 for rddp-archive@odin.ietf.org; Fri, 2 May 2003 10:54:01 -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 h42Es0827566 for ; Fri, 2 May 2003 10:54:00 -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 KAA16728 for ; Fri, 2 May 2003 10:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BbqU-0004hy-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 10:49:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BbqT-0004hv-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 10:49:05 -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 h42Er6827509; Fri, 2 May 2003 10:53:06 -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 h42Eqk827487 for ; Fri, 2 May 2003 10:52:47 -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 KAA16701 for ; Fri, 2 May 2003 10:45:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BbpI-0004hP-00 for rddp@ietf.org; Fri, 02 May 2003 10:47:52 -0400 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx with esmtp (Exim 4.12) id 19BbpC-0004hC-00 for rddp@ietf.org; Fri, 02 May 2003 10:47:46 -0400 Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.12.9/8.12.8) with ESMTP id h42ElnLW004169 for ; Fri, 2 May 2003 07:47:49 -0700 (PDT) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 May 2003 10:47:48 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF289B906E@xbl.ma.emulex.com> From: "Williams, Jim" To: rddp@ietf.org Subject: RE: [rddp] Marker Consensus Proposal Date: Fri, 2 May 2003 10:47:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Barron, Dwight [mailto:Dwight.Barron@hp.com] > Sent: Friday, May 02, 2003 9:59 AM > To: Jim Pinkerton; Black_David@emc.com; rddp@ietf.org > Subject: RE: [rddp] Marker Consensus Proposal > > > I also agree this is a reasonable compromise. It allows each > vendor to implement the design they think best matches market > needs while establishing a solid interoperability requirement > for all implementations. However, I had previously posted a > concern that this compromise still might not meet the needs > of the not-markers camp and I don't recall seeing any > comments one way or the other. Explicit feedback would be > appreciated. > > Regards, > Dwight I don't presume to speak for any "camp", not even the Emulex camp. But, personally, I would strongly support this consensus proposal. I believe it achieves the objective of allowing implementation and deployment experience to sort out value of markers. - Jim Williams _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 2 14:09:29 2003 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 OAA23717 for ; Fri, 2 May 2003 14:09:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42IG7213104 for rddp-archive@odin.ietf.org; Fri, 2 May 2003 14:16:07 -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 h42IG7813101 for ; Fri, 2 May 2003 14:16:07 -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 OAA23702 for ; Fri, 2 May 2003 14:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bf00-0006Gb-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 14:11:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bf00-0006GT-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 14:11:08 -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 h42IF4813052; Fri, 2 May 2003 14:15:04 -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 h42IEx813030 for ; Fri, 2 May 2003 14:14:59 -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 OAA23664 for ; Fri, 2 May 2003 14:07:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Beyf-0006Fp-00 for rddp@ietf.org; Fri, 02 May 2003 14:09:45 -0400 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 19BeyZ-0006FZ-00 for rddp@ietf.org; Fri, 02 May 2003 14:09:39 -0400 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Fri, 02 May 2003 10:57:35 -0700 Received: from nt-irva-0740.brcm.ad.broadcom.com ([10.8.194.53]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA06065; Fri, 2 May 2003 10:57:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] Marker Consensus Proposal Date: Fri, 2 May 2003 10:56:38 -0700 Message-ID: Thread-Topic: [rddp] Marker Consensus Proposal Thread-Index: AcMLS4iLq9t3z0ZFRvqyf9tzha2PFgFiAePw From: "Uri Elzur" To: Black_David@emc.com, rddp@ietf.org X-WSS-ID: 12AC6E053114601-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42IEx813031 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit David In order to allow the group to make forward progress, I'd support your call below. It allows for more efficient implementations to exist and to interoperate with other implementations. It also narrows down the number of options the implementer need to worry about, obviously good news. Our challenge going forward is to make sure we do not burden high speed implementations with a lengthy prologue. Uri -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, April 25, 2003 9:41 AM To: rddp@ietf.org Subject: [rddp] Marker Consensus Proposal WG Chair hat firmly in place ... Looking back on the discussion of markers, I'm going to attempt to propose a way forward and hope the we can get WG rough consensus for it. The core of the proposal is what I originally posted a couple of weeks ago: Make marker usage OPTIONAL, but put control of this option entirely in the hands of the receiver - senders MUST implement both markers and not-markers, receivers MUST implement one OR the other, and each receiver gets to pick which one is used as the benefits of markers are primarily on the receiver side. With the following additions: - When markers are used, the marker interval MUST be 512 bytes. - This proposed rough consensus assumes that we will be forced to do some sort of setup announcement as part of the "proof" requirement, which will provide a place to transmit options (and a version number). Details of exactly how this works so that each receiver gets to pick what is sent to it are TBD. This is not going to be the "perfect" answer for everyone, but it's clear to me that WG rough consensus will not be obtained for the positions at the end of the spectrum, namely: - 512 byte markers MUST be used at all times - Markers are completely optional Further discussion/advocacy of those positions is probably not productive. I believe the above proposal is acceptable for the important classes of implementations, and is technically sound. Further comment to the list, please. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 2 17:02:41 2003 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 RAA02628 for ; Fri, 2 May 2003 17:02:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42L9M128541 for rddp-archive@odin.ietf.org; Fri, 2 May 2003 17:09:22 -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 h42L9M828538 for ; Fri, 2 May 2003 17:09:22 -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 RAA02619 for ; Fri, 2 May 2003 17:02:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bhhb-00008c-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 17:04:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bhhb-00008Y-00 for rddp-web-archive@ietf.org; Fri, 02 May 2003 17:04:19 -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 h42L87828453; Fri, 2 May 2003 17:08:07 -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 h42L78827636 for ; Fri, 2 May 2003 17:07:08 -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 QAA02526 for ; Fri, 2 May 2003 16:59:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BhfD-00007K-00 for rddp@ietf.org; Fri, 02 May 2003 17:01:51 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19Bhes-00006p-00 for rddp@ietf.org; Fri, 02 May 2003 17:01:30 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E2AA2B4C3; Fri, 2 May 2003 16:00:56 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 2 May 2003 16:00:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] Header CRC mandatory? Date: Fri, 2 May 2003 16:00:54 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F872403143162@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] Header CRC mandatory? Thread-Index: AcMQLibRPGserZ64RHuWK7atRosM7gAktbmA From: "Barron, Dwight" To: "Williams, Jim" , X-OriginalArrivalTime: 02 May 2003 21:00:55.0159 (UTC) FILETIME=[EC242070:01C310ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42L7N828108 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, I would propose the following counter arguments: A. I have not heard anyone proposing a 16-bit checksum for hardware centric implementations of any ilk in the last decade, which is less complex than a 32-bit CRC, even in hardware. This would include ethernet, FC, all flavors of VI of which I am aware, InfiniBand, IEEE-1394 and USB. To me, this implies that CRC is a comfortable baseline for data integrity, 16-bit checksums are not, even in the most high-volume, cost-sensitive environments like USB. B. A chain is only as strong as its weakest link. I do not believe it appropriate to declare that ethernet's MAC CRC + TCP checksum is almost equal to an end-end CRC. The end-end integrity is that which can be guaranteed and delivered by the end-end digest method. As Caitlin pointed out, there is no shortage of low cost intermediary devices to mitigate any extra data integrity the MAC layer might provide. C. I agree that software implementations of RDDP are important and personally weight them as extremely important. Transmitter alignment is case in point where we have agreed to make changes to accommodate the widest latitude of RDDP software implementations. However, SCTP has set the precedence that mandatory CRCs are not prohibitive and do not short-change software implementations. I believe that A, B, and C taken together point to established industry practice that clearly leans towards CRC over checksum for data integrity, despite the extra complexity/cost/overhead of implementation. Why shouldn't this place the burden of proof on those who oppose mandatory CRCs? That said, what would be the success criteria of number 4 below that would sway your opinion to be in favor of mandatory CRCs? I infer from your comments that CRC generation being on the same order of magnitude as the TCP stack is too much, zero CRC software overhead is impossible, what is acceptable? Regards, Dwight > -----Original Message----- > From: Williams, Jim [mailto:Jim.Williams@emulex.com] > Sent: Thursday, May 01, 2003 4:51 PM > To: rddp@ietf.org > Subject: RE: [rddp] Header CRC mandatory? > > > > I am not fully convinced either way as to whether > CRC should be optional or mandatory. I have seen > some arguments for mandatory CRCs that > I personally find less that persuasive. This > would include the following. > > 1. Users want the same level of protection for > both TCP and SCTP. > > Why? Users want sufficient protection to > insure that silent data corruption does not > occur. Naive expectation would be that > TCP provides 16 bit checksum and SCTP provides > 32 bit CRC. Which is required depends on > deployment. If you really want the same, > then SCTP should include a 16 bit checksum > in the RDDP mapping layer so that both > TCP and SCTP will have the combined protection > of both a 32 bit CRC and a 16 bit checksum. > > > 2. Performance of software implementations is > not important since most all implementations, > or at least most all implementations caring > about performance, will use hardware acceleration. > > This argument seems plausible, but also seems > contrary to a previous consensus that > software implementations were important and > should not be short changed. > > > 3. Overhead to negotiate options is too onerous. > > Mechanisms need to be fully defined, but I think > there needs to be a round trip to negotiate use > of RDDP in the first place, so piggy-backing additional > negotiation items should have small incremental > cost. If connection is born in RDDP mode by > use of well known port, then option negotiation > could be piggy-backed on TCP SYN packets. > > > The following arguments have some merit, but I would > like to see more data to back them up. > > 4. CRCs are not very hard to calculate in software. > They do not require an additional data touch. > > What is the overhead of a typical software TCP > stack? For sake of argument, assume NIC offload > of checksum calculations. What is the overhead > of a CRC computation? How do these two numbers > compare (on a per byte basis). My guess is that > they are the same order of magnitude which would > mean that CRC computation is certainly not > negligible. But I could be wrong. > > As to no additional data touch, that seems possible > with an integrated implementation. Not sure how > that could work with a layered implementation > of new RDDP code on top of existing TCP/IP > implementation. The latter seems like > an important, if not more likely, scenario. > > > 5. TCP checksum provides inadequate coverage to > guarantee correctness. This is certainly true > in some cases. Is it true in most all cases? > Most common case for deployment of RDDP likely to > be two endpoints on the same LAN with > one or two switches between. Is TCP checksum > alone inadequate in this case given the link CRC? > My guess is that TCP checksum is adequate for > this case, but more data to shed light on this > would be helpful. > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Sat May 3 13:51:38 2003 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 NAA03974 for ; Sat, 3 May 2003 13:51:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h43Hwjn24956 for rddp-archive@odin.ietf.org; Sat, 3 May 2003 13:58:45 -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 h43Hwi824953 for ; Sat, 3 May 2003 13:58:44 -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 NAA03934 for ; Sat, 3 May 2003 13:50:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19C1BA-00058y-00 for rddp-web-archive@ietf.org; Sat, 03 May 2003 13:52:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19C1Ap-00058e-00 for rddp-web-archive@ietf.org; Sat, 03 May 2003 13:51:47 -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 h43HuH824777; Sat, 3 May 2003 13:56:17 -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 h43HtQ824749 for ; Sat, 3 May 2003 13:55:26 -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 NAA03896 for ; Sat, 3 May 2003 13:47:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19C18k-00058A-00 for rddp@ietf.org; Sat, 03 May 2003 13:49:38 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19C18P-00057d-00 for rddp@ietf.org; Sat, 03 May 2003 13:49:17 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 9CA14244A13 for ; Sat, 3 May 2003 13:49:15 -0400 (EDT) Date: Sat, 3 May 2003 12:51:44 -0500 From: Caitlin Bestler Subject: RE: [rddp] Header CRC mandatory? To: rddp@ietf.org X-Priority: 3 In-Reply-To: <01CA1B1F74A4EC40A9C887F7B58F872403143162@cceexc16.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Reviewing this thread, I am all but convinced that rddp is not the correct forum for this discussion. An argument can be made that the need for end-to-end CRCs may be more an inherited superstition than a real need. Maybe all need for it did disappear with the ISA bus. But those issues are not specific to rddp. They apply to reliable transports in general -- and there should be a consistent policy on the subject. Whatever need there is for end-to-end protection, it does not vary based on the membership of specific Working Groups. The last word from the transport working group on the appropriate level of protection for a reliable transport was that SCTP required CRC32C (RFC 3309). I believe correct procedure would call for any deviation from that wisdom to be based upon RDDP specific factors. Shouldn't nny questions regarding the need for end-to-end CRC protection, in general, be raised on tsvwg? Similiarly, if a mandatory CRC32C is acceptable for SCTP (where software implementations actually dominate), then how can there be RDDP-specific reasoning that concludes that CRC32C calculations constitute too much of a burden on software implementations? The only RDDP specific issue that I am aware of is that there is a strong argument that the header protection is *more* of a requirement for RDDP than for a conventional transport. With a conventional transport *only* the receiving buffer is ever at risk. With RDDP all other buffers advertised for the Protection Domain are also at risk. Whether or not a ULP chooses to trust its peer is a ULP decision. The point is that for those ULPs that do have trust, an unchecked RDDP header creates a new risk that is not part of a non-RDMA transport. But that, I believe, is ultimately irrelevant unless there are valid RDDP-specific reasons for concluding that mandatory CRC32C coverage of the entire payload is unwarranted. The arguments I have seen are *not* RDDP-specific. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Sun May 4 23:26:18 2003 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 XAA12145 for ; Sun, 4 May 2003 23:26:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h453Y6C19209 for rddp-archive@odin.ietf.org; Sun, 4 May 2003 23:34:06 -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 h453Y6819206 for ; Sun, 4 May 2003 23:34:06 -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 XAA12140 for ; Sun, 4 May 2003 23:25:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CWdu-0003Ux-00 for rddp-web-archive@ietf.org; Sun, 04 May 2003 23:27:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CWdu-0003Ut-00 for rddp-web-archive@ietf.org; Sun, 04 May 2003 23:27:54 -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 h453XI819185; Sun, 4 May 2003 23:33:18 -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 h453V4819131 for ; Sun, 4 May 2003 23:31:04 -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 XAA12117 for ; Sun, 4 May 2003 23:22:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CWaL-0003Ue-00 for rddp@ietf.org; Sun, 04 May 2003 23:24:13 -0400 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 19CWaF-0003Ua-00 for rddp@ietf.org; Sun, 04 May 2003 23:24:07 -0400 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Sun, 04 May 2003 20:12:29 -0700 Received: from nt-irva-0740.brcm.ad.broadcom.com ([10.8.194.53]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id UAA00761; Sun, 4 May 2003 20:12:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] Header CRC mandatory? Date: Sun, 4 May 2003 20:11:32 -0700 Message-ID: Thread-Topic: [rddp] Header CRC mandatory? Thread-Index: AcMQZ2ecOcOFhVj5T8SRkEsawSyj2wCS7VXQ From: "Uri Elzur" To: "Carrier, John" , rddp@ietf.org X-WSS-ID: 12AB09173367076-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h453WO819163 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit John I agree with your reasoning below. Would like to add that the subject line mentions "Header CRC", while it is important to have one CRC that covers the entire DDP message, such that regardless of ULP used, the _complete_ placement information is protected. In case the DDP header ONLY is protected, you run into problems pretty fast. Fr instance, RDMAP which is an official draft of RDDP WG, has its direct data placement information not fully covered if Header CRC only is used. Uri -----Original Message----- From: Carrier, John [mailto:John_Carrier@adaptec.com] Sent: Thursday, May 01, 2003 9:52 PM To: rddp@ietf.org Subject: RE: [rddp] Header CRC mandatory? On 5/1/03 Jim Williams wrote : > > 1. Users want the same level of protection for > both TCP and SCTP. > > Why? Users want sufficient protection to > insure that silent data corruption does not > occur. Naive expectation would be that > TCP provides 16 bit checksum and SCTP provides > 32 bit CRC. Which is required depends on > deployment. If you really want the same, > then SCTP should include a 16 bit checksum > in the RDDP mapping layer so that both > TCP and SCTP will have the combined protection > of both a 32 bit CRC and a 16 bit checksum. > > Adding additional CRCs or checksums to DDP does not make sense when SCTP already has 32 bit CRC protection. The layering of DDP over its LLP (SCTP or TCP) is cleaner if the CRC is all done at the LLP. Since SCTP already has a CRC, that meant adding a CRC to MPA. As a result, there are no LLP-specific options inside DDP--the same definition of DDP is valid over SCTP as well as TCP/MPA. --jc _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Mon May 5 12:59:47 2003 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 MAA07948 for ; Mon, 5 May 2003 12:59:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45H7rM17996 for rddp-archive@odin.ietf.org; Mon, 5 May 2003 13:07:53 -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 h45H7r817993 for ; Mon, 5 May 2003 13:07:53 -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 MAA07933 for ; Mon, 5 May 2003 12:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CjLA-00073P-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 13:01:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CjL9-00073M-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 13:01:23 -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 h45H75817173; Mon, 5 May 2003 13:07:05 -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 h45H6p817093 for ; Mon, 5 May 2003 13:06:51 -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 MAA07851 for ; Mon, 5 May 2003 12:57:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CjJ8-00072C-00 for rddp@ietf.org; Mon, 05 May 2003 12:59:18 -0400 Received: from magic-mail.adaptec.com ([208.236.45.100] helo=magic.adaptec.com) by ietf-mx with esmtp (Exim 4.12) id 19CjJ2-00071c-00 for rddp@ietf.org; Mon, 05 May 2003 12:59:12 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h45GtkZ19439 for ; Mon, 5 May 2003 09:55:46 -0700 Received: from aimexc07.adaptec.com (aimexc07.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id JAA16782 for ; Mon, 5 May 2003 09:59:01 -0700 (PDT) Received: by aimexc07.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 May 2003 09:59:01 -0700 Message-ID: From: "Carrier, John" To: rddp@ietf.org Subject: RE: [rddp] Header CRC mandatory? Date: Mon, 5 May 2003 09:59:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , sorry if I wasn't clear. I think the CRC calculation should : * cover all of the data in the TCP payload * be mandatory for RDMA over TCP * be done by the TCP framing layer below DDP (without any knowledge of the DDP header or its payload) --jc > -----Original Message----- > From: Uri Elzur [mailto:uri@broadcom.com] > Sent: Sunday, May 04, 2003 8:12 PM > To: Carrier, John; rddp@ietf.org > Subject: RE: [rddp] Header CRC mandatory? > > > John > > I agree with your reasoning below. > > Would like to add that the subject line mentions "Header > CRC", while it > is important to have one CRC that covers the entire DDP message, such > that regardless of ULP used, the _complete_ placement information is > protected. In case the DDP header ONLY is protected, you run into > problems pretty fast. Fr instance, RDMAP which is an official draft of > RDDP WG, has its direct data placement information not fully > covered if > Header CRC only is used. > > Uri > > -----Original Message----- > From: Carrier, John [mailto:John_Carrier@adaptec.com] > Sent: Thursday, May 01, 2003 9:52 PM > To: rddp@ietf.org > Subject: RE: [rddp] Header CRC mandatory? > > > > On 5/1/03 Jim Williams wrote : > > > > 1. Users want the same level of protection for > > both TCP and SCTP. > > > > Why? Users want sufficient protection to > > insure that silent data corruption does not > > occur. Naive expectation would be that > > TCP provides 16 bit checksum and SCTP provides > > 32 bit CRC. Which is required depends on > > deployment. If you really want the same, > > then SCTP should include a 16 bit checksum > > in the RDDP mapping layer so that both > > TCP and SCTP will have the combined protection > > of both a 32 bit CRC and a 16 bit checksum. > > > > > > > Adding additional CRCs or checksums to DDP does not make > sense when SCTP > already has 32 bit CRC protection. > > The layering of DDP over its LLP (SCTP or TCP) is cleaner if > the CRC is > all done at the LLP. Since SCTP already has a CRC, that > meant adding a > CRC to MPA. As a result, there are no LLP-specific options inside > DDP--the same definition of DDP is valid over SCTP as well as TCP/MPA. > > > --jc > > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Mon May 5 15:28:03 2003 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 PAA13426 for ; Mon, 5 May 2003 15:28:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45JaAR28041 for rddp-archive@odin.ietf.org; Mon, 5 May 2003 15:36:10 -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 h45JaA828038 for ; Mon, 5 May 2003 15:36:10 -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 PAA13411 for ; Mon, 5 May 2003 15:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cleb-000051-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 15:29:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Cleb-00004s-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 15:29:37 -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 h45JZF828002; Mon, 5 May 2003 15:35:15 -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 h45JYp827959 for ; Mon, 5 May 2003 15:34:51 -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 PAA13392 for ; Mon, 5 May 2003 15:26:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CldL-00004E-00 for rddp@ietf.org; Mon, 05 May 2003 15:28:19 -0400 Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx with esmtp (Exim 4.12) id 19Cld0-00003b-00 for rddp@ietf.org; Mon, 05 May 2003 15:27:58 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 4A5988DD3 for ; Mon, 5 May 2003 14:27:08 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 5 May 2003 14:27:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rddp] Marker Consensus Proposal Date: Mon, 5 May 2003 14:27:07 -0500 Message-ID: <07DEBFB3DCB18A49B06B6371993586740292FF5A@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] Marker Consensus Proposal Thread-Index: AcMLS4iLq9t3z0ZFRvqyf9tzha2PFgFiAePwAJoj4MA= From: "Hilland, Jeff" To: X-OriginalArrivalTime: 05 May 2003 19:27:08.0056 (UTC) FILETIME=[515D9980:01C3133C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h45JYp827960 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I would agree that "receiver's choice" is the a reasonable compromise. Regards, Jeff -----Original Message----- From: Uri Elzur [mailto:uri@broadcom.com] Sent: Friday, May 02, 2003 12:57 PM To: Black_David@emc.com; rddp@ietf.org Subject: RE: [rddp] Marker Consensus Proposal David In order to allow the group to make forward progress, I'd support your call below. It allows for more efficient implementations to exist and to interoperate with other implementations. It also narrows down the number of options the implementer need to worry about, obviously good news. Our challenge going forward is to make sure we do not burden high speed implementations with a lengthy prologue. Uri -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, April 25, 2003 9:41 AM To: rddp@ietf.org Subject: [rddp] Marker Consensus Proposal WG Chair hat firmly in place ... Looking back on the discussion of markers, I'm going to attempt to propose a way forward and hope the we can get WG rough consensus for it. The core of the proposal is what I originally posted a couple of weeks ago: Make marker usage OPTIONAL, but put control of this option entirely in the hands of the receiver - senders MUST implement both markers and not-markers, receivers MUST implement one OR the other, and each receiver gets to pick which one is used as the benefits of markers are primarily on the receiver side. With the following additions: - When markers are used, the marker interval MUST be 512 bytes. - This proposed rough consensus assumes that we will be forced to do some sort of setup announcement as part of the "proof" requirement, which will provide a place to transmit options (and a version number). Details of exactly how this works so that each receiver gets to pick what is sent to it are TBD. This is not going to be the "perfect" answer for everyone, but it's clear to me that WG rough consensus will not be obtained for the positions at the end of the spectrum, namely: - 512 byte markers MUST be used at all times - Markers are completely optional Further discussion/advocacy of those positions is probably not productive. I believe the above proposal is acceptable for the important classes of implementations, and is technically sound. Further comment to the list, please. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Mon May 5 16:27:35 2003 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 QAA15053 for ; Mon, 5 May 2003 16:27:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45KZin32156 for rddp-archive@odin.ietf.org; Mon, 5 May 2003 16:35:44 -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 h45KZi832153 for ; Mon, 5 May 2003 16:35:44 -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 QAA14829 for ; Mon, 5 May 2003 16:26:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CmZz-0000aU-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 16:28:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Cm98-0000H4-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 16:01:10 -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 h45K4c830105; Mon, 5 May 2003 16:04:38 -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 h45JkF829286 for ; Mon, 5 May 2003 15:46:15 -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 PAA13653 for ; Mon, 5 May 2003 15:37:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Clo8-00008f-00 for rddp@ietf.org; Mon, 05 May 2003 15:39:28 -0400 Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx with esmtp (Exim 4.12) id 19Clnn-00008A-00 for rddp@ietf.org; Mon, 05 May 2003 15:39:07 -0400 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 97B308E36 for ; Mon, 5 May 2003 14:39:01 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 5 May 2003 14:39:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rddp] Header CRC mandatory? Date: Mon, 5 May 2003 14:39:01 -0500 Message-ID: <07DEBFB3DCB18A49B06B63719935867403FF5F53@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] Header CRC mandatory? Thread-Index: AcMRnTdoeDU8uBj9RBO9MrbzbHHhBABnZNVw From: "Hilland, Jeff" To: X-OriginalArrivalTime: 05 May 2003 19:39:01.0500 (UTC) FILETIME=[FA9C83C0:01C3133D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h45JkF829287 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Caitlin brings out an excellent point below. How is it that CRC32C is acceptable overhead for SCTP, but it is onerous for MPA? I suppose you could argue that there would be extra touches to host memory, but realistically even my old laptop's NIC does TCP checksum offload. Regards, Jeff Hilland -----Original Message----- From: Caitlin Bestler [mailto:cait@asomi.com] Sent: Saturday, May 03, 2003 12:52 PM To: rddp@ietf.org Subject: RE: [rddp] Header CRC mandatory? Reviewing this thread, I am all but convinced that rddp is not the correct forum for this discussion. An argument can be made that the need for end-to-end CRCs may be more an inherited superstition than a real need. Maybe all need for it did disappear with the ISA bus. But those issues are not specific to rddp. They apply to reliable transports in general -- and there should be a consistent policy on the subject. Whatever need there is for end-to-end protection, it does not vary based on the membership of specific Working Groups. The last word from the transport working group on the appropriate level of protection for a reliable transport was that SCTP required CRC32C (RFC 3309). I believe correct procedure would call for any deviation from that wisdom to be based upon RDDP specific factors. Shouldn't nny questions regarding the need for end-to-end CRC protection, in general, be raised on tsvwg? Similiarly, if a mandatory CRC32C is acceptable for SCTP (where software implementations actually dominate), then how can there be RDDP-specific reasoning that concludes that CRC32C calculations constitute too much of a burden on software implementations? The only RDDP specific issue that I am aware of is that there is a strong argument that the header protection is *more* of a requirement for RDDP than for a conventional transport. With a conventional transport *only* the receiving buffer is ever at risk. With RDDP all other buffers advertised for the Protection Domain are also at risk. Whether or not a ULP chooses to trust its peer is a ULP decision. The point is that for those ULPs that do have trust, an unchecked RDDP header creates a new risk that is not part of a non-RDMA transport. But that, I believe, is ultimately irrelevant unless there are valid RDDP-specific reasons for concluding that mandatory CRC32C coverage of the entire payload is unwarranted. The arguments I have seen are *not* RDDP-specific. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Mon May 5 17:54:16 2003 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 RAA17716 for ; Mon, 5 May 2003 17:54:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45M2Q406865 for rddp-archive@odin.ietf.org; Mon, 5 May 2003 18:02:26 -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 h45M2Q806853 for ; Mon, 5 May 2003 18:02:26 -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 RAA17688 for ; Mon, 5 May 2003 17:52:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cnus-0001Ey-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 17:54:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Cnur-0001Ep-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 17:54:33 -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 h45LwL806695; Mon, 5 May 2003 17:58:21 -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 h45Lpk806531 for ; Mon, 5 May 2003 17:51:46 -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 RAA17589 for ; Mon, 5 May 2003 17:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cnln-0001DZ-00 for rddp@ietf.org; Mon, 05 May 2003 17:45:11 -0400 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cnlh-0001CH-00 for rddp@ietf.org; Mon, 05 May 2003 17:45:06 -0400 Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.12.9/8.12.8) with ESMTP id h45Li7LW021976 for ; Mon, 5 May 2003 14:44:07 -0700 (PDT) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 May 2003 17:44:07 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF289B9073@xbl.ma.emulex.com> From: "Williams, Jim" To: rddp@ietf.org Subject: RE: [rddp] CRC mandatory? Date: Mon, 5 May 2003 17:44:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , 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. Is the world clamoring that TCP be replaced by SCTP because TCP is corrupting too much data? If so, SCTP should quickly become widely deployed, and RDDP should simply ride this transition, and use SCTP. On the other hand, is TCP fine for its current uses, but RDDP if fundamentally different and requires a higher level of data integrity? 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? 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. 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? 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. 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. This seems a stretch in a couple respects. One being that two data checks are more expensive than one, and not justified if the first (TCP checksum) is sufficient. 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. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Mon May 5 18:07:34 2003 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 SAA18123 for ; Mon, 5 May 2003 18:07:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45MFjX08205 for rddp-archive@odin.ietf.org; Mon, 5 May 2003 18:15:45 -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 h45MFj808202 for ; Mon, 5 May 2003 18:15:45 -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 SAA18120 for ; Mon, 5 May 2003 18:07:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Co8z-0001KH-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 18:09:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Co8z-0001KE-00 for rddp-web-archive@ietf.org; Mon, 05 May 2003 18:09:09 -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 h45MD2808130; Mon, 5 May 2003 18:13:02 -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 h45MCa808102 for ; Mon, 5 May 2003 18:12:36 -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 SAA18038 for ; Mon, 5 May 2003 18:03:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Co5h-0001IX-00 for rddp@ietf.org; Mon, 05 May 2003 18:05:46 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 19Co5c-0001I9-00 for rddp@ietf.org; Mon, 05 May 2003 18:05:40 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h45LwFZ11055 for ; Mon, 5 May 2003 21:58:15 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h45LxJG28782 for ; Mon, 5 May 2003 21:59:19 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003050515024904499 ; Mon, 05 May 2003 15:02:49 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 May 2003 15:05:34 -0700 Message-ID: From: "Larsen, Roy K" To: "'Williams, Jim'" , rddp@ietf.org Subject: RE: [rddp] CRC mandatory? Date: Mon, 5 May 2003 15:05:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Amen! Well said Jim. Roy -----Original Message----- From: Williams, Jim [mailto:Jim.Williams@emulex.com] Sent: Monday, May 05, 2003 2:44 PM To: rddp@ietf.org Subject: RE: [rddp] CRC mandatory? 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. Is the world clamoring that TCP be replaced by SCTP because TCP is corrupting too much data? If so, SCTP should quickly become widely deployed, and RDDP should simply ride this transition, and use SCTP. On the other hand, is TCP fine for its current uses, but RDDP if fundamentally different and requires a higher level of data integrity? 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? 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. 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? 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. 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. This seems a stretch in a couple respects. One being that two data checks are more expensive than one, and not justified if the first (TCP checksum) is sufficient. 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. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Mon May 5 18:29:02 2003 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 SAA19786 for ; Mon, 5 May 2003 18:29:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45MbD509498 for rddp-archive@odin.ietf.org; Mon, 5 May 2003 18:37:13 -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 h45MbD809487 for ; Mon, 5 May 2003 18:37:13 -0400 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 SAA19740 for ; Mon, 5 May 2003 18:28:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Ma3808997; Mon, 5 May 2003 18:36:03 -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 h45MOk808511 for ; Mon, 5 May 2003 18:24:46 -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 SAA18523 for ; Mon, 5 May 2003 18:15:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CoHT-0001Me-00 for rddp@ietf.org; Mon, 05 May 2003 18:17:55 -0400 Received: from h008.c001.snv.cp.net ([209.228.32.122] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 19CoHI-0001Mb-00 for rddp@ietf.org; Mon, 05 May 2003 18:17:44 -0400 Received: (cpmta 8637 invoked from network); 5 May 2003 15:17:59 -0700 Received: from 63.193.3.254 (HELO zyteraphqohm96) by smtp.register-admin.com (209.228.32.122) with SMTP; 5 May 2003 15:17:59 -0700 X-Sent: 5 May 2003 22:17:59 GMT Reply-To: From: "John A. Thodiyil" To: Subject: RE: [rddp] CRC mandatory? Date: Mon, 5 May 2003 15:20:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I couldn't agree more!. CRC should be optional in my opinion too. -John -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Larsen, Roy K Sent: Monday, May 05, 2003 3:05 PM To: 'Williams, Jim'; rddp@ietf.org Subject: RE: [rddp] CRC mandatory? Amen! Well said Jim. Roy -----Original Message----- From: Williams, Jim [mailto:Jim.Williams@emulex.com] Sent: Monday, May 05, 2003 2:44 PM To: rddp@ietf.org Subject: RE: [rddp] CRC mandatory? 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. Is the world clamoring that TCP be replaced by SCTP because TCP is corrupting too much data? If so, SCTP should quickly become widely deployed, and RDDP should simply ride this transition, and use SCTP. On the other hand, is TCP fine for its current uses, but RDDP if fundamentally different and requires a higher level of data integrity? 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? 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. 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? 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. 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. This seems a stretch in a couple respects. One being that two data checks are more expensive than one, and not justified if the first (TCP checksum) is sufficient. 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. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 10:31:41 2003 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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 From mailnull@www1.ietf.org Tue May 6 12:42:18 2003 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 MAA28911 for ; Tue, 6 May 2003 12:42:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Goqb07507 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 12:50:52 -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 h46Goq807503 for ; Tue, 6 May 2003 12:50:52 -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 MAA28882 for ; Tue, 6 May 2003 12:41:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5Xl-0000To-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 12:43:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D5Xk-0000Tl-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 12:43:52 -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 h46GoB807458; Tue, 6 May 2003 12:50: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 h46GnR807402 for ; Tue, 6 May 2003 12:49:27 -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 MAA28843 for ; Tue, 6 May 2003 12:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5WP-0000T2-00 for rddp@ietf.org; Tue, 06 May 2003 12:42:29 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19D5WO-0000Sd-00 for rddp@ietf.org; Tue, 06 May 2003 12:42:28 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 6E388244F02 for ; Tue, 6 May 2003 12:43:03 -0400 (EDT) Date: Tue, 6 May 2003 11:42:48 -0500 From: Caitlin Bestler Subject: RE: [rddp] CRC mandatory? To: rddp@ietf.org X-Priority: 3 In-Reply-To: <5.1.0.14.2.20030506070121.028eb4c0@15.13.130.73> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I believe there are some fundamental issues regarding making CRC coverage optional. The first is exactly what is our starting point? My understanding is that we are defining RDMA over reliable IP transports and that we should be cleanly layered. So, which interpretation to we make of "cleanly layered": a) We define uniform expectations of the transport layer, and provide adaptation layers to fill the gap between those expectations and the existing IP transports. b) We add adaptation layer features *only* as required to make DDP work, leaving each transport mapping as close to the original transport as possible. The "uniform transport layer requirements" basically match SCTP. Basically because RDDP requires unordered delivery while preserving the order of submission, this required the addition of the DDP-SSN in a very thin adaptation layer. It has been agreed that MPA adds framing and markers if the receiver wants them. So the debate is whether MPA should provide a standard level of protection (i.e. end-to-end CRC32C on the entire DDP Segment), or whether we have to justify *each* addition to TCP as being specifically required by RDDP. I am a firm advocate of the "uniform expectations" approach. This is mostly because I believe that applications developers believe even more firmly in uniform expectations, and will achieve it by lowering their expectations to match the lowest common denominator. There are two guides as to what constitutes a reasonable expectation for reliable transport for RDMA protocols: SCTP and InfiniBand. SCTP is relevant because it is the reliable transport most recently defined by the IETF. InfiniBand is relevant because many of the ULPs that RDMAP/RDDP plans on supporting will also run over InfiniBand. Having the adaptation layer raise all transports to a uniform layer that matches the needs of RDDP makes much more sense to me than having all applications conform to the worst transport over which RDDP will run. The LCD approach *will* waste effort, because ULP integrity checks will be applied redundantly to SCTP's CRC32c. Further, even if we accept the need to justify each feature within MPA on an RDDP-specific basis, there is definitely a need for coverage of the DDP and RDMAP headers. I have not seen a single refutation to the following: -- There are applications where there is trust between the ULP peers. That is, the Data Sink ULP feels no need to protect itself from maliscious attacks by its peer. There is sufficient containment of damage from other clients and/or sufficient authentication of the peer. Whether a given ULP should or should not work from this model is irrelevant here. Clearly there are are applications where this is true, and they should be supported. -- There are applications that require a higher level of protection than afforded by TCP's 16 bit checksum. -- There are applications where the server wishes to allow the client to have multiple requests in-flight. There are even applications where all of the above apply. A DAFS Client requires more than a TCP 16 bit checksum, trusts the DAFS server and can have a sequence of read requests pending at the same instant. Without adequate protection for the DDP header, the ULP would be forced to have only a single STag open on the connection at any given time. That would mean that a DAFS client running over MPA/TCP would be less capable than one running over SCTP or IB. All three objectives cited above could be met via either IB or SCTP. I believe that clearly establishes an RDDP specific need to cover at least the headers. The cost of covering the entire DDP Segment is trivial compared to that. But making the length of the coverage variable is an option, which means it adds cost. See earlier posts on markers. Just because we decided that one option was justified does not make the comments on why options are expensive any less valid or relevant. Options are an ongoing complexity that must be continuously retested. They represent a perpetual drain of QA resources. A properly designed receiver can evaluate multiple CRCs and/or checksums in parallel during a single scan over memory. The calculations required for a CRC32C are minor, and no additional memory touches are required. Even if each addition to MPA must be justified, the simplicity of covering the complete DDP Segment would outweigh the benefits of allowing a handful of applications to omit some trivial calculations over the payload-only portions. If we accept the goal of providing uniform transport expectations to the ULP across all forms of reliable RDMA networks then matching both SCTP and IB with CRC coverage of the entire payload is clearly the only choice. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 13:10:14 2003 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 NAA29775 for ; Tue, 6 May 2003 13:10:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46HInA09900 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 13:18:49 -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 h46HIm809897 for ; Tue, 6 May 2003 13:18:48 -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 NAA29743 for ; Tue, 6 May 2003 13:09:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5yn-0000f3-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 13:11:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D5ym-0000f0-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 13:11:48 -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 h46HI2809830; Tue, 6 May 2003 13:18:02 -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 h46HHq809805 for ; Tue, 6 May 2003 13:17:52 -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 NAA29678 for ; Tue, 6 May 2003 13:08:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5xt-0000ec-00 for rddp@ietf.org; Tue, 06 May 2003 13:10:53 -0400 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 19D5xs-0000eZ-00 for rddp@ietf.org; Tue, 06 May 2003 13:10:52 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id E8F321C027F7 for ; Tue, 6 May 2003 10:11:39 -0700 (PDT) Received: from mk731915.cup.hp.com ([15.8.80.111]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id h46H7gE24448 for ; Tue, 6 May 2003 10:07:42 -0700 (PDT) Message-Id: <5.1.0.14.2.20030506100824.027292a8@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 May 2003 10:09:18 -0700 To: rddp@ietf.org From: Michael Krause Subject: RE: [rddp] CRC mandatory? In-Reply-To: References: <5.1.0.14.2.20030506070121.028eb4c0@15.13.130.73> 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Strongly concur. Mike At 11:42 AM 5/6/2003 -0500, Caitlin Bestler wrote: >I believe there are some fundamental issues regarding making >CRC coverage optional. > >The first is exactly what is our starting point? > >My understanding is that we are defining RDMA over reliable >IP transports and that we should be cleanly layered. > >So, which interpretation to we make of "cleanly layered": > >a) We define uniform expectations of the transport layer, > and provide adaptation layers to fill the gap between > those expectations and the existing IP transports. > >b) We add adaptation layer features *only* as required > to make DDP work, leaving each transport mapping as > close to the original transport as possible. > >The "uniform transport layer requirements" basically match >SCTP. Basically because RDDP requires unordered delivery >while preserving the order of submission, this required >the addition of the DDP-SSN in a very thin adaptation layer. >It has been agreed that MPA adds framing and markers if the >receiver wants them. > >So the debate is whether MPA should provide a standard level >of protection (i.e. end-to-end CRC32C on the entire DDP >Segment), or whether we have to justify *each* addition >to TCP as being specifically required by RDDP. > >I am a firm advocate of the "uniform expectations" approach. >This is mostly because I believe that applications >developers believe even more firmly in uniform expectations, >and will achieve it by lowering their expectations to match >the lowest common denominator. > >There are two guides as to what constitutes a reasonable >expectation for reliable transport for RDMA protocols: SCTP >and InfiniBand. SCTP is relevant because it is the reliable >transport most recently defined by the IETF. InfiniBand is >relevant because many of the ULPs that RDMAP/RDDP plans on >supporting will also run over InfiniBand. > >Having the adaptation layer raise all transports to a >uniform layer that matches the needs of RDDP makes much >more sense to me than having all applications conform >to the worst transport over which RDDP will run. > >The LCD approach *will* waste effort, because ULP integrity >checks will be applied redundantly to SCTP's CRC32c. > >Further, even if we accept the need to justify each feature >within MPA on an RDDP-specific basis, there is definitely a >need for coverage of the DDP and RDMAP headers. > >I have not seen a single refutation to the following: > >-- There are applications where there is trust between > the ULP peers. That is, the Data Sink ULP feels no > need to protect itself from maliscious attacks by > its peer. There is sufficient containment of damage > from other clients and/or sufficient authentication > of the peer. > > Whether a given ULP should or should not work from > this model is irrelevant here. Clearly there are > are applications where this is true, and they should > be supported. > >-- There are applications that require a higher level > of protection than afforded by TCP's 16 bit checksum. > >-- There are applications where the server wishes to allow > the client to have multiple requests in-flight. > >There are even applications where all of the above apply. >A DAFS Client requires more than a TCP 16 bit checksum, >trusts the DAFS server and can have a sequence of read >requests pending at the same instant. > >Without adequate protection for the DDP header, the ULP >would be forced to have only a single STag open on the >connection at any given time. > >That would mean that a DAFS client running over MPA/TCP >would be less capable than one running over SCTP or IB. >All three objectives cited above could be met via either >IB or SCTP. > >I believe that clearly establishes an RDDP specific need >to cover at least the headers. The cost of covering the >entire DDP Segment is trivial compared to that. > >But making the length of the coverage variable is an option, >which means it adds cost. See earlier posts on markers. > >Just because we decided that one option was justified does >not make the comments on why options are expensive any less >valid or relevant. Options are an ongoing complexity that >must be continuously retested. They represent a perpetual >drain of QA resources. > >A properly designed receiver can evaluate multiple CRCs >and/or checksums in parallel during a single scan over >memory. The calculations required for a CRC32C are minor, >and no additional memory touches are required. > >Even if each addition to MPA must be justified, the >simplicity of covering the complete DDP Segment would >outweigh the benefits of allowing a handful of applications >to omit some trivial calculations over the payload-only >portions. > >If we accept the goal of providing uniform transport >expectations to the ULP across all forms of reliable >RDMA networks then matching both SCTP and IB with >CRC coverage of the entire payload is clearly the only >choice. > > > > > > >Caitlin Bestler >http://asomi.com/CaitlinBestler/ >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 13:56:01 2003 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 NAA01324 for ; Tue, 6 May 2003 13:56:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46I4bH13423 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 14:04:37 -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 h46I4b813420 for ; Tue, 6 May 2003 14:04: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 NAA01316 for ; Tue, 6 May 2003 13:55:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D6h6-00012Z-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 13:57:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D6h6-00012W-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 13:57:36 -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 h46I3g813386; Tue, 6 May 2003 14:03:42 -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 h46I2E813306 for ; Tue, 6 May 2003 14:02:14 -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 NAA01240 for ; Tue, 6 May 2003 13:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D6en-00011T-00 for rddp@ietf.org; Tue, 06 May 2003 13:55:13 -0400 Received: from magic-mail.adaptec.com ([208.236.45.100] helo=magic.adaptec.com) by ietf-mx with esmtp (Exim 4.12) id 19D6em-00011K-00 for rddp@ietf.org; Tue, 06 May 2003 13:55:12 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h46HqCZ16584 for ; Tue, 6 May 2003 10:52:12 -0700 Received: from aimexc07.adaptec.com (aimexc07.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id KAA19007 for ; Tue, 6 May 2003 10:55:31 -0700 (PDT) Received: by aimexc07.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 May 2003 10:55:31 -0700 Message-ID: From: "Carrier, John" To: rddp@ietf.org Subject: RE: [rddp] CRC mandatory? Date: Tue, 6 May 2003 10:55:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , I also am a strong advocate of "uniform expectations" --jc > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Tuesday, May 06, 2003 9:43 AM > To: rddp@ietf.org > Subject: RE: [rddp] CRC mandatory? > > > I believe there are some fundamental issues regarding making > CRC coverage optional. > > The first is exactly what is our starting point? > > My understanding is that we are defining RDMA over reliable > IP transports and that we should be cleanly layered. > > So, which interpretation to we make of "cleanly layered": > > a) We define uniform expectations of the transport layer, > and provide adaptation layers to fill the gap between > those expectations and the existing IP transports. > > b) We add adaptation layer features *only* as required > to make DDP work, leaving each transport mapping as > close to the original transport as possible. > > The "uniform transport layer requirements" basically match > SCTP. Basically because RDDP requires unordered delivery > while preserving the order of submission, this required > the addition of the DDP-SSN in a very thin adaptation layer. > It has been agreed that MPA adds framing and markers if the > receiver wants them. > > So the debate is whether MPA should provide a standard level > of protection (i.e. end-to-end CRC32C on the entire DDP > Segment), or whether we have to justify *each* addition > to TCP as being specifically required by RDDP. > > I am a firm advocate of the "uniform expectations" approach. > This is mostly because I believe that applications > developers believe even more firmly in uniform expectations, > and will achieve it by lowering their expectations to match > the lowest common denominator. > > There are two guides as to what constitutes a reasonable > expectation for reliable transport for RDMA protocols: SCTP > and InfiniBand. SCTP is relevant because it is the reliable > transport most recently defined by the IETF. InfiniBand is > relevant because many of the ULPs that RDMAP/RDDP plans on > supporting will also run over InfiniBand. > > Having the adaptation layer raise all transports to a > uniform layer that matches the needs of RDDP makes much > more sense to me than having all applications conform > to the worst transport over which RDDP will run. > > The LCD approach *will* waste effort, because ULP integrity > checks will be applied redundantly to SCTP's CRC32c. > > Further, even if we accept the need to justify each feature > within MPA on an RDDP-specific basis, there is definitely a > need for coverage of the DDP and RDMAP headers. > > I have not seen a single refutation to the following: > > -- There are applications where there is trust between > the ULP peers. That is, the Data Sink ULP feels no > need to protect itself from maliscious attacks by > its peer. There is sufficient containment of damage > from other clients and/or sufficient authentication > of the peer. > > Whether a given ULP should or should not work from > this model is irrelevant here. Clearly there are > are applications where this is true, and they should > be supported. > > -- There are applications that require a higher level > of protection than afforded by TCP's 16 bit checksum. > > -- There are applications where the server wishes to allow > the client to have multiple requests in-flight. > > There are even applications where all of the above apply. > A DAFS Client requires more than a TCP 16 bit checksum, > trusts the DAFS server and can have a sequence of read > requests pending at the same instant. > > Without adequate protection for the DDP header, the ULP > would be forced to have only a single STag open on the > connection at any given time. > > That would mean that a DAFS client running over MPA/TCP > would be less capable than one running over SCTP or IB. > All three objectives cited above could be met via either > IB or SCTP. > > I believe that clearly establishes an RDDP specific need > to cover at least the headers. The cost of covering the > entire DDP Segment is trivial compared to that. > > But making the length of the coverage variable is an option, > which means it adds cost. See earlier posts on markers. > > Just because we decided that one option was justified does > not make the comments on why options are expensive any less > valid or relevant. Options are an ongoing complexity that > must be continuously retested. They represent a perpetual > drain of QA resources. > > A properly designed receiver can evaluate multiple CRCs > and/or checksums in parallel during a single scan over > memory. The calculations required for a CRC32C are minor, > and no additional memory touches are required. > > Even if each addition to MPA must be justified, the > simplicity of covering the complete DDP Segment would > outweigh the benefits of allowing a handful of applications > to omit some trivial calculations over the payload-only > portions. > > If we accept the goal of providing uniform transport > expectations to the ULP across all forms of reliable > RDMA networks then matching both SCTP and IB with > CRC coverage of the entire payload is clearly the only > choice. > > > > > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 13:57:18 2003 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 NAA01368 for ; Tue, 6 May 2003 13:57:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46I5se13503 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 14:05:54 -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 h46I5s813500 for ; Tue, 6 May 2003 14:05:54 -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 NAA01363 for ; Tue, 6 May 2003 13:56:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D6iL-00012y-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 13:58:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D6iL-00012v-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 13:58:53 -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 h46I51813468; Tue, 6 May 2003 14:05:01 -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 h46I49813404 for ; Tue, 6 May 2003 14:04:09 -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 NAA01300 for ; Tue, 6 May 2003 13:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D6gf-00012H-00 for rddp@ietf.org; Tue, 06 May 2003 13:57:09 -0400 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 19D6ge-00012E-00 for rddp@ietf.org; Tue, 06 May 2003 13:57:08 -0400 Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by palrel12.hp.com (Postfix) with ESMTP id 62F1F1C01F7E for ; Tue, 6 May 2003 10:57:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.9/8.12.2) with SMTP id h46Hvw9D028455 for rddp@ietf.org; Tue, 6 May 2003 10:57:59 -0700 (PDT) From: Jeffrey Mogul Message-Id: <200305061757.h46Hvw9D028455@wera.hpl.hp.com> X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol To: rddp@ietf.org Subject: Re: [rddp] CRC mandatory? X-Organization: Hewlett-Packard Labs, Large Scale Systems group Date: Tue, 06 May 2003 10:57:58 -0700 X-Mts: smtp 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , It seems to me that one (but NOT the only) consideration in this discussion is whether CRC calculation is really a burden for a software implementation. I've seen qualitative assertions (some vaguer than others) on both sides, but nothing quantitative. RFC 3309 ("Stream Control Transmission Protocol (SCTP) Checksum Change") has an appendix about CRC implementations, and briefly discusses the issue. It cites David C. Feldmeier Fast software implementation of error detection codes IEEE Transactions on Networking, vol 3 no 6, pp 640-651, December, 1995. Unfortunately, measurements made in 1995 on a SPARCstation LX (27 SPECint932) probably won't mean much in 2003. I spent a little time with CiteSeer and Google trying to find a more recent study of CRC performance, but I couldn't find anything. Perhaps someone with a good understanding of software CRC implementation could do some measurements on modern hardware that would give a solid quantitative basis for our debate? For example, one could hack the Linux or *BSD stack to do a CRC computation on each TCP segment (sent or received), then throw away the results. Measuring the performance change on bulk throughput (say, using netperf) seems like a reasonable approximation of software CRC costs. -Jeff P.S.: Don't look at me! I don't have any spare time this month, nor do I have a "good understanding of software CRC implementation". _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 14:11:33 2003 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 OAA01719 for ; Tue, 6 May 2003 14:11:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46IK9714990 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 14:20:09 -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 h46IK9814987 for ; Tue, 6 May 2003 14:20:09 -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 OAA01714 for ; Tue, 6 May 2003 14:11:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D6w8-00018P-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 14:13:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D6w8-00018M-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 14:13:08 -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 h46IJ2814897; Tue, 6 May 2003 14:19:02 -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 h46IIr814881 for ; Tue, 6 May 2003 14:18:53 -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 OAA01702 for ; Tue, 6 May 2003 14:09:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D6uu-00018H-00 for rddp@ietf.org; Tue, 06 May 2003 14:11:52 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19D6ut-000184-00 for rddp@ietf.org; Tue, 06 May 2003 14:11:51 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 36112D428 for ; Tue, 6 May 2003 11:11:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 85C671FC4A for ; Tue, 6 May 2003 11:12:02 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Date: Tue, 6 May 2003 11:11:57 -0700 From: "Somesh Gupta" Importance: Normal In-Reply-To: Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 01514-08F715ED; Tue, 06 May 2003 11:11:51 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id D0E3A1D266 for ; Tue, 6 May 2003 11:11:51 -0700 (PDT) Subject: RE: [rddp] CRC mandatory? To: X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If SCTP is the most desirable transport, the SCTP mapping should be used. There are many features of SCTP that are thankfully not attempted to be grafted on to TCP. But they could have been and the same justification could have been used. And it will be great when everybody adopts SCTP. Similar arguement is for IB. I don't think there would be any of these debates for use of RDMA over IB. At the same time, if people want to use TCP congestion control and other features, + a few other options, then the best thing to use another transport number. However the desire is to use TCP and fix the percieved shortcomings that it has. This is where the debate is. The best way to handle this is options and not making new percieved high-value features as mandatory. This way the market can sort out which are useful and which are not. 1. I use CIFS all the time and my bits are not randomly being corrupted (i.e. TCP checksum is sufficient). 2. CRC calculation in software does have additional overhead. Theoretically the CRC calculation could be combined in some other part of the processing, but practically it will be a separate computation. 3. It is quite likely that IPSec offload will become prevalant, thus eliminating any need to have CRC as the app level. 4. If applications want even higher level of protection, then they will best not off-load integrity checks. 5. A separate header and data CRC allows two things - one is to overcome the bugaboo about direct data placement, the second about allowing data protection to be stripped while data is DMAed to the host and eliminating another potential source of corruption (in the chip buffers). 6. Perceived reliability is a feature of deployments and not of applications. That is why HA features are optional and deployed as needed (in systems, configurations, network equipment ...), and people buy different types of equipment at different price points. Something as simple as ECC memory is not uniformly found in systems. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 14:48:33 2003 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 OAA02773 for ; Tue, 6 May 2003 14:48:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46IvAt17904 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 14:57:10 -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 h46Iv9817901 for ; Tue, 6 May 2003 14:57:09 -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 OAA02740 for ; Tue, 6 May 2003 14:48:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7Vw-0001MF-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 14:50:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D7Vv-0001MC-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 14:50:07 -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 h46Iu6817814; Tue, 6 May 2003 14:56:06 -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 h46It2817770 for ; Tue, 6 May 2003 14:55:02 -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 OAA02672 for ; Tue, 6 May 2003 14:45:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7Ts-0001Km-00 for rddp@ietf.org; Tue, 06 May 2003 14:48:00 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 19D7Ts-0001Ki-00 for rddp@ietf.org; Tue, 06 May 2003 14:48:00 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id 973321C01075 for ; Tue, 6 May 2003 11:48:50 -0700 (PDT) Received: from mk731915.cup.hp.com ([15.8.80.111]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id h46IihE01424 for ; Tue, 6 May 2003 11:44:43 -0700 (PDT) Message-Id: <5.1.0.14.2.20030506113936.027909f0@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 May 2003 11:47:37 -0700 To: From: Michael Krause Subject: RE: [rddp] CRC mandatory? In-Reply-To: References: 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , At 11:11 AM 5/6/2003 -0700, Somesh Gupta wrote: >If SCTP is the most desirable transport, the SCTP mapping >should be used. There are many features of SCTP that are >thankfully not attempted to be grafted on to TCP. But >they could have been and the same justification could have >been used. And it will be great when everybody adopts SCTP. > >Similar arguement is for IB. I don't think there would be >any of these debates for use of RDMA over IB. > >At the same time, if people want to use TCP congestion control >and other features, + a few other options, then the best thing >to use another transport number. > >However the desire is to use TCP and fix the percieved shortcomings >that it has. > >This is where the debate is. > >The best way to handle this is options and not making new >percieved high-value features as mandatory. This way the market >can sort out which are useful and which are not. > >1. I use CIFS all the time and my bits are not randomly being >corrupted (i.e. TCP checksum is sufficient). RDMA = Remote DMA which is in essence the same as local DMA from an exposure perspective but now controlled by a remote. For local DMA, we are adding in strong data integrity as a requirement, e.g. ECC or CRC-32. I assert that the same logic for local DMA having strong data integrity is no different than for Remote DMA. CIFS / NFS / etc. use anonymous buffers and thus are exposed in the same way as one is with Remote DMA from corruption of the buffers or targeting incorrect memory. >2. CRC calculation in software does have additional overhead. >Theoretically the CRC calculation could be combined in some >other part of the processing, but practically it will be >a separate computation. That is an implementation choice and not one a high performance solution would pursue, IMO. >3. It is quite likely that IPSec offload will become prevalant, thus >eliminating any need to have CRC as the app level. This isn't at the app level; it is at the RDMA level. Also, IPSec is often implemented in gateway devices and people desire to have end-to-end data integrity between the NICs (rely upon local I/O data integrity to insure final delivery is correct). >4. If applications want even higher level of protection, then >they will best not off-load integrity checks. >5. A separate header and data CRC allows two things - one is >to overcome the bugaboo about direct data placement, the second >about allowing data protection to be stripped while data is >DMAed to the host and eliminating another potential source of >corruption (in the chip buffers). Two CRC serves no purpose as the transport protection checks must be done in conjunction prior to validating the packet for placement purposes thus a single CRC provides the same level of protection at a lower cost. >6. Perceived reliability is a feature of deployments and not >of applications. That is why HA features are optional and >deployed as needed (in systems, configurations, network >equipment ...), and people buy different types of equipment >at different price points. Something as simple as ECC memory >is not uniformly found in systems. ECC memory is becoming the standard for servers and storage these days. It may eventually work its way into clients. In any case, the debate is on the value of having a mandatory CRC not on HA which is a separate topic. Mike _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 15:13:22 2003 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 PAA04486 for ; Tue, 6 May 2003 15:13:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46JM0h20000 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 15:22:00 -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 h46JM0819997 for ; Tue, 6 May 2003 15:22:00 -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 PAA04423 for ; Tue, 6 May 2003 15:12:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7ty-0001WG-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 15:14:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D7tx-0001WD-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 15:14:57 -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 h46JL5819948; Tue, 6 May 2003 15:21:05 -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 h46JJ7819829 for ; Tue, 6 May 2003 15:19:07 -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 PAA04093 for ; Tue, 6 May 2003 15:09:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7rA-0001V2-00 for rddp@ietf.org; Tue, 06 May 2003 15:12:05 -0400 Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx with esmtp (Exim 4.12) id 19D7rA-0001Us-00 for rddp@ietf.org; Tue, 06 May 2003 15:12:04 -0400 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 9CBB9BF21 for ; Tue, 6 May 2003 14:12:24 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 6 May 2003 14:12:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] CRC mandatory? Date: Tue, 6 May 2003 14:12:17 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F87240314316A@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] CRC mandatory? Thread-Index: AcMT+cJ9WXK32N5NRmyFR52oie5gjQABe1oQ From: "Barron, Dwight" To: "Mogul, Jeffrey (HPL Palo Alto)" , X-OriginalArrivalTime: 06 May 2003 19:12:24.0531 (UTC) FILETIME=[6D282230:01C31403] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h46JJ7819830 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jeff, I agree that collecting quantitative data can be useful, but also believe that when it is being used to settle qualitative arguments the thresholds of acceptability are best set before the numbers are in. In a previous posting Jim Williams had stated that something in the same order of magnitude as the TCP stack on a per byte basis was not acceptable. I have not seen any comments on what would be acceptable overhead/criteria in order to gain consensus support of a mandatory CRC, nor any guidance on the parameters or type of environment to measure (but I agree that Sparc numbers circa 1995 aren't a good candidate). While I am not volunteering to collect the data yet, this is a hint that I could be coerced into doing so if it would lead to a more rapid consensus. However, determining an acceptable overhead is only one side of the equation, determining the acceptable level of reliability is the other. I continue to find the quantitative conclusions in the paper "When the CRC and TCP checksum disagree" http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf much more convincing than the qualitative arguments of "I use XYZ file servers all the time and they work just fine." Finally, when making an overhead vs. reliability architectural decision, one should realize that while Moore's Law is clearly on the side of lowering overhead over time, the reliability method is fixed for a very long time, in the face of constant or ever increasing errors per unit of time. If I have to bet incorrectly on an architectural decision, I like having time on my side. Regards, Dwight > -----Original Message----- > From: Mogul, Jeffrey (HPL Palo Alto) > Sent: Tuesday, May 06, 2003 12:58 PM > To: rddp@ietf.org > Subject: Re: [rddp] CRC mandatory? > > > It seems to me that one (but NOT the only) consideration in this > discussion is whether CRC calculation is really a burden for a > software implementation. I've seen qualitative assertions > (some vaguer than others) on both sides, but nothing quantitative. > > RFC 3309 ("Stream Control Transmission Protocol (SCTP) > Checksum Change") > has an appendix about CRC implementations, and briefly discusses > the issue. It cites > > David C. Feldmeier > Fast software implementation of error detection codes > IEEE Transactions on Networking, vol 3 no 6, pp 640-651, > December, 1995. > > Unfortunately, measurements made in 1995 on a SPARCstation LX > (27 SPECint932) probably won't mean much in 2003. > > I spent a little time with CiteSeer and Google trying to find > a more recent study of CRC performance, but I couldn't find > anything. > > Perhaps someone with a good understanding of software CRC > implementation could do some measurements on modern hardware > that would give a solid quantitative basis for our debate? > For example, one could hack the Linux or *BSD stack to > do a CRC computation on each TCP segment (sent or received), > then throw away the results. Measuring the performance change > on bulk throughput (say, using netperf) seems like a reasonable > approximation of software CRC costs. > > -Jeff > > P.S.: Don't look at me! I don't have any spare time this month, > nor do I have a "good understanding of software CRC implementation". > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 15:33:19 2003 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 PAA05511 for ; Tue, 6 May 2003 15:33:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46JfvC21886 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 15:41:57 -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 h46Jfv821883 for ; Tue, 6 May 2003 15:41:57 -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 PAA05478 for ; Tue, 6 May 2003 15:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D8DG-0001fv-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 15:34:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D8DG-0001fs-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 15:34:54 -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 h46Jf2821841; Tue, 6 May 2003 15:41:02 -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 h46Jev821819 for ; Tue, 6 May 2003 15:40:57 -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 PAA05407 for ; Tue, 6 May 2003 15:31:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D8CI-0001eb-00 for rddp@ietf.org; Tue, 06 May 2003 15:33:54 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19D8CH-0001eK-00 for rddp@ietf.org; Tue, 06 May 2003 15:33:54 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 3DA95D36E; Tue, 6 May 2003 12:34:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CB7132BE1; Tue, 6 May 2003 12:34:09 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 6 May 2003 12:33:46 -0700 From: "Somesh Gupta" Importance: Normal In-Reply-To: <01CA1B1F74A4EC40A9C887F7B58F87240314316A@cceexc16.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 05655-13A9824B; Tue, 06 May 2003 12:33:41 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id 8CC1912A79; Tue, 6 May 2003 12:33:41 -0700 (PDT) Subject: RE: [rddp] CRC mandatory? To: "Barron, Dwight" , "Mogul, Jeffrey (HPL Palo Alto)" , X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The paper is an excellent arguement for not offloading integrity checks. A study of types of errors encountered is interesting. A single CRC generated at the egress point, and checked at the ingress point, would not catch 99% of the errors listed because the CRC would be added to corrupted data or data be corrupted after CRC check was done. > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > Barron, Dwight > Sent: Tuesday, May 06, 2003 12:12 PM > To: Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > Subject: RE: [rddp] CRC mandatory? > > > Jeff, I agree that collecting quantitative data can be useful, > but also believe that when it is being used to settle qualitative > arguments the thresholds of acceptability are best set before the > numbers are in. In a previous posting Jim Williams had stated > that something in the same order of magnitude as the TCP stack on > a per byte basis was not acceptable. I have not seen any comments > on what would be acceptable overhead/criteria in order to gain > consensus support of a mandatory CRC, nor any guidance on the > parameters or type of environment to measure (but I agree that > Sparc numbers circa 1995 aren't a good candidate). While I am not > volunteering to collect the data yet, this is a hint that I could > be coerced into doing so if it would lead to a more rapid consensus. > > However, determining an acceptable overhead is only one side of > the equation, determining the acceptable level of reliability is > the other. I continue to find the quantitative conclusions in the > paper "When the CRC and TCP checksum disagree" > http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf > much more convincing than the qualitative arguments of "I use XYZ > file servers all the time and they work just fine." > > Finally, when making an overhead vs. reliability architectural > decision, one should realize that while Moore's Law is clearly on > the side of lowering overhead over time, the reliability method > is fixed for a very long time, in the face of constant or ever > increasing errors per unit of time. If I have to bet incorrectly > on an architectural decision, I like having time on my side. > > Regards, > Dwight > > > > -----Original Message----- > > From: Mogul, Jeffrey (HPL Palo Alto) > > Sent: Tuesday, May 06, 2003 12:58 PM > > To: rddp@ietf.org > > Subject: Re: [rddp] CRC mandatory? > > > > > > It seems to me that one (but NOT the only) consideration in this > > discussion is whether CRC calculation is really a burden for a > > software implementation. I've seen qualitative assertions > > (some vaguer than others) on both sides, but nothing quantitative. > > > > RFC 3309 ("Stream Control Transmission Protocol (SCTP) > > Checksum Change") > > has an appendix about CRC implementations, and briefly discusses > > the issue. It cites > > > > David C. Feldmeier > > Fast software implementation of error detection codes > > IEEE Transactions on Networking, vol 3 no 6, pp 640-651, > > December, 1995. > > > > Unfortunately, measurements made in 1995 on a SPARCstation LX > > (27 SPECint932) probably won't mean much in 2003. > > > > I spent a little time with CiteSeer and Google trying to find > > a more recent study of CRC performance, but I couldn't find > > anything. > > > > Perhaps someone with a good understanding of software CRC > > implementation could do some measurements on modern hardware > > that would give a solid quantitative basis for our debate? > > For example, one could hack the Linux or *BSD stack to > > do a CRC computation on each TCP segment (sent or received), > > then throw away the results. Measuring the performance change > > on bulk throughput (say, using netperf) seems like a reasonable > > approximation of software CRC costs. > > > > -Jeff > > > > P.S.: Don't look at me! I don't have any spare time this month, > > nor do I have a "good understanding of software CRC implementation". > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 16:16:09 2003 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 QAA06833 for ; Tue, 6 May 2003 16:16:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46KOkF24653 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 16:24:46 -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 h46KOk824650 for ; Tue, 6 May 2003 16:24:46 -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 QAA06819 for ; Tue, 6 May 2003 16:15:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D8sh-0001yd-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 16:17:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D8sg-0001ya-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 16:17:42 -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 h46KN5824570; Tue, 6 May 2003 16:23:05 -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 h46KL7824388 for ; Tue, 6 May 2003 16:21:07 -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 QAA06673 for ; Tue, 6 May 2003 16:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D8pA-0001wD-00 for rddp@ietf.org; Tue, 06 May 2003 16:14:04 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19D8p9-0001w5-00 for rddp@ietf.org; Tue, 06 May 2003 16:14:03 -0400 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id BEF19AEE5; Tue, 6 May 2003 15:14:24 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 6 May 2003 15:14:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] CRC mandatory? Date: Tue, 6 May 2003 15:14:24 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F87240314316B@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] CRC mandatory? Thread-Index: AcMUBoOG6AU7cHVISRaH8GxLIRQOkAAAs9bg From: "Barron, Dwight" To: "Somesh Gupta" , X-OriginalArrivalTime: 06 May 2003 20:14:24.0687 (UTC) FILETIME=[168AE3F0:01C3140C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h46KL7824389 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I don't agree with that assessment. MPA CRC is layered above the TCP checksum/logic. The key is to have different fault behaviors, e.g. any latent faults in CRC logic are significantly different from the latent faults in the TCP protocol/checksum logic. I believe this independent fault behavior is quite achievable in both layered and roto-tilled implementations. Regards, Dwight > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Tuesday, May 06, 2003 2:34 PM > To: Barron, Dwight; Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > Subject: RE: [rddp] CRC mandatory? > > > The paper is an excellent arguement for not offloading > integrity checks. A study of types of errors encountered > is interesting. A single CRC generated at the egress point, > and checked at the ingress point, would not catch 99% of > the errors listed because the CRC would be added to corrupted > data or data be corrupted after CRC check was done. > > > -----Original Message----- > > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > > Barron, Dwight > > Sent: Tuesday, May 06, 2003 12:12 PM > > To: Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > > Subject: RE: [rddp] CRC mandatory? > > > > > > Jeff, I agree that collecting quantitative data can be useful, > > but also believe that when it is being used to settle qualitative > > arguments the thresholds of acceptability are best set before the > > numbers are in. In a previous posting Jim Williams had stated > > that something in the same order of magnitude as the TCP stack on > > a per byte basis was not acceptable. I have not seen any comments > > on what would be acceptable overhead/criteria in order to gain > > consensus support of a mandatory CRC, nor any guidance on the > > parameters or type of environment to measure (but I agree that > > Sparc numbers circa 1995 aren't a good candidate). While I am not > > volunteering to collect the data yet, this is a hint that I could > > be coerced into doing so if it would lead to a more rapid consensus. > > > > However, determining an acceptable overhead is only one side of > > the equation, determining the acceptable level of reliability is > > the other. I continue to find the quantitative conclusions in the > > paper "When the CRC and TCP checksum disagree" > > > http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf > > much more convincing than the qualitative arguments of "I use XYZ > > file servers all the time and they work just fine." > > > > Finally, when making an overhead vs. reliability architectural > > decision, one should realize that while Moore's Law is clearly on > > the side of lowering overhead over time, the reliability method > > is fixed for a very long time, in the face of constant or ever > > increasing errors per unit of time. If I have to bet incorrectly > > on an architectural decision, I like having time on my side. > > > > Regards, > > Dwight > > > > > > > -----Original Message----- > > > From: Mogul, Jeffrey (HPL Palo Alto) > > > Sent: Tuesday, May 06, 2003 12:58 PM > > > To: rddp@ietf.org > > > Subject: Re: [rddp] CRC mandatory? > > > > > > > > > It seems to me that one (but NOT the only) consideration in this > > > discussion is whether CRC calculation is really a burden for a > > > software implementation. I've seen qualitative assertions > > > (some vaguer than others) on both sides, but nothing quantitative. > > > > > > RFC 3309 ("Stream Control Transmission Protocol (SCTP) > > > Checksum Change") > > > has an appendix about CRC implementations, and briefly discusses > > > the issue. It cites > > > > > > David C. Feldmeier > > > Fast software implementation of error detection codes > > > IEEE Transactions on Networking, vol 3 no 6, pp 640-651, > > > December, 1995. > > > > > > Unfortunately, measurements made in 1995 on a SPARCstation LX > > > (27 SPECint932) probably won't mean much in 2003. > > > > > > I spent a little time with CiteSeer and Google trying to find > > > a more recent study of CRC performance, but I couldn't find > > > anything. > > > > > > Perhaps someone with a good understanding of software CRC > > > implementation could do some measurements on modern hardware > > > that would give a solid quantitative basis for our debate? > > > For example, one could hack the Linux or *BSD stack to > > > do a CRC computation on each TCP segment (sent or received), > > > then throw away the results. Measuring the performance change > > > on bulk throughput (say, using netperf) seems like a reasonable > > > approximation of software CRC costs. > > > > > > -Jeff > > > > > > P.S.: Don't look at me! I don't have any spare time this month, > > > nor do I have a "good understanding of software CRC > implementation". > > > _______________________________________________ > > > rddp mailing list > > > rddp@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rddp > > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 16:32:07 2003 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 QAA07405 for ; Tue, 6 May 2003 16:32:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46KejG26597 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 16:40:45 -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 h46Kei826594 for ; Tue, 6 May 2003 16:40:44 -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 QAA07355 for ; Tue, 6 May 2003 16:31:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D989-00025K-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 16:33:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D988-00025H-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 16:33:40 -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 h46Ke2826441; Tue, 6 May 2003 16:40:02 -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 h46Kcm826313 for ; Tue, 6 May 2003 16:38:48 -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 QAA07318 for ; Tue, 6 May 2003 16:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D96H-000253-00 for rddp@ietf.org; Tue, 06 May 2003 16:31:45 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19D96G-00024o-00 for rddp@ietf.org; Tue, 06 May 2003 16:31:44 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 42716D36E; Tue, 6 May 2003 13:31:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 31BAB21218; Tue, 6 May 2003 13:32:01 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 6 May 2003 13:31:46 -0700 From: "Somesh Gupta" Importance: Normal In-Reply-To: <01CA1B1F74A4EC40A9C887F7B58F87240314316B@cceexc16.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 07757-30A919F4; Tue, 06 May 2003 13:31:41 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id CB19D21111; Tue, 6 May 2003 13:31:41 -0700 (PDT) Subject: RE: [rddp] CRC mandatory? To: "Barron, Dwight" , X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, CRC32 and TCP checksum behave differently in the errors that escape or that they catch. However, I assume the paper was quoted to bring up the point of number of TCP checksum errors encountered in the real world. I have requested this information before but not had an answer yet. A number of the participants work in large corporations that have data centers and systems that stay up for years. It would be useful to bring the number of TCP checksum errors encountered in those systems (assuming they do not have telnet access from outside). In my past experience, it was practically nill. Somesh > -----Original Message----- > From: Barron, Dwight [mailto:Dwight.Barron@hp.com] > Sent: Tuesday, May 06, 2003 1:14 PM > To: Somesh Gupta; rddp@ietf.org > Subject: RE: [rddp] CRC mandatory? > > > I don't agree with that assessment. MPA CRC is layered above the > TCP checksum/logic. The key is to have different fault behaviors, > e.g. any latent faults in CRC logic are significantly different > from the latent faults in the TCP protocol/checksum logic. I > believe this independent fault behavior is quite achievable in > both layered and roto-tilled implementations. > > Regards, > Dwight > > > -----Original Message----- > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > Sent: Tuesday, May 06, 2003 2:34 PM > > To: Barron, Dwight; Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > > Subject: RE: [rddp] CRC mandatory? > > > > > > The paper is an excellent arguement for not offloading > > integrity checks. A study of types of errors encountered > > is interesting. A single CRC generated at the egress point, > > and checked at the ingress point, would not catch 99% of > > the errors listed because the CRC would be added to corrupted > > data or data be corrupted after CRC check was done. > > > > > -----Original Message----- > > > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > > > Barron, Dwight > > > Sent: Tuesday, May 06, 2003 12:12 PM > > > To: Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > > > Subject: RE: [rddp] CRC mandatory? > > > > > > > > > Jeff, I agree that collecting quantitative data can be useful, > > > but also believe that when it is being used to settle qualitative > > > arguments the thresholds of acceptability are best set before the > > > numbers are in. In a previous posting Jim Williams had stated > > > that something in the same order of magnitude as the TCP stack on > > > a per byte basis was not acceptable. I have not seen any comments > > > on what would be acceptable overhead/criteria in order to gain > > > consensus support of a mandatory CRC, nor any guidance on the > > > parameters or type of environment to measure (but I agree that > > > Sparc numbers circa 1995 aren't a good candidate). While I am not > > > volunteering to collect the data yet, this is a hint that I could > > > be coerced into doing so if it would lead to a more rapid consensus. > > > > > > However, determining an acceptable overhead is only one side of > > > the equation, determining the acceptable level of reliability is > > > the other. I continue to find the quantitative conclusions in the > > > paper "When the CRC and TCP checksum disagree" > > > > > http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf > > > much more convincing than the qualitative arguments of "I use XYZ > > > file servers all the time and they work just fine." > > > > > > Finally, when making an overhead vs. reliability architectural > > > decision, one should realize that while Moore's Law is clearly on > > > the side of lowering overhead over time, the reliability method > > > is fixed for a very long time, in the face of constant or ever > > > increasing errors per unit of time. If I have to bet incorrectly > > > on an architectural decision, I like having time on my side. > > > > > > Regards, > > > Dwight > > > > > > > > > > -----Original Message----- > > > > From: Mogul, Jeffrey (HPL Palo Alto) > > > > Sent: Tuesday, May 06, 2003 12:58 PM > > > > To: rddp@ietf.org > > > > Subject: Re: [rddp] CRC mandatory? > > > > > > > > > > > > It seems to me that one (but NOT the only) consideration in this > > > > discussion is whether CRC calculation is really a burden for a > > > > software implementation. I've seen qualitative assertions > > > > (some vaguer than others) on both sides, but nothing quantitative. > > > > > > > > RFC 3309 ("Stream Control Transmission Protocol (SCTP) > > > > Checksum Change") > > > > has an appendix about CRC implementations, and briefly discusses > > > > the issue. It cites > > > > > > > > David C. Feldmeier > > > > Fast software implementation of error detection codes > > > > IEEE Transactions on Networking, vol 3 no 6, pp 640-651, > > > > December, 1995. > > > > > > > > Unfortunately, measurements made in 1995 on a SPARCstation LX > > > > (27 SPECint932) probably won't mean much in 2003. > > > > > > > > I spent a little time with CiteSeer and Google trying to find > > > > a more recent study of CRC performance, but I couldn't find > > > > anything. > > > > > > > > Perhaps someone with a good understanding of software CRC > > > > implementation could do some measurements on modern hardware > > > > that would give a solid quantitative basis for our debate? > > > > For example, one could hack the Linux or *BSD stack to > > > > do a CRC computation on each TCP segment (sent or received), > > > > then throw away the results. Measuring the performance change > > > > on bulk throughput (say, using netperf) seems like a reasonable > > > > approximation of software CRC costs. > > > > > > > > -Jeff > > > > > > > > P.S.: Don't look at me! I don't have any spare time this month, > > > > nor do I have a "good understanding of software CRC > > implementation". > > > > _______________________________________________ > > > > rddp mailing list > > > > rddp@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rddp > > > > > > > _______________________________________________ > > > rddp mailing list > > > rddp@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rddp > > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 17:04:13 2003 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 RAA08969 for ; Tue, 6 May 2003 17:04:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46LCqp30227 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 17:12:52 -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 h46LCp830224 for ; Tue, 6 May 2003 17:12:51 -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 RAA08961 for ; Tue, 6 May 2003 17:03:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D9dD-0002Us-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 17:05:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D9dC-0002Up-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 17:05:46 -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 h46LC4830172; Tue, 6 May 2003 17:12:04 -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 h46LBw830130 for ; Tue, 6 May 2003 17:11:58 -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 RAA08914 for ; Tue, 6 May 2003 17:02:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D9cM-0002UP-00 for rddp@ietf.org; Tue, 06 May 2003 17:04:54 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 19D9cL-0002UM-00 for rddp@ietf.org; Tue, 06 May 2003 17:04:53 -0400 Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by palrel13.hp.com (Postfix) with ESMTP id 93EBE1C00E18 for ; Tue, 6 May 2003 14:05:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.9/8.12.2) with SMTP id h46L5YVn010943 for rddp@ietf.org; Tue, 6 May 2003 14:05:34 -0700 (PDT) From: Jeffrey Mogul Message-Id: <200305062105.h46L5YVn010943@wera.hpl.hp.com> X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol To: Subject: Re: [rddp] CRC mandatory? In-reply-to: Your message of "Tue, 06 May 2003 14:12:17 CDT." <01CA1B1F74A4EC40A9C887F7B58F87240314316A@cceexc16.americas.cpqcorp.net> X-Organization: Hewlett-Packard Labs, Large Scale Systems group Date: Tue, 06 May 2003 14:05:34 -0700 X-Mts: smtp 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Dwight Barron wrote: Jeff, I agree that collecting quantitative data can be useful, but also believe that when it is being used to settle qualitative arguments the thresholds of acceptability are best set before the numbers are in. In a perfect world, I might agree. In reality, it might be hard to get an actual consensus about a specific threshold that everyone would accept. My hope/suspicion is that by getting some measurements, we might simply avoid having a new debate over thresholds. Finally, when making an overhead vs. reliability architectural decision, one should realize that while Moore's Law is clearly on the side of lowering overhead over time, the reliability method is fixed for a very long time, in the face of constant or ever increasing errors per unit of time. If I have to bet incorrectly on an architectural decision, I like having time on my side. Which raises another point: if we can get someone to do software CRC measurements, it would be helpful to get them from a range of CPU speeds (e.g., different generations of the same basic architecture) so that we can get quantitative information about the effect of Moore's Law on the results. In general, I agree with you (don't bet against Moore's Law) but I can see where there might be some future debate about whether Moore's Law really applies to a specific measurement, and having credible experimental results for several points on the trend line might avoid basing the discussion on hypotheticals. -Jeff _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 18:31:18 2003 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 SAA12506 for ; Tue, 6 May 2003 18:31:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Mdwp04467 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 18:39:58 -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 h46Mdw804464 for ; Tue, 6 May 2003 18:39:58 -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 SAA12475 for ; Tue, 6 May 2003 18:30:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAzU-00036F-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 18:32:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DAzT-00036C-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 18:32:51 -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 h46Md9804416; Tue, 6 May 2003 18:39:09 -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 h46McC804273 for ; Tue, 6 May 2003 18:38:12 -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 SAA12399 for ; Tue, 6 May 2003 18:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAxl-00034i-00 for rddp@ietf.org; Tue, 06 May 2003 18:31:05 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 19DAxl-00034f-00 for rddp@ietf.org; Tue, 06 May 2003 18:31:05 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id 7A4D91C00AEF for ; Tue, 6 May 2003 15:31:51 -0700 (PDT) Received: from mk731915.cup.hp.com ([15.8.80.111]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id h46MRlE16652 for ; Tue, 6 May 2003 15:27:47 -0700 (PDT) Message-Id: <5.1.0.14.2.20030506151948.027ffc70@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 May 2003 15:25:10 -0700 To: From: Michael Krause Subject: RE: [rddp] CRC mandatory? In-Reply-To: References: <01CA1B1F74A4EC40A9C887F7B58F87240314316B@cceexc16.americas.cpqcorp.net> 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , At 01:31 PM 5/6/2003 -0700, Somesh Gupta wrote: >Yes, CRC32 and TCP checksum behave differently in the errors >that escape or that they catch. However, I assume the paper >was quoted to bring up the point of number of TCP checksum >errors encountered in the real world. > >I have requested this information before but not had an >answer yet. A number of the participants work in large >corporations that have data centers and systems that stay >up for years. It would be useful to bring the number of >TCP checksum errors encountered in those systems (assuming >they do not have telnet access from outside). In my past >experience, it was practically nill. - RDDP charter is not restricted to the data center but for all usage modes where IP technology may be deployed. - Many data centers still operate using 100 Mbps links today thus any error rates detected may not accurately be projected to remain true when operating at 10 Gbps or even 100 Gbps (which are the data rates that will be supported during the life span of the RDDP technology). - Many technologies are choosing to provide strong data integrity for much shorter distances than a data center to protect against data corruption causing a local DMA to target the wrong memory. Remote DMA should provide similar protections as for local DMA thus providing customers with strong end-to-end data integrity. Sorry to re-iterate but it is critical to understand that Remote DMA and local DMA are really only a change in wire protocol to state where data should be placed - the semantics are in essence the same which is why I strongly back requiring a mandatory end-to-end CRC. Mike >Somesh > > > -----Original Message----- > > From: Barron, Dwight [mailto:Dwight.Barron@hp.com] > > Sent: Tuesday, May 06, 2003 1:14 PM > > To: Somesh Gupta; rddp@ietf.org > > Subject: RE: [rddp] CRC mandatory? > > > > > > I don't agree with that assessment. MPA CRC is layered above the > > TCP checksum/logic. The key is to have different fault behaviors, > > e.g. any latent faults in CRC logic are significantly different > > from the latent faults in the TCP protocol/checksum logic. I > > believe this independent fault behavior is quite achievable in > > both layered and roto-tilled implementations. > > > > Regards, > > Dwight > > > > > -----Original Message----- > > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > > Sent: Tuesday, May 06, 2003 2:34 PM > > > To: Barron, Dwight; Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > > > Subject: RE: [rddp] CRC mandatory? > > > > > > > > > The paper is an excellent arguement for not offloading > > > integrity checks. A study of types of errors encountered > > > is interesting. A single CRC generated at the egress point, > > > and checked at the ingress point, would not catch 99% of > > > the errors listed because the CRC would be added to corrupted > > > data or data be corrupted after CRC check was done. > > > > > > > -----Original Message----- > > > > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > > > > Barron, Dwight > > > > Sent: Tuesday, May 06, 2003 12:12 PM > > > > To: Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > > > > Subject: RE: [rddp] CRC mandatory? > > > > > > > > > > > > Jeff, I agree that collecting quantitative data can be useful, > > > > but also believe that when it is being used to settle qualitative > > > > arguments the thresholds of acceptability are best set before the > > > > numbers are in. In a previous posting Jim Williams had stated > > > > that something in the same order of magnitude as the TCP stack on > > > > a per byte basis was not acceptable. I have not seen any comments > > > > on what would be acceptable overhead/criteria in order to gain > > > > consensus support of a mandatory CRC, nor any guidance on the > > > > parameters or type of environment to measure (but I agree that > > > > Sparc numbers circa 1995 aren't a good candidate). While I am not > > > > volunteering to collect the data yet, this is a hint that I could > > > > be coerced into doing so if it would lead to a more rapid consensus. > > > > > > > > However, determining an acceptable overhead is only one side of > > > > the equation, determining the acceptable level of reliability is > > > > the other. I continue to find the quantitative conclusions in the > > > > paper "When the CRC and TCP checksum disagree" > > > > > > > http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf > > > > much more convincing than the qualitative arguments of "I use XYZ > > > > file servers all the time and they work just fine." > > > > > > > > Finally, when making an overhead vs. reliability architectural > > > > decision, one should realize that while Moore's Law is clearly on > > > > the side of lowering overhead over time, the reliability method > > > > is fixed for a very long time, in the face of constant or ever > > > > increasing errors per unit of time. If I have to bet incorrectly > > > > on an architectural decision, I like having time on my side. > > > > > > > > Regards, > > > > Dwight > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mogul, Jeffrey (HPL Palo Alto) > > > > > Sent: Tuesday, May 06, 2003 12:58 PM > > > > > To: rddp@ietf.org > > > > > Subject: Re: [rddp] CRC mandatory? > > > > > > > > > > > > > > > It seems to me that one (but NOT the only) consideration in this > > > > > discussion is whether CRC calculation is really a burden for a > > > > > software implementation. I've seen qualitative assertions > > > > > (some vaguer than others) on both sides, but nothing quantitative. > > > > > > > > > > RFC 3309 ("Stream Control Transmission Protocol (SCTP) > > > > > Checksum Change") > > > > > has an appendix about CRC implementations, and briefly discusses > > > > > the issue. It cites > > > > > > > > > > David C. Feldmeier > > > > > Fast software implementation of error detection codes > > > > > IEEE Transactions on Networking, vol 3 no 6, pp 640-651, > > > > > December, 1995. > > > > > > > > > > Unfortunately, measurements made in 1995 on a SPARCstation LX > > > > > (27 SPECint932) probably won't mean much in 2003. > > > > > > > > > > I spent a little time with CiteSeer and Google trying to find > > > > > a more recent study of CRC performance, but I couldn't find > > > > > anything. > > > > > > > > > > Perhaps someone with a good understanding of software CRC > > > > > implementation could do some measurements on modern hardware > > > > > that would give a solid quantitative basis for our debate? > > > > > For example, one could hack the Linux or *BSD stack to > > > > > do a CRC computation on each TCP segment (sent or received), > > > > > then throw away the results. Measuring the performance change > > > > > on bulk throughput (say, using netperf) seems like a reasonable > > > > > approximation of software CRC costs. > > > > > > > > > > -Jeff > > > > > > > > > > P.S.: Don't look at me! I don't have any spare time this month, > > > > > nor do I have a "good understanding of software CRC > > > implementation". > > > > > _______________________________________________ > > > > > rddp mailing list > > > > > rddp@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/rddp > > > > > > > > > _______________________________________________ > > > > rddp mailing list > > > > rddp@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rddp > > > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 19:28:55 2003 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 TAA14045 for ; Tue, 6 May 2003 19:28:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Nbb808468 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 19:37:37 -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 h46Nbb808465 for ; Tue, 6 May 2003 19:37: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 TAA14036 for ; Tue, 6 May 2003 19:28:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBtF-0003Rr-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 19:30:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DBtF-0003Ro-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 19:30:29 -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 h46Nas807562; Tue, 6 May 2003 19:36:54 -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 h46NYw807464 for ; Tue, 6 May 2003 19:34:58 -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 TAA13970; Tue, 6 May 2003 19:25:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBqh-0003Qm-00; Tue, 06 May 2003 19:27:51 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19DBqg-0003Q5-00; Tue, 06 May 2003 19:27:50 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h46NSAuT170080; Tue, 6 May 2003 19:28:10 -0400 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h46NSAfP102272; Tue, 6 May 2003 17:28:10 -0600 To: Caitlin Bestler Cc: rddp@ietf.org, rddp-admin@ietf.org MIME-Version: 1.0 Subject: RE: [rddp] CRC mandatory? X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Tue, 6 May 2003 16:27:55 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/06/2003 17:28:09, Serialize complete at 05/06/2003 17:28:09 Content-Type: multipart/alternative; boundary="=_alternative 0080E64D88256D1E_=" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0080E64D88256D1E_= Content-Type: text/plain; charset="us-ascii" Caitlin, I also believe strongly in what you have stated. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com Caitlin Bestler Sent by: rddp-admin@ietf.org 05/06/2003 09:42 AM To: rddp@ietf.org cc: Subject: RE: [rddp] CRC mandatory? I believe there are some fundamental issues regarding making CRC coverage optional. The first is exactly what is our starting point? My understanding is that we are defining RDMA over reliable IP transports and that we should be cleanly layered. So, which interpretation to we make of "cleanly layered": a) We define uniform expectations of the transport layer, and provide adaptation layers to fill the gap between those expectations and the existing IP transports. b) We add adaptation layer features *only* as required to make DDP work, leaving each transport mapping as close to the original transport as possible. The "uniform transport layer requirements" basically match SCTP. Basically because RDDP requires unordered delivery while preserving the order of submission, this required the addition of the DDP-SSN in a very thin adaptation layer. It has been agreed that MPA adds framing and markers if the receiver wants them. So the debate is whether MPA should provide a standard level of protection (i.e. end-to-end CRC32C on the entire DDP Segment), or whether we have to justify *each* addition to TCP as being specifically required by RDDP. I am a firm advocate of the "uniform expectations" approach. This is mostly because I believe that applications developers believe even more firmly in uniform expectations, and will achieve it by lowering their expectations to match the lowest common denominator. There are two guides as to what constitutes a reasonable expectation for reliable transport for RDMA protocols: SCTP and InfiniBand. SCTP is relevant because it is the reliable transport most recently defined by the IETF. InfiniBand is relevant because many of the ULPs that RDMAP/RDDP plans on supporting will also run over InfiniBand. Having the adaptation layer raise all transports to a uniform layer that matches the needs of RDDP makes much more sense to me than having all applications conform to the worst transport over which RDDP will run. The LCD approach *will* waste effort, because ULP integrity checks will be applied redundantly to SCTP's CRC32c. Further, even if we accept the need to justify each feature within MPA on an RDDP-specific basis, there is definitely a need for coverage of the DDP and RDMAP headers. I have not seen a single refutation to the following: -- There are applications where there is trust between the ULP peers. That is, the Data Sink ULP feels no need to protect itself from maliscious attacks by its peer. There is sufficient containment of damage from other clients and/or sufficient authentication of the peer. Whether a given ULP should or should not work from this model is irrelevant here. Clearly there are are applications where this is true, and they should be supported. -- There are applications that require a higher level of protection than afforded by TCP's 16 bit checksum. -- There are applications where the server wishes to allow the client to have multiple requests in-flight. There are even applications where all of the above apply. A DAFS Client requires more than a TCP 16 bit checksum, trusts the DAFS server and can have a sequence of read requests pending at the same instant. Without adequate protection for the DDP header, the ULP would be forced to have only a single STag open on the connection at any given time. That would mean that a DAFS client running over MPA/TCP would be less capable than one running over SCTP or IB. All three objectives cited above could be met via either IB or SCTP. I believe that clearly establishes an RDDP specific need to cover at least the headers. The cost of covering the entire DDP Segment is trivial compared to that. But making the length of the coverage variable is an option, which means it adds cost. See earlier posts on markers. Just because we decided that one option was justified does not make the comments on why options are expensive any less valid or relevant. Options are an ongoing complexity that must be continuously retested. They represent a perpetual drain of QA resources. A properly designed receiver can evaluate multiple CRCs and/or checksums in parallel during a single scan over memory. The calculations required for a CRC32C are minor, and no additional memory touches are required. Even if each addition to MPA must be justified, the simplicity of covering the complete DDP Segment would outweigh the benefits of allowing a handful of applications to omit some trivial calculations over the payload-only portions. If we accept the goal of providing uniform transport expectations to the ULP across all forms of reliable RDMA networks then matching both SCTP and IB with CRC coverage of the entire payload is clearly the only choice. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --=_alternative 0080E64D88256D1E_= Content-Type: text/html; charset="us-ascii"
Caitlin,
I also believe strongly in what you have stated.  
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


Caitlin Bestler <cait@asomi.com>
Sent by: rddp-admin@ietf.org

05/06/2003 09:42 AM

       
        To:        rddp@ietf.org
        cc:        
        Subject:        RE: [rddp]  CRC mandatory?



I believe there are some fundamental issues regarding making
CRC coverage optional.

The first is exactly what is our starting point?

My understanding is that we are defining RDMA over reliable
IP transports and that we should be cleanly layered.

So, which interpretation to we make of "cleanly layered":

a) We define uniform expectations of the transport layer,
  and provide adaptation layers to fill the gap between
  those expectations and the existing IP transports.
 
b) We add adaptation layer features *only* as required
  to make DDP work, leaving each transport mapping as
  close to the original transport as possible.
 
The "uniform transport layer requirements" basically match
SCTP. Basically because RDDP requires unordered delivery
while preserving the order of submission, this required
the addition of the DDP-SSN in a very thin adaptation layer.
It has been agreed that MPA adds framing and markers if the
receiver wants them.

So the debate is whether MPA should provide a standard level
of protection (i.e. end-to-end CRC32C on the entire DDP
Segment), or whether we have to justify *each* addition
to TCP as being specifically required by RDDP.

I am a firm advocate of the "uniform expectations" approach.
This is mostly because I believe that applications
developers believe even more firmly in uniform expectations,
and will achieve it by lowering their expectations to match
the lowest common denominator.

There are two guides as to what constitutes a reasonable
expectation for reliable transport for RDMA protocols: SCTP
and InfiniBand. SCTP is relevant because it is the reliable
transport most recently defined by the IETF. InfiniBand is
relevant because many of the ULPs that RDMAP/RDDP plans on
supporting will also run over InfiniBand.

Having the adaptation layer raise all transports to a
uniform layer that matches the needs of RDDP makes much
more sense to me than having all applications conform
to the worst transport over which RDDP will run.

The LCD approach *will* waste effort, because ULP integrity
checks will be applied redundantly to SCTP's CRC32c.

Further, even if we accept the need to justify each feature
within MPA on an RDDP-specific basis, there is definitely a
need for coverage of the DDP and RDMAP headers.

I have not seen a single refutation to the following:

-- There are applications where there is trust between
   the ULP peers. That is, the Data Sink ULP feels no
   need to protect itself from maliscious attacks by
   its peer. There is sufficient containment of damage
   from other clients and/or sufficient authentication
   of the peer.
   
   Whether a given ULP should or should not work from
   this model is irrelevant here. Clearly there are
   are applications where this is true, and they should
   be supported.
   
--  There are applications that require a higher level
   of protection than afforded by TCP's 16 bit checksum.
   
--  There are applications where the server wishes to allow
   the client to have multiple requests in-flight.
   
There are even applications where all of the above apply.
A DAFS Client requires more than a TCP 16 bit checksum,
trusts the DAFS server and can have a sequence of read
requests pending at the same instant.

Without adequate protection for the DDP header, the ULP
would be forced to have only a single STag open on the
connection at any given time.

That would mean that a DAFS client running over MPA/TCP
would be less capable than one running over SCTP or IB.
All three objectives cited above could be met via either
IB or SCTP.

I believe that clearly establishes an RDDP specific need
to cover at least the headers. The cost of covering the
entire DDP Segment is trivial compared to that.

But making the length of the coverage variable is an option,
which means it adds cost. See earlier posts on markers.

Just because we decided that one option was justified does
not make the comments on why options are expensive any less
valid or relevant. Options are an ongoing complexity that
must be continuously retested. They represent a perpetual
drain of QA resources.

A properly designed receiver can evaluate multiple CRCs
and/or checksums in parallel during a single scan over
memory. The calculations required for a CRC32C are minor,
and no additional memory touches are required.

Even if each addition to MPA must be justified, the
simplicity of covering the complete DDP Segment would
outweigh the benefits of allowing a handful of applications
to omit some trivial calculations over the payload-only
portions.

If we accept the goal of providing uniform transport
expectations to the ULP across all forms of reliable
RDMA networks then matching both SCTP and IB with
CRC coverage of the entire payload is clearly the only
choice.

   




Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

--=_alternative 0080E64D88256D1E_=-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 20:12:09 2003 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 UAA14930 for ; Tue, 6 May 2003 20:12:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h470KqX11098 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 20:20:52 -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 h470Kq811095 for ; Tue, 6 May 2003 20:20:52 -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 UAA14921 for ; Tue, 6 May 2003 20:11:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DCZ6-0003fw-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 20:13:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DCZ5-0003ft-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 20:13:43 -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 h470K8811052; Tue, 6 May 2003 20:20:08 -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 h470JP810963 for ; Tue, 6 May 2003 20:19:25 -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 UAA14844 for ; Tue, 6 May 2003 20:10:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DCXg-0003et-00 for rddp@ietf.org; Tue, 06 May 2003 20:12:16 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DCXf-0003eQ-00 for rddp@ietf.org; Tue, 06 May 2003 20:12:16 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h470CXQs239502; Tue, 6 May 2003 20:12:33 -0400 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h470CWfP133632; Tue, 6 May 2003 18:12:32 -0600 To: "Somesh Gupta" Cc: "Barron, Dwight" , "Mogul, Jeffrey (HPL Palo Alto)" , rddp@ietf.org, rddp-admin@ietf.org MIME-Version: 1.0 Subject: RE: [rddp] CRC mandatory? X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Tue, 6 May 2003 17:12:17 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/06/2003 18:12:33, Serialize complete at 05/06/2003 18:12:33 Content-Type: multipart/alternative; boundary="=_alternative 0001202088256D1F_=" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0001202088256D1F_= Content-Type: text/plain; charset="us-ascii" Somesh, You and I have had this discussion many times. And I have said that when you combine the results of that paper with the increase in speed that is now here and coming in the future, that it make a strong statement that CRC32c type checks are needed. As you know we made CRC32c a "MUST implement,, optional to use" in iSCSI. I have found no one within my company that would ever suggest to our customers that they should operate with CRC32c turned off. I have not heard that from our competitors either. In other words, we made a big deal of making it optional in iSCSI, but the folks that focus exclusively on storage, have, as far as I can determine made these checks the defacto way things operate. As you also know some folks are attempting to make an adaption which will enable iSCSI to operate with RDMA, however, without CRC32c covering the headers and data being a "required to implement" this would not be possible. The point that Caitlin and others are making is (in my opinion) that there are a number of applications that feel a CRC32c digest is needed. And we will have to make CRC32c at least a "required to implement (optional to use)", and that negotiating such an option is not worth the testing effort for the negation itself nor the testing that must occur at run time with each side having negotiated different options, etc.. Also they are stating that from their point of view, the requirement from customers such as my company, makes it a hard requirement. And since we and our competitors require such capability, the RNIC vendor needs to supply it even if some folks, like yourself, believe it is only a need spun from an urban legend that is causing the perceived need. So I think we should at least agree that it needs to be a MUST implement, and then focus on whether it needs to be optional to use. I personally do not want make it optional, and want to ensure that the whole packet is covered. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Somesh Gupta" Sent by: rddp-admin@ietf.org 05/06/2003 12:33 PM To: "Barron, Dwight" , "Mogul, Jeffrey (HPL Palo Alto)" , cc: Subject: RE: [rddp] CRC mandatory? The paper is an excellent arguement for not offloading integrity checks. A study of types of errors encountered is interesting. A single CRC generated at the egress point, and checked at the ingress point, would not catch 99% of the errors listed because the CRC would be added to corrupted data or data be corrupted after CRC check was done. > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > Barron, Dwight > Sent: Tuesday, May 06, 2003 12:12 PM > To: Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > Subject: RE: [rddp] CRC mandatory? > > > Jeff, I agree that collecting quantitative data can be useful, > but also believe that when it is being used to settle qualitative > arguments the thresholds of acceptability are best set before the > numbers are in. In a previous posting Jim Williams had stated > that something in the same order of magnitude as the TCP stack on > a per byte basis was not acceptable. I have not seen any comments > on what would be acceptable overhead/criteria in order to gain > consensus support of a mandatory CRC, nor any guidance on the > parameters or type of environment to measure (but I agree that > Sparc numbers circa 1995 aren't a good candidate). While I am not > volunteering to collect the data yet, this is a hint that I could > be coerced into doing so if it would lead to a more rapid consensus. > > However, determining an acceptable overhead is only one side of > the equation, determining the acceptable level of reliability is > the other. I continue to find the quantitative conclusions in the > paper "When the CRC and TCP checksum disagree" > http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf > much more convincing than the qualitative arguments of "I use XYZ > file servers all the time and they work just fine." > > Finally, when making an overhead vs. reliability architectural > decision, one should realize that while Moore's Law is clearly on > the side of lowering overhead over time, the reliability method > is fixed for a very long time, in the face of constant or ever > increasing errors per unit of time. If I have to bet incorrectly > on an architectural decision, I like having time on my side. > > Regards, > Dwight > > > > -----Original Message----- > > From: Mogul, Jeffrey (HPL Palo Alto) > > Sent: Tuesday, May 06, 2003 12:58 PM > > To: rddp@ietf.org > > Subject: Re: [rddp] CRC mandatory? > > > > > > It seems to me that one (but NOT the only) consideration in this > > discussion is whether CRC calculation is really a burden for a > > software implementation. I've seen qualitative assertions > > (some vaguer than others) on both sides, but nothing quantitative. > > > > RFC 3309 ("Stream Control Transmission Protocol (SCTP) > > Checksum Change") > > has an appendix about CRC implementations, and briefly discusses > > the issue. It cites > > > > David C. Feldmeier > > Fast software implementation of error detection codes > > IEEE Transactions on Networking, vol 3 no 6, pp 640-651, > > December, 1995. > > > > Unfortunately, measurements made in 1995 on a SPARCstation LX > > (27 SPECint932) probably won't mean much in 2003. > > > > I spent a little time with CiteSeer and Google trying to find > > a more recent study of CRC performance, but I couldn't find > > anything. > > > > Perhaps someone with a good understanding of software CRC > > implementation could do some measurements on modern hardware > > that would give a solid quantitative basis for our debate? > > For example, one could hack the Linux or *BSD stack to > > do a CRC computation on each TCP segment (sent or received), > > then throw away the results. Measuring the performance change > > on bulk throughput (say, using netperf) seems like a reasonable > > approximation of software CRC costs. > > > > -Jeff > > > > P.S.: Don't look at me! I don't have any spare time this month, > > nor do I have a "good understanding of software CRC implementation". > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --=_alternative 0001202088256D1F_= Content-Type: text/html; charset="us-ascii"
Somesh,
You and I have had this discussion many times.  And I have said that when you combine the results of that paper with the increase in speed that is now here and coming in the future,  that it make a strong statement that CRC32c type checks are needed.

As you know we made CRC32c  a "MUST implement,, optional to use" in iSCSI.  I have found no one within my company that would ever suggest to our customers that they should operate with CRC32c turned off.  I have not heard that from our competitors either.  In other words, we made a big deal of making it optional in iSCSI, but the folks that focus exclusively on storage, have, as far as I can determine made these checks the defacto way things operate.

As you also know some folks are attempting to make an adaption which will enable iSCSI to operate with RDMA, however, without CRC32c covering the headers and data being a "required to implement" this would not be possible.

The point that Caitlin and others are making is (in my opinion) that there are a number of applications that feel a CRC32c digest is needed.  And we will have to make CRC32c at least a "required to implement (optional to use)", and that negotiating such an option is not worth the testing effort for the negation itself nor the testing that must occur at run time with each side having negotiated different options, etc..  Also they are stating that from their point of view, the requirement from customers such as my company, makes it a hard requirement.  And since we and our competitors require such capability, the RNIC vendor needs to supply it even if some folks, like yourself, believe it is only a need spun from an urban legend that is causing the perceived need.

So I think we should at least agree that it needs to be a MUST implement, and then focus on whether it needs to be optional to use.

I personally do not want make it  optional, and want to ensure that the whole packet is covered.

.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Somesh Gupta" <somesh_gupta@silverbacksystems.com>
Sent by: rddp-admin@ietf.org

05/06/2003 12:33 PM

       
        To:        "Barron, Dwight" <Dwight.Barron@hp.com>, "Mogul, Jeffrey (HPL Palo Alto)" <jeff.mogul@hp.com>, <rddp@ietf.org>
        cc:        
        Subject:        RE: [rddp] CRC mandatory?



The paper is an excellent arguement for not offloading
integrity checks. A study of types of errors encountered
is interesting. A single CRC generated at the egress point,
and checked at the ingress point, would not catch 99% of
the errors listed because the CRC would be added to corrupted
data or data be corrupted after CRC check was done.

> -----Original Message-----
> From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of
> Barron, Dwight
> Sent: Tuesday, May 06, 2003 12:12 PM
> To: Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org
> Subject: RE: [rddp] CRC mandatory?
>
>
> Jeff, I agree that collecting quantitative data can be useful,
> but also believe that when it is being used to settle qualitative
> arguments the thresholds of acceptability are best set before the
> numbers are in. In a previous posting Jim Williams had stated
> that something in the same order of magnitude as the TCP stack on
> a per byte basis was not acceptable. I have not seen any comments
> on what would be acceptable overhead/criteria in order to gain
> consensus support of a mandatory CRC, nor any guidance on the
> parameters or type of environment to measure (but I agree that
> Sparc numbers circa 1995 aren't a good candidate). While I am not
> volunteering to collect the data yet, this is a hint that I could
> be coerced into doing so if it would lead to a more rapid consensus.
>
> However, determining an acceptable overhead is only one side of
> the equation, determining the acceptable level of reliability is
> the other. I continue to find the quantitative conclusions in the
> paper "When the CRC and TCP checksum disagree"
> http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf
> much more convincing than the qualitative arguments of "I use XYZ
> file servers all the time and they work just fine."
>
> Finally, when making an overhead vs. reliability architectural
> decision, one should realize that while Moore's Law is clearly on
> the side of lowering overhead over time, the reliability method
> is fixed for a very long time, in the face of constant or ever
> increasing errors per unit of time. If I have to bet incorrectly
> on an architectural decision, I like having time on my side.
>
> Regards,
> Dwight
>
>
> > -----Original Message-----
> > From: Mogul, Jeffrey (HPL Palo Alto)
> > Sent: Tuesday, May 06, 2003 12:58 PM
> > To: rddp@ietf.org
> > Subject: Re: [rddp] CRC mandatory?
> >
> >
> > It seems to me that one (but NOT the only) consideration in this
> > discussion is whether CRC calculation is really a burden for a
> > software implementation.  I've seen qualitative assertions
> > (some vaguer than others) on both sides, but nothing quantitative.
> >
> > RFC 3309 ("Stream Control Transmission Protocol (SCTP)
> > Checksum Change")
> > has an appendix about CRC implementations, and briefly discusses
> > the issue.  It cites
> >
> >                  David C. Feldmeier
> >                  Fast software implementation of error detection codes
> >                  IEEE Transactions on Networking, vol 3 no 6, pp 640-651,
> >                                   December, 1995.
> >
> > Unfortunately, measurements made in 1995 on a SPARCstation LX
> > (27 SPECint932) probably won't mean much in 2003.
> >
> > I spent a little time with CiteSeer and Google trying to find
> > a more recent study of CRC performance, but I couldn't find
> > anything.
> >
> > Perhaps someone with a good understanding of software CRC
> > implementation could do some measurements on modern hardware
> > that would give a solid quantitative basis for our debate?
> > For example, one could hack the Linux or *BSD stack to
> > do a CRC computation on each TCP segment (sent or received),
> > then throw away the results.  Measuring the performance change
> > on bulk throughput (say, using netperf) seems like a reasonable
> > approximation of software CRC costs.
> >
> > -Jeff
> >
> > P.S.: Don't look at me!  I don't have any spare time this month,
> > nor do I have a "good understanding of software CRC implementation".
> > _______________________________________________
> > rddp mailing list
> > rddp@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rddp
> >
> _______________________________________________
> rddp mailing list
> rddp@ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

--=_alternative 0001202088256D1F_=-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 20:48:59 2003 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 UAA15833 for ; Tue, 6 May 2003 20:48:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h470vhD13751 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 20:57:43 -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 h470vh813748 for ; Tue, 6 May 2003 20:57:43 -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 UAA15828 for ; Tue, 6 May 2003 20:48:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DD8k-0003vf-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 20:50:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DD8k-0003vc-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 20:50:34 -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 h470v2813722; Tue, 6 May 2003 20:57:02 -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 h470uR813665 for ; Tue, 6 May 2003 20:56:27 -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 UAA15754 for ; Tue, 6 May 2003 20:47:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DD7W-0003v6-00 for rddp@ietf.org; Tue, 06 May 2003 20:49:18 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19DD7W-0003un-00 for rddp@ietf.org; Tue, 06 May 2003 20:49:18 -0400 Received: from jurassic.eng.sun.com ([129.146.83.36]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA22825 for ; Tue, 6 May 2003 17:49:39 -0700 (PDT) Received: from sr1-umpk-03 (sr1-umpk-03.Eng.Sun.COM [129.146.14.20]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h470ncKQ691182 for ; Tue, 6 May 2003 17:49:39 -0700 (PDT) Message-Id: <200305070049.h470ncKQ691182@jurassic.eng.sun.com> Date: Tue, 6 May 2003 17:49:38 -0700 (PDT) From: Carl Hensler Reply-To: Carl Hensler Subject: RE: [rddp] CRC mandatory? To: rddp@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2d9UJ3bEFu4/GROm9gkdcw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.8 SunOS 5.8 sun4u sparc 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , I strongly support Caitlin's position. Carl Hensler Distinguished Engineer Sun Microsystems > Date: Tue, 6 May 2003 11:42:48 -0500 > From: Caitlin Bestler > Subject: RE: [rddp] CRC mandatory? > To: rddp@ietf.org > > I believe there are some fundamental issues regarding making > CRC coverage optional. > > The first is exactly what is our starting point? > > My understanding is that we are defining RDMA over reliable > IP transports and that we should be cleanly layered. > > So, which interpretation to we make of "cleanly layered": > > a) We define uniform expectations of the transport layer, > and provide adaptation layers to fill the gap between > those expectations and the existing IP transports. > > b) We add adaptation layer features *only* as required > to make DDP work, leaving each transport mapping as > close to the original transport as possible. > > The "uniform transport layer requirements" basically match > SCTP. Basically because RDDP requires unordered delivery > while preserving the order of submission, this required > the addition of the DDP-SSN in a very thin adaptation layer. > It has been agreed that MPA adds framing and markers if the > receiver wants them. > > So the debate is whether MPA should provide a standard level > of protection (i.e. end-to-end CRC32C on the entire DDP > Segment), or whether we have to justify *each* addition > to TCP as being specifically required by RDDP. > > I am a firm advocate of the "uniform expectations" approach. > This is mostly because I believe that applications > developers believe even more firmly in uniform expectations, > and will achieve it by lowering their expectations to match > the lowest common denominator. > > There are two guides as to what constitutes a reasonable > expectation for reliable transport for RDMA protocols: SCTP > and InfiniBand. SCTP is relevant because it is the reliable > transport most recently defined by the IETF. InfiniBand is > relevant because many of the ULPs that RDMAP/RDDP plans on > supporting will also run over InfiniBand. > > Having the adaptation layer raise all transports to a > uniform layer that matches the needs of RDDP makes much > more sense to me than having all applications conform > to the worst transport over which RDDP will run. > > The LCD approach *will* waste effort, because ULP integrity > checks will be applied redundantly to SCTP's CRC32c. > > Further, even if we accept the need to justify each feature > within MPA on an RDDP-specific basis, there is definitely a > need for coverage of the DDP and RDMAP headers. > > I have not seen a single refutation to the following: > > -- There are applications where there is trust between > the ULP peers. That is, the Data Sink ULP feels no > need to protect itself from maliscious attacks by > its peer. There is sufficient containment of damage > from other clients and/or sufficient authentication > of the peer. > > Whether a given ULP should or should not work from > this model is irrelevant here. Clearly there are > are applications where this is true, and they should > be supported. > > -- There are applications that require a higher level > of protection than afforded by TCP's 16 bit checksum. > > -- There are applications where the server wishes to allow > the client to have multiple requests in-flight. > > There are even applications where all of the above apply. > A DAFS Client requires more than a TCP 16 bit checksum, > trusts the DAFS server and can have a sequence of read > requests pending at the same instant. > > Without adequate protection for the DDP header, the ULP > would be forced to have only a single STag open on the > connection at any given time. > > That would mean that a DAFS client running over MPA/TCP > would be less capable than one running over SCTP or IB. > All three objectives cited above could be met via either > IB or SCTP. > > I believe that clearly establishes an RDDP specific need > to cover at least the headers. The cost of covering the > entire DDP Segment is trivial compared to that. > > But making the length of the coverage variable is an option, > which means it adds cost. See earlier posts on markers. > > Just because we decided that one option was justified does > not make the comments on why options are expensive any less > valid or relevant. Options are an ongoing complexity that > must be continuously retested. They represent a perpetual > drain of QA resources. > > A properly designed receiver can evaluate multiple CRCs > and/or checksums in parallel during a single scan over > memory. The calculations required for a CRC32C are minor, > and no additional memory touches are required. > > Even if each addition to MPA must be justified, the > simplicity of covering the complete DDP Segment would > outweigh the benefits of allowing a handful of applications > to omit some trivial calculations over the payload-only > portions. > > If we accept the goal of providing uniform transport > expectations to the ULP across all forms of reliable > RDMA networks then matching both SCTP and IB with > CRC coverage of the entire payload is clearly the only > choice. > > > > > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 21:05:02 2003 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 VAA16106 for ; Tue, 6 May 2003 21:05:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h471Dlf15299 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 21:13:47 -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 h471Dl815296 for ; Tue, 6 May 2003 21:13:47 -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 VAA16091 for ; Tue, 6 May 2003 21:04:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DDOH-000414-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 21:06:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DDOH-000411-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 21:06:37 -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 h471D2815275; Tue, 6 May 2003 21:13:02 -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 h471CV815239 for ; Tue, 6 May 2003 21:12:31 -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 VAA16062 for ; Tue, 6 May 2003 21:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DDN3-00040b-00 for rddp@ietf.org; Tue, 06 May 2003 21:05:21 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 19DDN2-00040K-00 for rddp@ietf.org; Tue, 06 May 2003 21:05:21 -0400 Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.9/8.12.9/NTAP-1.4) with ESMTP id h4715eFB021105; Tue, 6 May 2003 18:05:40 -0700 (PDT) Received: from dford-xp.netapp.com ([10.58.48.207]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.4) with ESMTP id h4715blp029020; Tue, 6 May 2003 18:05:39 -0700 (PDT) Message-Id: <5.1.1.5.2.20030506210539.00b4a678@silver.nane.netapp.com> X-Sender: dford@silver.nane.netapp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 06 May 2003 21:07:05 -0400 To: From: David Ford Subject: RE: [rddp] CRC mandatory? Cc: "Carl Hensler" In-Reply-To: <200305070049.h470ncKQ691182@jurassic.eng.sun.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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , At 08:49 PM 5/6/2003, Carl Hensler wrote: >I strongly support Caitlin's position. What he said. David Ford Network Appliance >Carl Hensler >Distinguished Engineer >Sun Microsystems > > > > Date: Tue, 6 May 2003 11:42:48 -0500 > > From: Caitlin Bestler > > Subject: RE: [rddp] CRC mandatory? > > To: rddp@ietf.org > > > > I believe there are some fundamental issues regarding making > > CRC coverage optional. > > > > The first is exactly what is our starting point? > > > > My understanding is that we are defining RDMA over reliable > > IP transports and that we should be cleanly layered. > > > > So, which interpretation to we make of "cleanly layered": > > > > a) We define uniform expectations of the transport layer, > > and provide adaptation layers to fill the gap between > > those expectations and the existing IP transports. > > > > b) We add adaptation layer features *only* as required > > to make DDP work, leaving each transport mapping as > > close to the original transport as possible. > > > > The "uniform transport layer requirements" basically match > > SCTP. Basically because RDDP requires unordered delivery > > while preserving the order of submission, this required > > the addition of the DDP-SSN in a very thin adaptation layer. > > It has been agreed that MPA adds framing and markers if the > > receiver wants them. > > > > So the debate is whether MPA should provide a standard level > > of protection (i.e. end-to-end CRC32C on the entire DDP > > Segment), or whether we have to justify *each* addition > > to TCP as being specifically required by RDDP. > > > > I am a firm advocate of the "uniform expectations" approach. > > This is mostly because I believe that applications > > developers believe even more firmly in uniform expectations, > > and will achieve it by lowering their expectations to match > > the lowest common denominator. > > > > There are two guides as to what constitutes a reasonable > > expectation for reliable transport for RDMA protocols: SCTP > > and InfiniBand. SCTP is relevant because it is the reliable > > transport most recently defined by the IETF. InfiniBand is > > relevant because many of the ULPs that RDMAP/RDDP plans on > > supporting will also run over InfiniBand. > > > > Having the adaptation layer raise all transports to a > > uniform layer that matches the needs of RDDP makes much > > more sense to me than having all applications conform > > to the worst transport over which RDDP will run. > > > > The LCD approach *will* waste effort, because ULP integrity > > checks will be applied redundantly to SCTP's CRC32c. > > > > Further, even if we accept the need to justify each feature > > within MPA on an RDDP-specific basis, there is definitely a > > need for coverage of the DDP and RDMAP headers. > > > > I have not seen a single refutation to the following: > > > > -- There are applications where there is trust between > > the ULP peers. That is, the Data Sink ULP feels no > > need to protect itself from maliscious attacks by > > its peer. There is sufficient containment of damage > > from other clients and/or sufficient authentication > > of the peer. > > > > Whether a given ULP should or should not work from > > this model is irrelevant here. Clearly there are > > are applications where this is true, and they should > > be supported. > > > > -- There are applications that require a higher level > > of protection than afforded by TCP's 16 bit checksum. > > > > -- There are applications where the server wishes to allow > > the client to have multiple requests in-flight. > > > > There are even applications where all of the above apply. > > A DAFS Client requires more than a TCP 16 bit checksum, > > trusts the DAFS server and can have a sequence of read > > requests pending at the same instant. > > > > Without adequate protection for the DDP header, the ULP > > would be forced to have only a single STag open on the > > connection at any given time. > > > > That would mean that a DAFS client running over MPA/TCP > > would be less capable than one running over SCTP or IB. > > All three objectives cited above could be met via either > > IB or SCTP. > > > > I believe that clearly establishes an RDDP specific need > > to cover at least the headers. The cost of covering the > > entire DDP Segment is trivial compared to that. > > > > But making the length of the coverage variable is an option, > > which means it adds cost. See earlier posts on markers. > > > > Just because we decided that one option was justified does > > not make the comments on why options are expensive any less > > valid or relevant. Options are an ongoing complexity that > > must be continuously retested. They represent a perpetual > > drain of QA resources. > > > > A properly designed receiver can evaluate multiple CRCs > > and/or checksums in parallel during a single scan over > > memory. The calculations required for a CRC32C are minor, > > and no additional memory touches are required. > > > > Even if each addition to MPA must be justified, the > > simplicity of covering the complete DDP Segment would > > outweigh the benefits of allowing a handful of applications > > to omit some trivial calculations over the payload-only > > portions. > > > > If we accept the goal of providing uniform transport > > expectations to the ULP across all forms of reliable > > RDMA networks then matching both SCTP and IB with > > CRC coverage of the entire payload is clearly the only > > choice. > > > > > > > > > > > > > > Caitlin Bestler > > http://asomi.com/CaitlinBestler/ > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Tue May 6 21:32:00 2003 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 VAA16753 for ; Tue, 6 May 2003 21:32:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h471ejb17479 for rddp-archive@odin.ietf.org; Tue, 6 May 2003 21:40:45 -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 h471ej817476 for ; Tue, 6 May 2003 21:40:45 -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 VAA16734 for ; Tue, 6 May 2003 21:31:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DDoN-0004EZ-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 21:33:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DDoN-0004EW-00 for rddp-web-archive@ietf.org; Tue, 06 May 2003 21:33:35 -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 h471e6817460; Tue, 6 May 2003 21:40:06 -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 h471e0817411 for ; Tue, 6 May 2003 21:40:00 -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 VAA16716 for ; Tue, 6 May 2003 21:30:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DDne-0004EC-00 for rddp@ietf.org; Tue, 06 May 2003 21:32:50 -0400 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 19DDnd-0004E9-00 for rddp@ietf.org; Tue, 06 May 2003 21:32:49 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id ECB89244910 for ; Tue, 6 May 2003 21:34:00 -0400 (EDT) Date: Tue, 6 May 2003 20:33:47 -0500 From: Caitlin Bestler To: rddp@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Subject: [rddp] CRC32C Calculation "Burden" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit RFC 3385 section 8.2 gives a parallel implementation of CRC-32c. It takes as input the next 32 bits of data and the current 32 bit CRC. The result is a new 32 bit CRC. The algorithm presented is based on the fact that each bit of the resulting CRC is an XOR of a subset of the input bits (the original CRC and new data). If you examine the formulas, though, you will realize that the reverse is also true. Each input bit effects a subset of the result. Further the contribution of any set of input bits is an xor of the contribution of each of those bits. More precisely: contributionOf [x^y] = contributionOf[x] ^ contributionOf[y]. These could be rolled into a large table, resulting in a very short calculation: newCRC = contributionOfCRC[oldCRC] ^ contributionOfData[newData]. Of course that's 2 tables with 2**32 entries. Probably a bit too large. Working 16 bits at a time: newCRC.high = contributionOfCRChigh[oldCRC.high] ^ contributionOfCRClow[oldCRC.low] ^ contributionOfDataHigh[newData.high] ^ contributionOfDataLow[newData.low]; That produces one indexed lookup and one XOR operation per byte. Any size can be pre-factored. The Linux code for SCTP uses 256 entry tables. Smaller tables result in more operations, but increase the ability to keep the lookup table cached. If you go down to calculating the effect bit-by-bit the "tables" become in-line constants. This minimizes random access to code space for constant tables, but increases the number of calculations. Of course many processors can perform numerous calculations for each non-cached memory fetch, so the tradeoff is complex. The optimum balance is dependent on the memory architecture. In particular, whether fetches from constant tables in code-space can execute in parallel with fetches of the new data byte. The CRC itself would remain in a register or at least cached. But whatever combination is selected, there are at most a few simple operations per 32 bits, and no additional memory touches to uncached data space are required. Given those two factors, I cannot see how a CRC32C calculation can possibly be considered an unreasonable burden for software implementations. Note, the referenced Linux implementation can be found at: http://www.linuxhq.com/kernel/v2.5/33/net/sctp/crc32c.c Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 08:50:08 2003 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 IAA28441 for ; Wed, 7 May 2003 08:50:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Cx7s12849 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 08:59:07 -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 h47Cx7812846 for ; Wed, 7 May 2003 08:59:07 -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 IAA28416 for ; Wed, 7 May 2003 08:49:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DOOc-0000rq-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 08:51:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DOOc-0000rn-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 08:51:42 -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 h47CwP812812; Wed, 7 May 2003 08:58:25 -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 h47Cub812741 for ; Wed, 7 May 2003 08:56: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 IAA28366 for ; Wed, 7 May 2003 08:47:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DOMC-0000qd-00 for rddp@ietf.org; Wed, 07 May 2003 08:49:12 -0400 Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx with esmtp (Exim 4.12) id 19DOMB-0000qO-00 for rddp@ietf.org; Wed, 07 May 2003 08:49:11 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id DC74BBE0F for ; Wed, 7 May 2003 07:49:33 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 07:49:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rddp] CRC mandatory? Date: Wed, 7 May 2003 07:49:33 -0500 Message-ID: <07DEBFB3DCB18A49B06B6371993586740292FF60@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] CRC mandatory? Thread-Index: AcMT74XPRgGscOCPRlG5FmLi8hgW1wApsfew From: "Hilland, Jeff" To: X-OriginalArrivalTime: 07 May 2003 12:49:33.0616 (UTC) FILETIME=[1BD66B00:01C31497] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47Cub812742 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I strongly agree with Caitlin as well. Uniform transport layer requirements. Her point about at least requiring CRC32 for the headers is something I thought this group was headed toward by earlier emails. The consequences of landing data in an unintended location are severe, so we should take all reasonable steps to ensure that this doesn't happen. CRC32 of the header is one of these reasonable steps. If we are expecting an application to cover the data with it's own CRC, then this would mean the application would have to add another "touch" to the data, so we would just be pushing the memory bandwidth issue up one level. I would prefer a uniform transport layer requirement to prevent upper layer protocols from being required to touch the data again. Regards, Jeff -----Original Message----- From: Caitlin Bestler [mailto:cait@asomi.com] Sent: Tuesday, May 06, 2003 11:43 AM To: rddp@ietf.org Subject: RE: [rddp] CRC mandatory? I believe there are some fundamental issues regarding making CRC coverage optional. The first is exactly what is our starting point? My understanding is that we are defining RDMA over reliable IP transports and that we should be cleanly layered. So, which interpretation to we make of "cleanly layered": a) We define uniform expectations of the transport layer, and provide adaptation layers to fill the gap between those expectations and the existing IP transports. b) We add adaptation layer features *only* as required to make DDP work, leaving each transport mapping as close to the original transport as possible. The "uniform transport layer requirements" basically match SCTP. Basically because RDDP requires unordered delivery while preserving the order of submission, this required the addition of the DDP-SSN in a very thin adaptation layer. It has been agreed that MPA adds framing and markers if the receiver wants them. So the debate is whether MPA should provide a standard level of protection (i.e. end-to-end CRC32C on the entire DDP Segment), or whether we have to justify *each* addition to TCP as being specifically required by RDDP. I am a firm advocate of the "uniform expectations" approach. This is mostly because I believe that applications developers believe even more firmly in uniform expectations, and will achieve it by lowering their expectations to match the lowest common denominator. There are two guides as to what constitutes a reasonable expectation for reliable transport for RDMA protocols: SCTP and InfiniBand. SCTP is relevant because it is the reliable transport most recently defined by the IETF. InfiniBand is relevant because many of the ULPs that RDMAP/RDDP plans on supporting will also run over InfiniBand. Having the adaptation layer raise all transports to a uniform layer that matches the needs of RDDP makes much more sense to me than having all applications conform to the worst transport over which RDDP will run. The LCD approach *will* waste effort, because ULP integrity checks will be applied redundantly to SCTP's CRC32c. Further, even if we accept the need to justify each feature within MPA on an RDDP-specific basis, there is definitely a need for coverage of the DDP and RDMAP headers. I have not seen a single refutation to the following: -- There are applications where there is trust between the ULP peers. That is, the Data Sink ULP feels no need to protect itself from maliscious attacks by its peer. There is sufficient containment of damage from other clients and/or sufficient authentication of the peer. Whether a given ULP should or should not work from this model is irrelevant here. Clearly there are are applications where this is true, and they should be supported. -- There are applications that require a higher level of protection than afforded by TCP's 16 bit checksum. -- There are applications where the server wishes to allow the client to have multiple requests in-flight. There are even applications where all of the above apply. A DAFS Client requires more than a TCP 16 bit checksum, trusts the DAFS server and can have a sequence of read requests pending at the same instant. Without adequate protection for the DDP header, the ULP would be forced to have only a single STag open on the connection at any given time. That would mean that a DAFS client running over MPA/TCP would be less capable than one running over SCTP or IB. All three objectives cited above could be met via either IB or SCTP. I believe that clearly establishes an RDDP specific need to cover at least the headers. The cost of covering the entire DDP Segment is trivial compared to that. But making the length of the coverage variable is an option, which means it adds cost. See earlier posts on markers. Just because we decided that one option was justified does not make the comments on why options are expensive any less valid or relevant. Options are an ongoing complexity that must be continuously retested. They represent a perpetual drain of QA resources. A properly designed receiver can evaluate multiple CRCs and/or checksums in parallel during a single scan over memory. The calculations required for a CRC32C are minor, and no additional memory touches are required. Even if each addition to MPA must be justified, the simplicity of covering the complete DDP Segment would outweigh the benefits of allowing a handful of applications to omit some trivial calculations over the payload-only portions. If we accept the goal of providing uniform transport expectations to the ULP across all forms of reliable RDMA networks then matching both SCTP and IB with CRC coverage of the entire payload is clearly the only choice. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 09:29:09 2003 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 JAA29988 for ; Wed, 7 May 2003 09:29:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Dc8n16978 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 09:38:08 -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 h47Dc8816975 for ; Wed, 7 May 2003 09:38:08 -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 JAA29954 for ; Wed, 7 May 2003 09:28:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DP0N-0001Cl-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 09:30:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DP0N-0001Ci-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 09:30:43 -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 h47DbM816495; Wed, 7 May 2003 09:37:22 -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 h47DZ3815968 for ; Wed, 7 May 2003 09:35:03 -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 JAA29701 for ; Wed, 7 May 2003 09:25:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DOxO-0001BN-00 for rddp@ietf.org; Wed, 07 May 2003 09:27:38 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19DOxN-0001BK-00 for rddp@ietf.org; Wed, 07 May 2003 09:27:37 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 7FC1DAFE6 for ; Wed, 7 May 2003 08:28:00 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 08:28:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] CRC mandatory? Date: Wed, 7 May 2003 08:27:59 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F87240314316F@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] CRC mandatory? Thread-Index: AcMT74XPRgGscOCPRlG5FmLi8hgW1wApsfewAAEaXRA= From: "Barron, Dwight" To: "Hilland, Jeff" , X-OriginalArrivalTime: 07 May 2003 13:28:00.0342 (UTC) FILETIME=[7AC0DF60:01C3149C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47DZ3815969 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I agree with Caitlin also, uniform transport requirements with roughly uniform overhead for equivalent implementations. I also agree with Jeff, if we don't solve it consistently at the RDDP layer it will pop back up to the app layer, where we lose the memory bandwidth savings of RDDP and a really good chance to move the CRC overhead into hardware once and for all. John, hopefully everyone is on the tack of mandatory to implement, whatever the outcome of the optional debate. Regards, Dwight > -----Original Message----- > From: Hilland, Jeff > Sent: Wednesday, May 07, 2003 7:50 AM > To: rddp@ietf.org > Subject: RE: [rddp] CRC mandatory? > > > I strongly agree with Caitlin as well. Uniform transport layer > requirements. > > Her point about at least requiring CRC32 for the headers is > something I > thought this group was headed toward by earlier emails. The > consequences of landing data in an unintended location are > severe, so we > should take all reasonable steps to ensure that this doesn't happen. > CRC32 of the header is one of these reasonable steps. > > If we are expecting an application to cover the data with > it's own CRC, > then this would mean the application would have to add another "touch" > to the data, so we would just be pushing the memory bandwidth issue up > one level. I would prefer a uniform transport layer requirement to > prevent upper layer protocols from being required to touch the data > again. > > Regards, > Jeff > > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Tuesday, May 06, 2003 11:43 AM > To: rddp@ietf.org > Subject: RE: [rddp] CRC mandatory? > > > I believe there are some fundamental issues regarding making CRC > coverage optional. > > The first is exactly what is our starting point? > > My understanding is that we are defining RDMA over reliable > IP transports and that we should be cleanly layered. > > So, which interpretation to we make of "cleanly layered": > > a) We define uniform expectations of the transport layer, > and provide adaptation layers to fill the gap between > those expectations and the existing IP transports. > > b) We add adaptation layer features *only* as required > to make DDP work, leaving each transport mapping as > close to the original transport as possible. > > The "uniform transport layer requirements" basically match SCTP. > Basically because RDDP requires unordered delivery while > preserving the > order of submission, this required the addition of the > DDP-SSN in a very > thin adaptation layer. It has been agreed that MPA adds framing and > markers if the receiver wants them. > > So the debate is whether MPA should provide a standard level > of protection (i.e. end-to-end CRC32C on the entire DDP Segment), or > whether we have to justify *each* addition to TCP as being > specifically > required by RDDP. > > I am a firm advocate of the "uniform expectations" approach. This is > mostly because I believe that applications developers believe > even more > firmly in uniform expectations, and will achieve it by lowering their > expectations to match the lowest common denominator. > > There are two guides as to what constitutes a reasonable > expectation for > reliable transport for RDMA protocols: SCTP and InfiniBand. SCTP is > relevant because it is the reliable transport most recently defined by > the IETF. InfiniBand is relevant because many of the ULPs that > RDMAP/RDDP plans on supporting will also run over InfiniBand. > > Having the adaptation layer raise all transports to a > uniform layer that matches the needs of RDDP makes much > more sense to me than having all applications conform > to the worst transport over which RDDP will run. > > The LCD approach *will* waste effort, because ULP integrity > checks will > be applied redundantly to SCTP's CRC32c. > > Further, even if we accept the need to justify each feature within MPA > on an RDDP-specific basis, there is definitely a need for coverage of > the DDP and RDMAP headers. > > I have not seen a single refutation to the following: > > -- There are applications where there is trust between > the ULP peers. That is, the Data Sink ULP feels no > need to protect itself from maliscious attacks by > its peer. There is sufficient containment of damage > from other clients and/or sufficient authentication > of the peer. > > Whether a given ULP should or should not work from > this model is irrelevant here. Clearly there are > are applications where this is true, and they should > be supported. > > -- There are applications that require a higher level > of protection than afforded by TCP's 16 bit checksum. > > -- There are applications where the server wishes to allow > the client to have multiple requests in-flight. > > There are even applications where all of the above apply. > A DAFS Client requires more than a TCP 16 bit checksum, > trusts the DAFS server and can have a sequence of read > requests pending at the same instant. > > Without adequate protection for the DDP header, the ULP > would be forced to have only a single STag open on the > connection at any > given time. > > That would mean that a DAFS client running over MPA/TCP > would be less capable than one running over SCTP or IB. > All three objectives cited above could be met via either > IB or SCTP. > > I believe that clearly establishes an RDDP specific need > to cover at least the headers. The cost of covering the > entire DDP Segment is trivial compared to that. > > But making the length of the coverage variable is an option, > which means > it adds cost. See earlier posts on markers. > > Just because we decided that one option was justified does > not make the comments on why options are expensive any less valid or > relevant. Options are an ongoing complexity that must be continuously > retested. They represent a perpetual drain of QA resources. > > A properly designed receiver can evaluate multiple CRCs > and/or checksums in parallel during a single scan over > memory. The calculations required for a CRC32C are minor, > and no additional memory touches are required. > > Even if each addition to MPA must be justified, the > simplicity of covering the complete DDP Segment would > outweigh the benefits of allowing a handful of applications > to omit some trivial calculations over the payload-only portions. > > If we accept the goal of providing uniform transport > expectations to the > ULP across all forms of reliable RDMA networks then matching both SCTP > and IB with CRC coverage of the entire payload is clearly the only > choice. > > > > > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 10:48:02 2003 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 KAA04605 for ; Wed, 7 May 2003 10:48:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Ev4B23160 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 10:57:04 -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 h47Ev3823157 for ; Wed, 7 May 2003 10:57:03 -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 KAA04575 for ; Wed, 7 May 2003 10:47:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQEi-00023o-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 10:49:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DQEi-00023i-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 10:49:36 -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 h47EuC823118; Wed, 7 May 2003 10:56:12 -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 h47EtQ823057 for ; Wed, 7 May 2003 10:55:26 -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 KAA04483 for ; Wed, 7 May 2003 10:45:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQD9-00023B-00 for rddp@ietf.org; Wed, 07 May 2003 10:47:59 -0400 Received: from sandmail.sandburst.com ([216.57.132.42]) by ietf-mx with esmtp (Exim 4.12) id 19DQD9-00022h-00 for rddp@ietf.org; Wed, 07 May 2003 10:47:59 -0400 To: rddp@ietf.org Subject: Re: [rddp] CRC mandatory? In-Reply-To: Message from David Ford of "Tue, 06 May 2003 21:07:05 EDT." <5.1.1.5.2.20030506210539.00b4a678@silver.nane.netapp.com> References: <5.1.1.5.2.20030506210539.00b4a678@silver.nane.netapp.com> Date: Wed, 07 May 2003 10:48:19 -0400 From: Stephen Bailey Message-Id: <20030507144821.121DC4ED1@sandmail.sandburst.com> 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , > > > So, which interpretation to we make of "cleanly layered": > > > > > > a) We define uniform expectations of the transport layer, > > > and provide adaptation layers to fill the gap between > > > those expectations and the existing IP transports. > > > > > > b) We add adaptation layer features *only* as required > > > to make DDP work, leaving each transport mapping as > > > close to the original transport as possible. You've outlined two extremes. There's an intermediate position. If applications (rather than RDDP), SPECIFICALLY want a capability, the adaptation layer can provide it. CRC protection is an example. I'm personally opposed to the `uniform expectations' model for its own sake. This is much more broad than to CRC or not to CRC. RDDP solves an orthogonal problem to over-the-wire data delivery, and should not be constrained to a single set of transport characteristics. It may well be the case (is the case, apparently) that a) we don't understand how to build an RDDP that operates orthogonally from the transport b) we don't see a clear and present NEED for RDDP on transports other than connected, sequenced and reliable. I actually think a) may not be as hard as people think (I believe the RDDP architecture in the arch ID IS transport agnostic), but b) makes it relatively unlikely that anybody other than a hobbyist (i.e. me) would be interested. Along these lines, I'm somewhat disappointed that (if I understand correctly) the SCTP mapping seems to build sequencing on top of unsequenced SCTP. Seems more natural to allow the application to chose one or the other transport mode. Perhaps my concern with `nailing down every loose detail' in the protocol architecture comes from my history with processor design. You really want to have the architecture specify enough behavior to be useful, and leave as much as possible to implementation or application choice. Ok, so I worked at DEC. Alpha got the coherency model right (but failed for other reasons). Alpha never really took this position, but clearly, if you want a strong coherency model, e.g. for an embedded application, you can buy an implementation which provides superset (stronger coherency) capabilities. Your code won't be 100% portable, but that's the choice you make. I think you've gone too far if you say CRC protection is a specific instance of a general principle we should apply. CRC protection is CRC protection. The general principle is to leave as much flexibility to the implementations while still providing a useful service. Saying that RDDP MUST run on a sequenced, reliable, CRC protected transport seems ridiculous. Steph _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 10:49:57 2003 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 KAA04663 for ; Wed, 7 May 2003 10:49:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47EwwV23286 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 10:58:58 -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 h47Eww823283 for ; Wed, 7 May 2003 10:58:58 -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 KAA04646 for ; Wed, 7 May 2003 10:49:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQGZ-00024P-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 10:51:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DQGZ-00024M-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 10:51:31 -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 h47Ew2823223; Wed, 7 May 2003 10:58:02 -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 h47EvW823179 for ; Wed, 7 May 2003 10:57:32 -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 KAA04603 for ; Wed, 7 May 2003 10:48:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQFB-000243-00 for rddp@ietf.org; Wed, 07 May 2003 10:50:05 -0400 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQFA-00023d-00 for rddp@ietf.org; Wed, 07 May 2003 10:50:04 -0400 Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.12.9/8.12.8) with ESMTP id h47EoQLW028458 for ; Wed, 7 May 2003 07:50:26 -0700 (PDT) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 10:50:25 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF289B9077@xbl.ma.emulex.com> From: "Williams, Jim" To: rddp@ietf.org Subject: RE: [rddp] CRC mandatory? Date: Wed, 7 May 2003 10:50:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Jeff Hilland wrote: > The consequences of landing data in an unintended > location are severe, so we should take all reasonable > steps to ensure that this doesn't happen. > CRC32 of the header is one of these reasonable steps. I agree that the consequences are severe. However in most cases the consequences of putting bad data in the correct location are equally severe. (There are counter examples, but they are the exception rather than the rule.) Given an unreliable transport, undetected payload corruption is far more likely than undetected header corruption. This is both because there are a lot more bits of payload than header, and because a large percentage of header corruption will be caught by means other than a CRC, for instance illegal format, buffer ID, or offset. Payload corruption will often be totally unchecked at the ULP level. So I am led to a couple opinions. 1. I do not see sufficient justification for a mode including a header CRC but not a payload CRC. This does represent a change of opinion on my part from some previous statements. 2. The only justification for opting not to use RDDP layer CRCs is confidence that the underlying transport, TCP, will deliver correct data. I am reluctant to go down the path of saying bad headers or payloads are "acceptable" under any circumstances. Caitlin Bestler wrote: > I am a firm advocate of the "uniform expectations" approach. > This is mostly because I believe that applications > developers believe even more firmly in uniform expectations, > and will achieve it by lowering their expectations to match > the lowest common denominator. I certainly support the idea of uniform expectations. I would just like to avoid confusing expectations with mechanisms. The expectation is reliable correct data delivery by the transport. The mechanism is some number of bits of checksum and/or CRC. I prefer to frame the debate as to whether or not TCP achieves the expectation of reliable and correct data delivery. Clearly different transports use different mechanisms to achieve each of their expectations. I don't believe equivalence of mechanisms is or should be an objective. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 11:13:54 2003 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 LAA05316 for ; Wed, 7 May 2003 11:13:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47FMsw25506 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 11:22:54 -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 h47FMs825503 for ; Wed, 7 May 2003 11:22:54 -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 LAA05306 for ; Wed, 7 May 2003 11:13:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQdj-0002Ek-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 11:15:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DQdi-0002Eh-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 11:15:26 -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 h47FM3825467; Wed, 7 May 2003 11:22:03 -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 h47FLh825425 for ; Wed, 7 May 2003 11:21:43 -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 LAA05275 for ; Wed, 7 May 2003 11:12:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQca-0002EQ-00 for rddp@ietf.org; Wed, 07 May 2003 11:14:16 -0400 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 19DQca-0002E4-00 for rddp@ietf.org; Wed, 07 May 2003 11:14:16 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 0FBC0245344; Wed, 7 May 2003 11:14:58 -0400 (EDT) Date: Wed, 7 May 2003 10:14:46 -0500 From: Caitlin Bestler To: Stephen Bailey Cc: rddp@ietf.org X-Priority: 3 In-Reply-To: <20030507144821.121DC4ED1@sandmail.sandburst.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Subject: [rddp] Re: Unreliable Transports (was re CRC mandatory? ) 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/7/03, Stephen Bailey wrote: >I think you've gone too far if you say CRC protection is a >specific instance of a general principle we should apply. >CRC protection is CRC protection. The general principle >is to leave as much flexibility to the implementations >while still providing a useful service. Saying that RDDP >MUST run on a sequenced, reliable, CRC protected transport >seems ridiculous. Agreed. To be more precise, RDDP should have uniform expectations for sequenced/reliable transports. It has been my assumption all along that RDDP maps very well to unreliable transports, but that the use of an unreliable transport is something that the ULP would request to meet specific requirements. The specific issue that will have to be dealt with when we are ready to address unreliable transports is how the set of DDP Segments that form an atomic made it / lost it decision are identified. When we discussed this briefly on the old yahoo groups you seemed to favor having the receiving ULP make such determinations, I favored explicitly labeling the RDMA Writes and Send that formed a cohesive accept it/drop it unit. But I think we both agree that unreliable RDDP is a specialized application that can be dealt with after the reliable version has been fully dealt with. [And even if we don't, David would probably agree for us more vehemently, ;-) ]. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 12:51:11 2003 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 MAA08025 for ; Wed, 7 May 2003 12:51:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47H0Dq01583 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 13:00:13 -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 h47H0D801580 for ; Wed, 7 May 2003 13:00:13 -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 MAA08003 for ; Wed, 7 May 2003 12:50:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DS9s-0002s7-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 12:52:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DS9r-0002s4-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 12:52:43 -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 h47GxD801479; Wed, 7 May 2003 12:59:13 -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 h47GwZ801439 for ; Wed, 7 May 2003 12:58:35 -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 MAA07966; Wed, 7 May 2003 12:49:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DS8H-0002rb-00; Wed, 07 May 2003 12:51:05 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19DS8G-0002rS-00; Wed, 07 May 2003 12:51:04 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 2E7A2D4CA; Wed, 7 May 2003 09:51:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 555792110E; Wed, 7 May 2003 09:51:13 -0700 (PDT) Cc: "Barron, Dwight" , "Mogul, Jeffrey (HPL Palo Alto)" , , Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C3147E.25B1F400" Date: Wed, 7 May 2003 09:50:52 -0700 From: "Somesh Gupta" Importance: Normal In-reply-to: Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 15119-17913B11; Wed, 07 May 2003 09:50:40 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id 10F0A20ECF; Wed, 7 May 2003 09:50:40 -0700 (PDT) Subject: RE: [rddp] CRC mandatory? To: "John Hufferd" X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C3147E.25B1F400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John, As far as Silverback products are concerned, header as well as data CRC is supported at our high performance levels. (And as a IHV, it is great if everyone will use CRC all the time because it increases the CPU overhead and the need for NICs). I wish we can focus on the technical debate and leave any insinuations about specific company products etc out of this. However, there are a number of products out there that do not support CRC. You may not consider them competitors, but that is not an argument I can get into. IPSec is also mandatory to implement and optional to use. A reasonable section of the community also feels that for iSCSI to have widespread deployment, IPSec is a more important technology than some of the other features. And if IPSec gets deployed, an additional CRC becomes meaningless. IPSec is also something that the RDMA community will have to deal with. Customers are likely to be very concerned about any security holes being exposed as a result of out of order placement without authentication of the sender. My position has been of having an optional CRC - not of not having a CRC. Somesh -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, May 06, 2003 5:12 PM To: Somesh Gupta Cc: Barron, Dwight; Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org; rddp-admin@ietf.org Subject: RE: [rddp] CRC mandatory? Somesh, You and I have had this discussion many times. And I have said that when you combine the results of that paper with the increase in speed that is now here and coming in the future, that it make a strong statement that CRC32c type checks are needed. As you know we made CRC32c a "MUST implement,, optional to use" in iSCSI. I have found no one within my company that would ever suggest to our customers that they should operate with CRC32c turned off. I have not heard that from our competitors either. In other words, we made a big deal of making it optional in iSCSI, but the folks that focus exclusively on storage, have, as far as I can determine made these checks the defacto way things operate. As you also know some folks are attempting to make an adaption which will enable iSCSI to operate with RDMA, however, without CRC32c covering the headers and data being a "required to implement" this would not be possible. The point that Caitlin and others are making is (in my opinion) that there are a number of applications that feel a CRC32c digest is needed. And we will have to make CRC32c at least a "required to implement (optional to use)", and that negotiating such an option is not worth the testing effort for the negation itself nor the testing that must occur at run time with each side having negotiated different options, etc.. Also they are stating that from their point of view, the requirement from customers such as my company, makes it a hard requirement. And since we and our competitors require such capability, the RNIC vendor needs to supply it even if some folks, like yourself, believe it is only a need spun from an urban legend that is causing the perceived need. So I think we should at least agree that it needs to be a MUST implement, and then focus on whether it needs to be optional to use. I personally do not want make it optional, and want to ensure that the whole packet is covered. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Somesh Gupta" Sent by: rddp-admin@ietf.org 05/06/2003 12:33 PM To: "Barron, Dwight" , "Mogul, Jeffrey (HPL Palo Alto)" , cc: Subject: RE: [rddp] CRC mandatory? The paper is an excellent arguement for not offloading integrity checks. A study of types of errors encountered is interesting. A single CRC generated at the egress point, and checked at the ingress point, would not catch 99% of the errors listed because the CRC would be added to corrupted data or data be corrupted after CRC check was done. > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > Barron, Dwight > Sent: Tuesday, May 06, 2003 12:12 PM > To: Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org > Subject: RE: [rddp] CRC mandatory? > > > Jeff, I agree that collecting quantitative data can be useful, > but also believe that when it is being used to settle qualitative > arguments the thresholds of acceptability are best set before the > numbers are in. In a previous posting Jim Williams had stated > that something in the same order of magnitude as the TCP stack on > a per byte basis was not acceptable. I have not seen any comments > on what would be acceptable overhead/criteria in order to gain > consensus support of a mandatory CRC, nor any guidance on the > parameters or type of environment to measure (but I agree that > Sparc numbers circa 1995 aren't a good candidate). While I am not > volunteering to collect the data yet, this is a hint that I could > be coerced into doing so if it would lead to a more rapid consensus. > > However, determining an acceptable overhead is only one side of > the equation, determining the acceptable level of reliability is > the other. I continue to find the quantitative conclusions in the > paper "When the CRC and TCP checksum disagree" > http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf > much more convincing than the qualitative arguments of "I use XYZ > file servers all the time and they work just fine." > > Finally, when making an overhead vs. reliability architectural > decision, one should realize that while Moore's Law is clearly on > the side of lowering overhead over time, the reliability method > is fixed for a very long time, in the face of constant or ever > increasing errors per unit of time. If I have to bet incorrectly > on an architectural decision, I like having time on my side. > > Regards, > Dwight > > > > -----Original Message----- > > From: Mogul, Jeffrey (HPL Palo Alto) > > Sent: Tuesday, May 06, 2003 12:58 PM > > To: rddp@ietf.org > > Subject: Re: [rddp] CRC mandatory? > > > > > > It seems to me that one (but NOT the only) consideration in this > > discussion is whether CRC calculation is really a burden for a > > software implementation. I've seen qualitative assertions > > (some vaguer than others) on both sides, but nothing quantitative. > > > > RFC 3309 ("Stream Control Transmission Protocol (SCTP) > > Checksum Change") > > has an appendix about CRC implementations, and briefly discusses > > the issue. It cites > > > > David C. Feldmeier > > Fast software implementation of error detection codes > > IEEE Transactions on Networking, vol 3 no 6, pp 640-651, > > December, 1995. > > > > Unfortunately, measurements made in 1995 on a SPARCstation LX > > (27 SPECint932) probably won't mean much in 2003. > > > > I spent a little time with CiteSeer and Google trying to find > > a more recent study of CRC performance, but I couldn't find > > anything. > > > > Perhaps someone with a good understanding of software CRC > > implementation could do some measurements on modern hardware > > that would give a solid quantitative basis for our debate? > > For example, one could hack the Linux or *BSD stack to > > do a CRC computation on each TCP segment (sent or received), > > then throw away the results. Measuring the performance change > > on bulk throughput (say, using netperf) seems like a reasonable > > approximation of software CRC costs. > > > > -Jeff > > > > P.S.: Don't look at me! I don't have any spare time this month, > > nor do I have a "good understanding of software CRC implementation". > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp ------=_NextPart_000_000F_01C3147E.25B1F400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
John,
 
As far=20 as Silverback products are concerned, header as well as data CRC=20 is
supported at our high performance levels. = (And as a=20 IHV, it is great if everyone
will=20 use CRC all the time because it increases the CPU overhead and the=20 need
for=20 NICs). I wish we can focus on the technical debate and leave any=20 insinuations
about=20 specific company products etc out of this.
 
However, there are a number of products out = there that=20 do not support CRC.
You=20 may not consider them competitors, but that is not an argument I=20 can
get=20 into.
 
IPSec=20 is also mandatory to implement and optional to use. A reasonable=20 section
of the=20 community also feels that for iSCSI to have widespread deployment,=20 IPSec
is a=20 more important technology than some of the other features. And if=20 IPSec
gets=20 deployed, an additional CRC becomes meaningless.
 
IPSec is also something that the RDMA = community=20 will have to deal with. Customers
are=20 likely to be very concerned about any security holes being exposed as a=20 result
of out=20 of order placement without authentication of the = sender.
 
My=20 position has been of having an optional CRC - not of not having a=20 CRC.
 
Somesh
-----Original Message-----
From: John Hufferd=20 [mailto:hufferd@us.ibm.com]
Sent: Tuesday, May 06, 2003 5:12 = PM
To: Somesh Gupta
Cc: Barron, Dwight; Mogul, = Jeffrey=20 (HPL Palo Alto); rddp@ietf.org; rddp-admin@ietf.org
Subject: = RE:=20 [rddp] CRC mandatory?


Somesh,
You and I = have had this=20 discussion many times.  And I have said that when you combine the = results=20 of that paper with the increase in speed that is now here and coming = in the=20 future,  that it make a strong statement that CRC32c type checks = are=20 needed.

As you know we = made CRC32c=20  a "MUST implement,, optional to use" in iSCSI.  I have = found no one=20 within my company that would ever suggest to our customers that they = should=20 operate with CRC32c turned off.  I have not heard that from our=20 competitors either.  In other words, we made a big deal of making = it=20 optional in iSCSI, but the folks that focus exclusively on storage, = have, as=20 far as I can determine made these checks the defacto way things=20 operate.

As you also = know some=20 folks are attempting to make an adaption which will enable iSCSI to = operate=20 with RDMA, however, without CRC32c covering the headers and data being = a=20 "required to implement" this would not be possible. =

The point that Caitlin and others are = making is (in my=20 opinion) that there are a number of applications that feel a CRC32c = digest is=20 needed.  And we will have to make CRC32c at least a "required to=20 implement (optional to use)", and that negotiating such an option is = not worth=20 the testing effort for the negation itself nor the testing that must = occur at=20 run time with each side having negotiated different options, etc.. =  Also=20 they are stating that from their point of view, the requirement from = customers=20 such as my company, makes it a hard requirement.  And since we = and our=20 competitors require such capability, the RNIC vendor needs to supply = it even=20 if some folks, like yourself, believe it is only a need spun from an = urban=20 legend that is causing the perceived need.

So I think we should at least agree that it = needs to be=20 a MUST implement, and then focus on whether it needs to be optional to = use.

I personally do = not want make=20 it  optional, and want to ensure that the whole packet is = covered.=20

.
.
John L. = Hufferd
Senior=20 Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main = Office:=20 (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: = (408)=20 997-6136, Cell: (408) 499-9702
Internet Address: = hufferd@us.ibm.com=20


"Somesh Gupta"=20 <somesh_gupta@silverbacksystems.com>
Sent by: rddp-admin@ietf.org=20

05/06/2003 12:33 PM =

        =
        To: =    =20    "Barron, Dwight" <Dwight.Barron@hp.com>, = "Mogul,=20 Jeffrey (HPL Palo Alto)" <jeff.mogul@hp.com>,=20 <rddp@ietf.org>
 =20       cc:         =
        Subject: =  =20      RE: [rddp] CRC mandatory?=20



The paper=20 is an excellent arguement for not offloading
integrity checks. A = study of=20 types of errors encountered
is interesting. A single CRC generated = at the=20 egress point,
and checked at the ingress point, would not catch 99% = of
the errors listed because the CRC would be added to = corrupted
data or=20 data be corrupted after CRC check was done.

> -----Original=20 Message-----
> From: rddp-admin@ietf.org = [mailto:rddp-admin@ietf.org]On=20 Behalf Of
> Barron, Dwight
> Sent: Tuesday, May 06, 2003 = 12:12=20 PM
> To: Mogul, Jeffrey (HPL Palo Alto); rddp@ietf.org
> = Subject:=20 RE: [rddp] CRC mandatory?
>
>
> Jeff, I agree = that=20 collecting quantitative data can be useful,
> but also believe = that=20 when it is being used to settle qualitative
> arguments the = thresholds=20 of acceptability are best set before the
> numbers are in. In a = previous posting Jim Williams had stated
> that something in = the same=20 order of magnitude as the TCP stack on
> a per byte basis was = not=20 acceptable. I have not seen any comments
> on what would be = acceptable=20 overhead/criteria in order to gain
> consensus support of a = mandatory=20 CRC, nor any guidance on the
> parameters or type of = environment to=20 measure (but I agree that
> Sparc numbers circa 1995 aren't a = good=20 candidate). While I am not
> volunteering to collect the data = yet, this=20 is a hint that I could
> be coerced into doing so if it would = lead to a=20 more rapid consensus.
>
> However, determining an = acceptable=20 overhead is only one side of
> the equation, determining the = acceptable=20 level of reliability is
> the other. I continue to find the=20 quantitative conclusions in the
> paper "When the CRC and TCP = checksum=20 disagree"
>=20 http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf =
>=20 much more convincing than the qualitative arguments of "I use XYZ =
>=20 file servers all the time and they work just fine."
>
> = Finally,=20 when making an overhead vs. reliability architectural
> = decision, one=20 should realize that while Moore's Law is clearly on
> the side = of=20 lowering overhead over time, the reliability method
> is fixed = for a=20 very long time, in the face of constant or ever
> increasing = errors per=20 unit of time. If I have to bet incorrectly
> on an = architectural=20 decision, I like having time on my side.
>
> = Regards,
>=20 Dwight
>
>
> > -----Original = Message-----
> >=20 From: Mogul, Jeffrey (HPL Palo Alto)
> > Sent: Tuesday, May = 06, 2003=20 12:58 PM
> > To: rddp@ietf.org
> > Subject: Re: = [rddp] CRC=20 mandatory?
> >
> >
> > It seems to me = that one=20 (but NOT the only) consideration in this
> > discussion is = whether=20 CRC calculation is really a burden for a
> > software = implementation.=20  I've seen qualitative assertions
> > (some vaguer than = others)=20 on both sides, but nothing quantitative.
> >
> > = RFC 3309=20 ("Stream Control Transmission Protocol (SCTP)
> > Checksum=20 Change")
> > has an appendix about CRC implementations, and = briefly=20 discusses
> > the issue.  It cites
> > =
> >=20                  David C. = Feldmeier
> >             =    =20  Fast software implementation of error detection codes
> = >=20                  IEEE=20 Transactions on Networking, vol 3 no 6, pp 640-651,
> > =    =20                     =  =20         December, 1995.
> >
> = >=20 Unfortunately, measurements made in 1995 on a SPARCstation LX
> = > (27=20 SPECint932) probably won't mean much in 2003.
> >
> = > I=20 spent a little time with CiteSeer and Google trying to find
> = > a=20 more recent study of CRC performance, but I couldn't find
> > = anything.
> >
> > Perhaps someone with a good = understanding=20 of software CRC
> > implementation could do some measurements = on=20 modern hardware
> > that would give a solid quantitative = basis for=20 our debate?
> > For example, one could hack the Linux or *BSD = stack=20 to
> > do a CRC computation on each TCP segment (sent or=20 received),
> > then throw away the results.  Measuring = the=20 performance change
> > on bulk throughput (say, using = netperf) seems=20 like a reasonable
> > approximation of software CRC = costs.
>=20 >
> > -Jeff
> >
> > P.S.: Don't look = at me!=20  I don't have any spare time this month,
> > nor do I = have a=20 "good understanding of software CRC implementation".
> >=20 _______________________________________________
> > rddp = mailing=20 list
> > rddp@ietf.org
> >=20 https://www1.ietf.org/mailman/listinfo/rddp
> > =
>=20 _______________________________________________
> rddp mailing=20 list
> rddp@ietf.org
>=20 = https://www1.ietf.org/mailman/listinfo/rddp
__________________________= _____________________
rddp=20 mailing=20 = list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
<= /FONT>

------=_NextPart_000_000F_01C3147E.25B1F400-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 12:52:33 2003 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 MAA08064 for ; Wed, 7 May 2003 12:52:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47H1Yt01668 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 13:01:34 -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 h47H1Y801665 for ; Wed, 7 May 2003 13:01:34 -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 MAA08045 for ; Wed, 7 May 2003 12:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSBB-0002sX-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 12:54:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DSBA-0002sU-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 12:54:04 -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 h47GxB801459; Wed, 7 May 2003 12:59: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 h47Gw3801425 for ; Wed, 7 May 2003 12:58:03 -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 MAA07959 for ; Wed, 7 May 2003 12:48:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DS7l-0002rM-00 for rddp@ietf.org; Wed, 07 May 2003 12:50:33 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19DS7k-0002r9-00 for rddp@ietf.org; Wed, 07 May 2003 12:50:32 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 5AF2EA72F; Wed, 7 May 2003 11:50:52 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 11:50:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] Re: Unreliable Transports (was re CRC mandatory? ) Date: Wed, 7 May 2003 11:50:41 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F872403143170@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] Re: Unreliable Transports (was re CRC mandatory? ) Thread-Index: AcMUrEzVAhQW/6Z7SOm0JI4AP2r1KgACv5OQ From: "Barron, Dwight" To: "Caitlin Bestler" , "Stephen Bailey" Cc: X-OriginalArrivalTime: 07 May 2003 16:50:52.0077 (UTC) FILETIME=[D1AC3DD0:01C314B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47Gw3801426 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I agree with Caitlin and believe the discussions of CRC have been in the context of RDDP when mapped to a reliable, connected transport. In fact, I believe the WG has specifically stated that MPA is tied to TCP. That said, I don't necessarily draw the conclusion that an unreliable protocol mapping of RDDP would toss the CRC. Error detection at the receiver is still valuable, even if retransmission is not desired, as some receiver schemas might want to toss known bad data and synthesize a replacement. Regards, Dwight > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Wednesday, May 07, 2003 10:15 AM > To: Stephen Bailey > Cc: rddp@ietf.org > Subject: [rddp] Re: Unreliable Transports (was re CRC mandatory? ) > > > On 5/7/03, Stephen Bailey wrote: > > >I think you've gone too far if you say CRC protection is a > >specific instance of a general principle we should apply. > >CRC protection is CRC protection. The general principle > >is to leave as much flexibility to the implementations > >while still providing a useful service. Saying that RDDP > >MUST run on a sequenced, reliable, CRC protected transport > >seems ridiculous. > > Agreed. > > To be more precise, RDDP should have uniform expectations > for sequenced/reliable transports. > > It has been my assumption all along that RDDP maps very > well to unreliable transports, but that the use of an > unreliable transport is something that the ULP would > request to meet specific requirements. > > The specific issue that will have to be dealt with when > we are ready to address unreliable transports is how the > set of DDP Segments that form an atomic made it / lost it > decision are identified. When we discussed this briefly > on the old yahoo groups you seemed to favor having the > receiving ULP make such determinations, I favored > explicitly labeling the RDMA Writes and Send that > formed a cohesive accept it/drop it unit. > > But I think we both agree that unreliable RDDP is a > specialized application that can be dealt with after the > reliable version has been fully dealt with. [And even if > we don't, David would probably agree for us more vehemently, > ;-) ]. > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 13:39:27 2003 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 NAA09619 for ; Wed, 7 May 2003 13:39:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47HmVY05942 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 13:48:31 -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 h47HmV805939 for ; Wed, 7 May 2003 13:48:31 -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 NAA09580 for ; Wed, 7 May 2003 13:38:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSua-0003D6-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 13:41:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DSua-0003D3-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 13:41:00 -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 h47HlU805866; Wed, 7 May 2003 13:47:30 -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 h47Hkx805809 for ; Wed, 7 May 2003 13:46:59 -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 NAA09554 for ; Wed, 7 May 2003 13:37:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSt7-0003Ce-00 for rddp@ietf.org; Wed, 07 May 2003 13:39:29 -0400 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSt6-0003CW-00 for rddp@ietf.org; Wed, 07 May 2003 13:39:28 -0400 Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.12.9/8.12.8) with ESMTP id h47HdkLW002708 for ; Wed, 7 May 2003 10:39:47 -0700 (PDT) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 13:39:46 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF289B9078@xbl.ma.emulex.com> From: "Williams, Jim" To: rddp@ietf.org Date: Wed, 7 May 2003 13:39:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [rddp] Optional CRC: Proposed Compromise 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , I would like to throw out the following proposed compromise position. I will withdraw it if there is strong opposition from either side of this discussion. CRC is optional. If used, CRC coverage must include both header and payload. CRC MUST be used unless BOTH ends of a connection opt to not use it. An implementation MAY choose to always require CRC and therefore not implement non-CRC mode. (I.e. optional CRCs are optional to implement, with the default being to use CRCs.) If both ends opt to not use CRCs, then neither header or payload will be covered by CRC. I believe this is totally transparent and painless to implementers that want to always use CRCs. But it doesn't preclude other vendors that think there might be a subset of the market that could benefit from software implementations not using CRCs. My intent is NOT to address the question of whether header and payload are covered by the same CRC or different. That is a separate discussion. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 13:49:57 2003 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 NAA09955 for ; Wed, 7 May 2003 13:49:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Hx1T06537 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 13:59:01 -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 h47Hx1806534 for ; Wed, 7 May 2003 13:59:01 -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 NAA09894 for ; Wed, 7 May 2003 13:49:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DT4k-0003HX-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 13:51:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DT4k-0003HU-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 13:51:30 -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 h47Hw1806479; Wed, 7 May 2003 13:58:01 -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 h47HvH806398 for ; Wed, 7 May 2003 13:57:17 -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 NAA09841 for ; Wed, 7 May 2003 13:47:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DT34-0003Gf-00 for rddp@ietf.org; Wed, 07 May 2003 13:49:46 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19DT33-0003GQ-00 for rddp@ietf.org; Wed, 07 May 2003 13:49:45 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id D025DAE23; Wed, 7 May 2003 12:50:08 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 12:50:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314C1.19376F50" Subject: RE: [rddp] CRC mandatory? Date: Wed, 7 May 2003 12:50:08 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F872403159D6D@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] CRC mandatory? Thread-Index: AcMUuRtzyChCltd0Suiep2NhyPY70wABpGFg From: "Barron, Dwight" To: "Somesh Gupta" Cc: X-OriginalArrivalTime: 07 May 2003 17:50:08.0608 (UTC) FILETIME=[1987CE00:01C314C1] 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C314C1.19376F50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Somesh, my understanding is that IPSEC, even if implemented in the same = node as iSCSI or RDDP is currently transparent to the ULP for any given = source/destination IP address pair. How would you propose that a ULP = determine this necessary information in order to know when to turn CRC = on or off? This would be compounded even further by external devices = located one or more hops away that provided the IPSEC functionality.=20 =20 Regards, Dwight IPSec is also mandatory to implement and optional to use. A reasonable = section of the community also feels that for iSCSI to have widespread = deployment, IPSec is a more important technology than some of the other features. And if = IPSec gets deployed, an additional CRC becomes meaningless. =20 IPSec is also something that the RDMA community will have to deal with. = Customers are likely to be very concerned about any security holes being exposed = as a result of out of order placement without authentication of the sender. =20 My position has been of having an optional CRC - not of not having a = CRC. =20 Somesh =20 ------_=_NextPart_001_01C314C1.19376F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Somesh, my understanding is that IPSEC, = even if=20 implemented in the same node as iSCSI or RDDP is currently transparent = to the=20 ULP for any given source/destination IP address pair. How would you = propose that=20 a ULP determine this necessary information in order to know when to turn = CRC on=20 or off? This would be compounded even further by external devices = located one or=20 more hops away that provided the IPSEC functionality. =
 
Regards,
Dwight
IPSec is also mandatory to implement and = optional to=20 use. A reasonable section
of=20 the community also feels that for iSCSI to have widespread deployment, = IPSec
is a=20 more important technology than some of the other features. And if=20 IPSec
gets=20 deployed, an additional CRC becomes meaningless.
 
IPSec is also something that the RDMA = community=20 will have to deal with. Customers
are=20 likely to be very concerned about any security holes being exposed as = a=20 result
of=20 out of order placement without authentication of the=20 sender.
 
My=20 position has been of having an optional CRC - not of not having a=20 CRC.
 
Somesh
 
------_=_NextPart_001_01C314C1.19376F50-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 14:07:16 2003 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 OAA10577 for ; Wed, 7 May 2003 14:07:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47IGLv08472 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 14:16:21 -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 h47IGL808468 for ; Wed, 7 May 2003 14:16:21 -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 OAA10545 for ; Wed, 7 May 2003 14:06:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTLW-0003Pm-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 14:08:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DTLP-0003Pi-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 14:08:43 -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 h47IFP808355; Wed, 7 May 2003 14:15:25 -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 h47I9p808053 for ; Wed, 7 May 2003 14:09:51 -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 OAA10331 for ; Wed, 7 May 2003 14:00:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTFE-0003MN-00 for rddp@ietf.org; Wed, 07 May 2003 14:02:20 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 19DTFD-0003ME-00 for rddp@ietf.org; Wed, 07 May 2003 14:02:19 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id A1124B044; Wed, 7 May 2003 13:02:42 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 13:02:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] Optional CRC: Proposed Compromise Date: Wed, 7 May 2003 13:02:41 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F872403143171@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] Optional CRC: Proposed Compromise Thread-Index: AcMUwHSc6rBu3kZpTiCDGqe3IUHecgAAQYkQ From: "Barron, Dwight" To: "Williams, Jim" , X-OriginalArrivalTime: 07 May 2003 18:02:42.0390 (UTC) FILETIME=[DAD1CF60:01C314C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47I9p808054 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, would provide comments on the acceptability of the following clarification points (aka fine print)? - The CRC option always applies to both directions of a connection - The CRC field is always present, but sometimes may not be valid - The disposition of the CRC option is never made available to the ULP This last item probably deserves some explanation. One of the reasons that I want CRCs mandatory is to stop the proliferation of "sufficient" transport error checking up to the ULP. I believe that one of the reasons you want CRCs optional is that you deem link CRC+TCP checksum "sufficient." In both cases, I don't believe either of us are proposing that the ULP take additional measures. Regards, Dwight > -----Original Message----- > From: Williams, Jim [mailto:Jim.Williams@emulex.com] > Sent: Wednesday, May 07, 2003 12:40 PM > To: rddp@ietf.org > Subject: [rddp] Optional CRC: Proposed Compromise > > > I would like to throw out the following > proposed compromise position. I will > withdraw it if there is strong opposition > from either side of this discussion. > > CRC is optional. If used, CRC coverage > must include both header and payload. > CRC MUST be used unless BOTH ends of a > connection opt to not use it. > An implementation MAY choose to > always require CRC and therefore > not implement non-CRC mode. > (I.e. optional CRCs are optional > to implement, with the default > being to use CRCs.) > > If both ends opt to not use CRCs, > then neither header or payload > will be covered by CRC. > > I believe this is totally transparent > and painless to implementers that want > to always use CRCs. But it doesn't > preclude other vendors that think > there might be a subset of the market > that could benefit from software > implementations not using CRCs. > > My intent is NOT to address the question > of whether header and payload are > covered by the same CRC or different. > That is a separate discussion. > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 14:25:51 2003 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 OAA11313 for ; Wed, 7 May 2003 14:25:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47IYup10111 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 14:34:56 -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 h47IYu810108 for ; Wed, 7 May 2003 14:34:56 -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 OAA11285 for ; Wed, 7 May 2003 14:25:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTdU-0003cX-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 14:27:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DTdU-0003cU-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 14:27:24 -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 h47IY8810033; Wed, 7 May 2003 14:34:08 -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 h47IVE809658 for ; Wed, 7 May 2003 14:31:14 -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 OAA11116 for ; Wed, 7 May 2003 14:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTZv-0003Z8-00 for rddp@ietf.org; Wed, 07 May 2003 14:23:43 -0400 Received: from sandmail.sandburst.com ([216.57.132.42]) by ietf-mx with esmtp (Exim 4.12) id 19DTZu-0003Yz-00 for rddp@ietf.org; Wed, 07 May 2003 14:23:42 -0400 To: "Barron, Dwight" Cc: rddp@ietf.org, "Caitlin Bestler" Subject: Re: [rddp] Re: Unreliable Transports (was re CRC mandatory? ) In-Reply-To: Message from "Barron, Dwight" of "Wed, 07 May 2003 11:50:41 CDT." <01CA1B1F74A4EC40A9C887F7B58F872403143170@cceexc16.americas.cpqcorp.net> References: <01CA1B1F74A4EC40A9C887F7B58F872403143170@cceexc16.americas.cpqcorp.net> Date: Wed, 07 May 2003 14:24:02 -0400 From: Stephen Bailey Message-Id: <20030507182404.C6CFC4EC8@sandmail.sandburst.com> 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , > I agree with Caitlin and believe the discussions of CRC have been in the > context of RDDP when mapped to a reliable, connected transport. Oh. Perhaps that wasn't clear (I didn't see `reliable, connected and sequenced' anywhere juxtaposed with `uniform transport assumptions'), or maybe I'm just a bullethead. As long as everybody else is really just talking about to CRC or not CRC, I'm less concerned :-). Thanks, Steph _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 14:50:00 2003 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 OAA12330 for ; Wed, 7 May 2003 14:50:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Ix6Z12501 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 14:59:06 -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 h47Ix6812498 for ; Wed, 7 May 2003 14:59:06 -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 OAA12315 for ; Wed, 7 May 2003 14:49:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DU0s-0003oq-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 14:51:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DU0r-0003on-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 14:51:33 -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 h47It3812272; Wed, 7 May 2003 14:55:03 -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 h47IsZ812244 for ; Wed, 7 May 2003 14:54:35 -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 OAA12142 for ; Wed, 7 May 2003 14:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTwV-0003mn-00 for rddp@ietf.org; Wed, 07 May 2003 14:47:03 -0400 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTwV-0003mh-00 for rddp@ietf.org; Wed, 07 May 2003 14:47:03 -0400 Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.12.9/8.12.8) with ESMTP id h47IlKLW004608 for ; Wed, 7 May 2003 11:47:20 -0700 (PDT) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 14:47:19 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF289B9079@xbl.ma.emulex.com> From: "Williams, Jim" To: rddp@ietf.org Subject: RE: [rddp] Optional CRC: Proposed Compromise Date: Wed, 7 May 2003 14:47:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Barron, Dwight [mailto:Dwight.Barron@hp.com] > Sent: Wednesday, May 07, 2003 2:03 PM > To: Williams, Jim; rddp@ietf.org > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > Jim, would provide comments on the acceptability of the > following clarification points (aka fine print)? > > - The CRC option always applies to both directions of a connection That's what I intended. Sorry if that was not clear. > - The CRC field is always present, but sometimes may not be valid This drops down to a lower level of detail. However, that approach sounds right to me. > - The disposition of the CRC option is never made available to the ULP Likewise the request to opt out of CRC use should not come from the ULP, or be visible to the ULP. This doesn't sound like a problem in principle. TCP typically doesn't notify the application of what options are negotiated at the TCP layer. I don't know, however, what a reasonable wording of this requirement would be. It seems a bit strong to require RDDP to insure that the ULP cannot, by any means, determine this. Certainly vendors providing management interfaces would want to make this type of information available. Any reasonable wording should be OK, though, as long as it's not too extreme, and clear on the spirit. > I believe that one of the reasons you want CRCs > optional is that you deem link CRC+TCP checksum "sufficient." Sufficient in some cases. That's the only reason. > In both cases, I don't believe either of us are proposing > that the ULP take additional measures. I agree. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 15:11:51 2003 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 PAA13629 for ; Wed, 7 May 2003 15:11:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47JKwI14386 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 15:20:58 -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 h47JKw814383 for ; Wed, 7 May 2003 15:20:58 -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 PAA13570 for ; Wed, 7 May 2003 15:11:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DUM1-0003vz-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 15:13:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DUM1-0003vw-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 15:13:25 -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 h47JK9814343; Wed, 7 May 2003 15:20:09 -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 h47JJD814278 for ; Wed, 7 May 2003 15:19:13 -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 PAA13390 for ; Wed, 7 May 2003 15:09:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DUKK-0003v8-00 for rddp@ietf.org; Wed, 07 May 2003 15:11:40 -0400 Received: from h020.c001.snv.cp.net ([209.228.32.134] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 19DUKJ-0003v5-00 for rddp@ietf.org; Wed, 07 May 2003 15:11:39 -0400 Received: (cpmta 19786 invoked from network); 7 May 2003 12:12:32 -0700 Received: from 63.193.3.254 (HELO zyteraphqohm96) by smtp.register-admin.com (209.228.32.134) with SMTP; 7 May 2003 12:12:32 -0700 X-Sent: 7 May 2003 19:12:32 GMT Reply-To: From: "John A. Thodiyil" To: Subject: RE: [rddp] Optional CRC: Proposed Compromise Date: Wed, 7 May 2003 12:14:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3356669BBE90C448AD4645C843E2BF289B9079@xbl.ma.emulex.com> Importance: Normal Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi RDDP Group I have been following the Emails on this forum for a while. I have some ideas. But i would like to get a detailed picture of whats going on. As, i started following this later in the process. Any suggestions for me to get to the level of speaking and making sense will be appreciated. I however would like to make the comment that CRC at the RDDP level has positives and negatives. By making the CRC optional we do not forgo the positives and have the option to prevent the negatives. This CRC negotiation can happen at the RDDP level since at STCP/TCP does not look like a good place to do this and there are no hooks at this point of life of TCP. -John -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Williams, Jim Sent: Wednesday, May 07, 2003 11:47 AM To: rddp@ietf.org Subject: RE: [rddp] Optional CRC: Proposed Compromise > -----Original Message----- > From: Barron, Dwight [mailto:Dwight.Barron@hp.com] > Sent: Wednesday, May 07, 2003 2:03 PM > To: Williams, Jim; rddp@ietf.org > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > Jim, would provide comments on the acceptability of the > following clarification points (aka fine print)? > > - The CRC option always applies to both directions of a connection That's what I intended. Sorry if that was not clear. > - The CRC field is always present, but sometimes may not be valid This drops down to a lower level of detail. However, that approach sounds right to me. > - The disposition of the CRC option is never made available to the ULP Likewise the request to opt out of CRC use should not come from the ULP, or be visible to the ULP. This doesn't sound like a problem in principle. TCP typically doesn't notify the application of what options are negotiated at the TCP layer. I don't know, however, what a reasonable wording of this requirement would be. It seems a bit strong to require RDDP to insure that the ULP cannot, by any means, determine this. Certainly vendors providing management interfaces would want to make this type of information available. Any reasonable wording should be OK, though, as long as it's not too extreme, and clear on the spirit. > I believe that one of the reasons you want CRCs > optional is that you deem link CRC+TCP checksum "sufficient." Sufficient in some cases. That's the only reason. > In both cases, I don't believe either of us are proposing > that the ULP take additional measures. I agree. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 17:13:20 2003 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 RAA17772 for ; Wed, 7 May 2003 17:13:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47LMSq24709 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 17:22:28 -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 h47LMR824706 for ; Wed, 7 May 2003 17:22:27 -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 RAA17764 for ; Wed, 7 May 2003 17:12:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DWFZ-0004oN-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 17:14:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DWFY-0004oK-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 17:14:52 -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 h47LIS824491; Wed, 7 May 2003 17:18:28 -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 h47LCK824155 for ; Wed, 7 May 2003 17:12:20 -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 RAA17434 for ; Wed, 7 May 2003 17:02:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DW5m-0004jZ-00 for rddp@ietf.org; Wed, 07 May 2003 17:04:46 -0400 Received: from h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 19DW5l-0004jQ-00 for rddp@ietf.org; Wed, 07 May 2003 17:04:45 -0400 Received: (cpmta 8427 invoked from network); 7 May 2003 14:05:35 -0700 Received: from 63.193.3.254 (HELO zyteraphqohm96) by smtp.register-admin.com (209.228.32.119) with SMTP; 7 May 2003 14:05:35 -0700 X-Sent: 7 May 2003 21:05:35 GMT Reply-To: From: "John A. Thodiyil" To: Subject: RE: [rddp] CRC32C Calculation "Burden" Date: Wed, 7 May 2003 14:07:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The Gallois field approach to CRC32 calculation is very fast, not withstanding my suggestion to making CRC optional, just incase its enabled. -John -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Caitlin Bestler Sent: Tuesday, May 06, 2003 6:34 PM To: rddp@ietf.org Subject: [rddp] CRC32C Calculation "Burden" RFC 3385 section 8.2 gives a parallel implementation of CRC-32c. It takes as input the next 32 bits of data and the current 32 bit CRC. The result is a new 32 bit CRC. The algorithm presented is based on the fact that each bit of the resulting CRC is an XOR of a subset of the input bits (the original CRC and new data). If you examine the formulas, though, you will realize that the reverse is also true. Each input bit effects a subset of the result. Further the contribution of any set of input bits is an xor of the contribution of each of those bits. More precisely: contributionOf [x^y] = contributionOf[x] ^ contributionOf[y]. These could be rolled into a large table, resulting in a very short calculation: newCRC = contributionOfCRC[oldCRC] ^ contributionOfData[newData]. Of course that's 2 tables with 2**32 entries. Probably a bit too large. Working 16 bits at a time: newCRC.high = contributionOfCRChigh[oldCRC.high] ^ contributionOfCRClow[oldCRC.low] ^ contributionOfDataHigh[newData.high] ^ contributionOfDataLow[newData.low]; That produces one indexed lookup and one XOR operation per byte. Any size can be pre-factored. The Linux code for SCTP uses 256 entry tables. Smaller tables result in more operations, but increase the ability to keep the lookup table cached. If you go down to calculating the effect bit-by-bit the "tables" become in-line constants. This minimizes random access to code space for constant tables, but increases the number of calculations. Of course many processors can perform numerous calculations for each non-cached memory fetch, so the tradeoff is complex. The optimum balance is dependent on the memory architecture. In particular, whether fetches from constant tables in code-space can execute in parallel with fetches of the new data byte. The CRC itself would remain in a register or at least cached. But whatever combination is selected, there are at most a few simple operations per 32 bits, and no additional memory touches to uncached data space are required. Given those two factors, I cannot see how a CRC32C calculation can possibly be considered an unreasonable burden for software implementations. Note, the referenced Linux implementation can be found at: http://www.linuxhq.com/kernel/v2.5/33/net/sctp/crc32c.c Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 7 19:21:58 2003 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 TAA23206 for ; Wed, 7 May 2003 19:21:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47NV9n03434 for rddp-archive@odin.ietf.org; Wed, 7 May 2003 19:31:09 -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 h47NV9803431 for ; Wed, 7 May 2003 19:31:09 -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 TAA23184 for ; Wed, 7 May 2003 19:21:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DYG3-0005uE-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 19:23:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DYG3-0005uB-00 for rddp-web-archive@ietf.org; Wed, 07 May 2003 19:23:31 -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 h47NU9803331; Wed, 7 May 2003 19:30:09 -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 h47NS5803214 for ; Wed, 7 May 2003 19:28:05 -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 TAA23115; Wed, 7 May 2003 19:18:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DYD5-0005sZ-00; Wed, 07 May 2003 19:20:27 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19DYD4-0005sE-00; Wed, 07 May 2003 19:20:26 -0400 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h47NKnQs090302; Wed, 7 May 2003 19:20:49 -0400 Received: from d03nm115.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h47NKFAq069428; Wed, 7 May 2003 17:20:34 -0600 To: rddp@ietf.org, rddp-admin@ietf.org MIME-Version: 1.0 Subject: RE: [rddp] Optional CRC: Proposed Compromise X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Wed, 7 May 2003 16:20:25 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/07/2003 17:20:34, Serialize complete at 05/07/2003 17:20:34 Content-Type: multipart/alternative; boundary="=_alternative 0080367F88256D1F_=" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0080367F88256D1F_= Content-Type: text/plain; charset="us-ascii" I now think we are headed in the right direction, and think that Jim and Dwight have something that we can get behind and flesh out. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Williams, Jim" Sent by: rddp-admin@ietf.org 05/07/2003 11:47 AM To: rddp@ietf.org cc: Subject: RE: [rddp] Optional CRC: Proposed Compromise > -----Original Message----- > From: Barron, Dwight [mailto:Dwight.Barron@hp.com] > Sent: Wednesday, May 07, 2003 2:03 PM > To: Williams, Jim; rddp@ietf.org > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > Jim, would provide comments on the acceptability of the > following clarification points (aka fine print)? > > - The CRC option always applies to both directions of a connection That's what I intended. Sorry if that was not clear. > - The CRC field is always present, but sometimes may not be valid This drops down to a lower level of detail. However, that approach sounds right to me. > - The disposition of the CRC option is never made available to the ULP Likewise the request to opt out of CRC use should not come from the ULP, or be visible to the ULP. This doesn't sound like a problem in principle. TCP typically doesn't notify the application of what options are negotiated at the TCP layer. I don't know, however, what a reasonable wording of this requirement would be. It seems a bit strong to require RDDP to insure that the ULP cannot, by any means, determine this. Certainly vendors providing management interfaces would want to make this type of information available. Any reasonable wording should be OK, though, as long as it's not too extreme, and clear on the spirit. > I believe that one of the reasons you want CRCs > optional is that you deem link CRC+TCP checksum "sufficient." Sufficient in some cases. That's the only reason. > In both cases, I don't believe either of us are proposing > that the ULP take additional measures. I agree. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --=_alternative 0080367F88256D1F_= Content-Type: text/html; charset="us-ascii"
I now think we are headed in the right direction, and think that Jim and Dwight have something that we can get behind and flesh out.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Williams, Jim" <Jim.Williams@emulex.com>
Sent by: rddp-admin@ietf.org

05/07/2003 11:47 AM

       
        To:        rddp@ietf.org
        cc:        
        Subject:        RE: [rddp] Optional CRC: Proposed Compromise





> -----Original Message-----
> From: Barron, Dwight [mailto:Dwight.Barron@hp.com]
> Sent: Wednesday, May 07, 2003 2:03 PM
> To: Williams, Jim; rddp@ietf.org
> Subject: RE: [rddp] Optional CRC: Proposed Compromise
>
>
> Jim, would provide comments on the acceptability of the
> following clarification points (aka fine print)?
>
> - The CRC option always applies to both directions of a connection

That's what I intended.  Sorry if that was not clear.

> - The CRC field is always present, but sometimes may not be valid

This drops down to a lower level of detail.
However, that approach sounds right to me.

> - The disposition of the CRC option is never made available to the ULP

Likewise the request to opt out of CRC use
should not come from the ULP, or be visible to the ULP.

This doesn't sound like a problem in principle.  TCP typically
doesn't notify the application of what options are negotiated
at the TCP layer.  I don't know, however, what a reasonable
wording of this requirement would be.  It seems a bit strong
to require RDDP to insure that the ULP cannot, by any means,
determine this.  Certainly vendors providing management
interfaces would want to make this type of information
available.  Any reasonable wording should be OK, though,
as long as it's not too extreme, and clear on the spirit.

> I believe that one of the reasons you want CRCs
> optional is that you deem link CRC+TCP checksum "sufficient."

Sufficient in some cases.  That's the only reason.

> In both cases, I don't believe either of us are proposing
> that the ULP take additional measures.

I agree.


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

--=_alternative 0080367F88256D1F_=-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 00:30:38 2003 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 AAA00030 for ; Thu, 8 May 2003 00:30:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h484dtR25934 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 00:39:55 -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 h484ds825930 for ; Thu, 8 May 2003 00:39:54 -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 AAA00006 for ; Thu, 8 May 2003 00:30:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dd4k-0007Zz-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 00:32:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dd4k-0007Zw-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 00:32:10 -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 h484dA825915; Thu, 8 May 2003 00:39:10 -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 h484cQ825872 for ; Thu, 8 May 2003 00:38:26 -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 AAA29992 for ; Thu, 8 May 2003 00:28:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dd3J-0007Zo-00 for rddp@ietf.org; Thu, 08 May 2003 00:30:41 -0400 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 19Dd3J-0007Za-00 for rddp@ietf.org; Thu, 08 May 2003 00:30:41 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 21B2B244BA2 for ; Thu, 8 May 2003 00:31:24 -0400 (EDT) Date: Wed, 7 May 2003 23:31:14 -0500 From: Caitlin Bestler Subject: RE: [rddp] Optional CRC: Proposed Compromise To: rddp@ietf.org X-Priority: 3 In-Reply-To: <01CA1B1F74A4EC40A9C887F7B58F872403143171@cceexc16.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/7/03, Barron, Dwight wrote: >- The disposition of the CRC option is never made > available to the ULP A receiving ULP needs to be able to determine whether it can tolerate "transport specific" payload protection. As outlined in prior posts, there are applications that *cannot* tolerate the risk of header correction, and unlike payload protection there is no easy correction for such applications. Therefore the option to suppress MPA CRCs would have to be agreed to by the sending MPA, receiving MPA and the receiving ULP. At that point the only "cost" of allowing the option is the two bits required in the MPA mode mask (I'm willing to receive/send without CRC). The most that any implementation would be forced to deal with suppressed CRCs would be to not set bits, so the other side knew. I'm not certain how much the option is really worth at that point -- but it is certainly minimal cost. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 13:32:29 2003 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 NAA00980 for ; Thu, 8 May 2003 13:32:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48Hg1t01653 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 13:42:01 -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 h48Hg1801650 for ; Thu, 8 May 2003 13:42:01 -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 NAA00971 for ; Thu, 8 May 2003 13:31:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DpHN-0004Xd-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 13:34:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DpHM-0004XZ-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 13:34:00 -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 h48HfC801583; Thu, 8 May 2003 13:41:12 -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 h48Hcq801425 for ; Thu, 8 May 2003 13:38:52 -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 NAA00886 for ; Thu, 8 May 2003 13:28:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DpEJ-0004Wq-00 for rddp@ietf.org; Thu, 08 May 2003 13:30:51 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19DpEI-0004Wd-00 for rddp@ietf.org; Thu, 08 May 2003 13:30:50 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 2E3DBD3B3; Thu, 8 May 2003 10:31:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C463F21907; Thu, 8 May 2003 10:31:00 -0700 (PDT) Cc: Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C3154C.F20AFCD0" Date: Thu, 8 May 2003 10:31:11 -0700 From: "Somesh Gupta" Importance: Normal In-reply-to: <01CA1B1F74A4EC40A9C887F7B58F872403159D6D@cceexc16.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 00140-4285F3B9; Thu, 08 May 2003 10:30:58 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id C03971FD44; Thu, 8 May 2003 10:30:58 -0700 (PDT) Subject: RE: [rddp] CRC mandatory? To: "Barron, Dwight" X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C3154C.F20AFCD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dwight, I would ignore the IPSec in the gateway device for the purpose of this discussion. Perhaps looking at the "IPSec Offload" interfaces of some (one??) OS vendor will give an idea of how Offload is signalled from the host. There is always an administration/config plane to any and all apps. The app typically does not decide which remote system it communicates to or provides services to, it does not decide which files it will use, it does not decide whether IPSec is on or off. It can as easily be informed to have request CRC on or off - although that is as likely to be a systemwide decision. Somesh -----Original Message----- From: Barron, Dwight [mailto:Dwight.Barron@hp.com] Sent: Wednesday, May 07, 2003 10:50 AM To: Somesh Gupta Cc: rddp@ietf.org Subject: RE: [rddp] CRC mandatory? Somesh, my understanding is that IPSEC, even if implemented in the same node as iSCSI or RDDP is currently transparent to the ULP for any given source/destination IP address pair. How would you propose that a ULP determine this necessary information in order to know when to turn CRC on or off? This would be compounded even further by external devices located one or more hops away that provided the IPSEC functionality. Regards, Dwight IPSec is also mandatory to implement and optional to use. A reasonable section of the community also feels that for iSCSI to have widespread deployment, IPSec is a more important technology than some of the other features. And if IPSec gets deployed, an additional CRC becomes meaningless. IPSec is also something that the RDMA community will have to deal with. Customers are likely to be very concerned about any security holes being exposed as a result of out of order placement without authentication of the sender. My position has been of having an optional CRC - not of not having a CRC. Somesh ------=_NextPart_000_0049_01C3154C.F20AFCD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dwight,
 
I=20 would ignore the IPSec in the gateway device for the purpose of=20 this
discussion. Perhaps looking at the "IPSec = Offload"=20 interfaces of some
(one??) OS vendor will give an idea of how = Offload is=20 signalled from the
host.
 
There=20 is always an administration/config plane to any and all apps.=20 The
app=20 typically does not decide which remote system it=20 communicates
to or=20 provides services to, it does not decide which files it will use,=20 it
does=20 not decide whether IPSec is on or off. It can as easily be=20 informed
to=20 have request CRC on or off - although that is as likely to be a=20 systemwide
decision.
 
Somesh
-----Original Message-----
From: Barron, Dwight=20 [mailto:Dwight.Barron@hp.com]
Sent: Wednesday, May 07, 2003 = 10:50=20 AM
To: Somesh Gupta
Cc: = rddp@ietf.org
Subject:=20 RE: [rddp] CRC mandatory?

Somesh, my understanding is that IPSEC, = even if=20 implemented in the same node as iSCSI or RDDP is currently transparent = to the=20 ULP for any given source/destination IP address pair. How would you = propose=20 that a ULP determine this necessary information in order to know when = to turn=20 CRC on or off? This would be compounded even further by external = devices=20 located one or more hops away that provided the IPSEC functionality.=20
 
Regards,
Dwight
IPSec is also mandatory to implement and = optional=20 to use. A reasonable section
of=20 the community also feels that for iSCSI to have widespread = deployment,=20 IPSec
is=20 a more important technology than some of the other features. And if=20 IPSec
gets deployed, an additional CRC becomes=20 meaningless.
 
IPSec is also something that the = RDMA=20 community will have to deal with. Customers
are likely to be very concerned about any = security=20 holes being exposed as a result
of=20 out of order placement without authentication of the=20 sender.
 
My=20 position has been of having an optional CRC - not of not having a=20 CRC.
 
Somesh
 
------=_NextPart_000_0049_01C3154C.F20AFCD0-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 13:39:13 2003 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 NAA01181 for ; Thu, 8 May 2003 13:39:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48Hmki02021 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 13:48:46 -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 h48Hmj802018 for ; Thu, 8 May 2003 13:48:46 -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 NAA01155 for ; Thu, 8 May 2003 13:38:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DpNs-0004aI-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 13:40:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DpNs-0004aF-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 13:40:44 -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 h48Hm0801960; Thu, 8 May 2003 13:48:00 -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 h48HjE801829 for ; Thu, 8 May 2003 13:45:14 -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 NAA01059 for ; Thu, 8 May 2003 13:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DpKT-0004YZ-00 for rddp@ietf.org; Thu, 08 May 2003 13:37:13 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19DpKS-0004YD-00 for rddp@ietf.org; Thu, 08 May 2003 13:37:12 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 4BF72D3B3 for ; Thu, 8 May 2003 10:37:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 324202161B for ; Thu, 8 May 2003 10:37:23 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 8 May 2003 10:37:34 -0700 From: "Somesh Gupta" Importance: Normal In-reply-to: <01CA1B1F74A4EC40A9C887F7B58F872403143171@cceexc16.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 00429-70E412E1; Thu, 08 May 2003 10:37:22 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id E72F92161B for ; Thu, 8 May 2003 10:37:21 -0700 (PDT) Subject: RE: [rddp] Optional CRC: Proposed Compromise To: X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't think the CRC field should be present if not in use (It does make sense to have it be present or absent in both directions at the same time). There are fairly reasonable scenarios that make it completely not useful (to be PC here). A combination of IPSec offload that is likely to become common and free (part of the NIC cost) combined with the first hack of an iSCSI based storage server is likely to make IPSec a must have for authentication. This will take care of worries about integrity as well as resegmenting middle boxes. As always caveats etc. for something not here. Somesh > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > Barron, Dwight > Sent: Wednesday, May 07, 2003 11:03 AM > To: Williams, Jim; rddp@ietf.org > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > Jim, would provide comments on the acceptability of the following > clarification points (aka fine print)? > > - The CRC option always applies to both directions of a connection > - The CRC field is always present, but sometimes may not be valid > - The disposition of the CRC option is never made available to the ULP > > This last item probably deserves some explanation. One of the > reasons that I want CRCs mandatory is to stop the proliferation > of "sufficient" transport error checking up to the ULP. I believe > that one of the reasons you want CRCs optional is that you deem > link CRC+TCP checksum "sufficient." In both cases, I don't > believe either of us are proposing that the ULP take additional measures. > > Regards, > Dwight > > > -----Original Message----- > > From: Williams, Jim [mailto:Jim.Williams@emulex.com] > > Sent: Wednesday, May 07, 2003 12:40 PM > > To: rddp@ietf.org > > Subject: [rddp] Optional CRC: Proposed Compromise > > > > > > I would like to throw out the following > > proposed compromise position. I will > > withdraw it if there is strong opposition > > from either side of this discussion. > > > > CRC is optional. If used, CRC coverage > > must include both header and payload. > > CRC MUST be used unless BOTH ends of a > > connection opt to not use it. > > An implementation MAY choose to > > always require CRC and therefore > > not implement non-CRC mode. > > (I.e. optional CRCs are optional > > to implement, with the default > > being to use CRCs.) > > > > If both ends opt to not use CRCs, > > then neither header or payload > > will be covered by CRC. > > > > I believe this is totally transparent > > and painless to implementers that want > > to always use CRCs. But it doesn't > > preclude other vendors that think > > there might be a subset of the market > > that could benefit from software > > implementations not using CRCs. > > > > My intent is NOT to address the question > > of whether header and payload are > > covered by the same CRC or different. > > That is a separate discussion. > > > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 14:07:37 2003 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 OAA02053 for ; Thu, 8 May 2003 14:07:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48IHB704442 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 14:17: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 h48IHB804439 for ; Thu, 8 May 2003 14:17: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 OAA02040 for ; Thu, 8 May 2003 14:07:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DppN-0004oc-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:09:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DppN-0004oZ-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:09:09 -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 h48IA2804034; Thu, 8 May 2003 14:10:02 -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 h48I9m804003 for ; Thu, 8 May 2003 14:09:48 -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 NAA01856 for ; Thu, 8 May 2003 13:59:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DpiF-0004ld-00 for rddp@ietf.org; Thu, 08 May 2003 14:01:47 -0400 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 19DpiE-0004lX-00 for rddp@ietf.org; Thu, 08 May 2003 14:01:46 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 4F3B3244D29; Thu, 8 May 2003 14:02:32 -0400 (EDT) Date: Thu, 8 May 2003 13:02:22 -0500 From: Caitlin Bestler Subject: RE: [rddp] Optional CRC: Proposed Compromise To: rddp@ietf.org Cc: Somesh Gupta X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/8/03, Somesh Gupta wrote: >I don't think the CRC field should be present if not in use >(It does make sense to have it be present or absent in both >directions at the same time). Having the field always be present simplifies startup. If the CRC field is always present, a sender could transmit the MPA mode frame and the first data frame with a valid CRC. A valid CRC is acceptable to the other side whether it support CRC suppression or not. If the CRC field were to be omitted, not merely voided, neither side could transmit the first data frame until after receiving the other's mode frame. That would delay the start of productive data transfer. Always having the CRC field present will also simplify coding. There will be fewer places where the mode will have to be checked. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 14:22:43 2003 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 OAA02481 for ; Thu, 8 May 2003 14:22:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48IWHe05378 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 14:32:17 -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 h48IWH805375 for ; Thu, 8 May 2003 14:32:17 -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 OAA02460 for ; Thu, 8 May 2003 14:22:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dq3z-0004uG-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:24:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dq3z-0004uD-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:24: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 h48IVS805304; Thu, 8 May 2003 14:31:28 -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 h48IRt805054 for ; Thu, 8 May 2003 14:27:55 -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 OAA02347 for ; Thu, 8 May 2003 14:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dpzl-0004ss-00 for rddp@ietf.org; Thu, 08 May 2003 14:19:53 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19Dpzl-0004sj-00 for rddp@ietf.org; Thu, 08 May 2003 14:19:53 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 3DE5AD3B3; Thu, 8 May 2003 11:20:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1BB93217D3; Thu, 8 May 2003 11:20:04 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 2003 11:20:01 -0700 From: "Somesh Gupta" Importance: Normal In-reply-to: Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 02086-3EC49AC7; Thu, 08 May 2003 11:19:48 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id 8A0A321911; Thu, 8 May 2003 11:19:48 -0700 (PDT) Subject: RE: [rddp] Optional CRC: Proposed Compromise To: "Caitlin Bestler" , X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think it is safe to assume that there is a negotiation phase of some kind in our future. As far as advantages/disadvantages are concerned - there are both. An addition vector to be allocate/pinned/deallocated etc is additional cost. On receive side with plain TOE, it pollutes the data stream. > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, May 08, 2003 11:02 AM > To: rddp@ietf.org > Cc: Somesh Gupta > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > On 5/8/03, Somesh Gupta wrote: > > >I don't think the CRC field should be present if not in use > >(It does make sense to have it be present or absent in both > >directions at the same time). > > Having the field always be present simplifies startup. > > If the CRC field is always present, a sender could transmit > the MPA mode frame and the first data frame with a valid > CRC. A valid CRC is acceptable to the other side whether > it support CRC suppression or not. > > If the CRC field were to be omitted, not merely voided, > neither side could transmit the first data frame until > after receiving the other's mode frame. That would delay > the start of productive data transfer. > > Always having the CRC field present will also simplify > coding. There will be fewer places where the mode will > have to be checked. > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 14:38:36 2003 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 OAA03003 for ; Thu, 8 May 2003 14:38:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48ImBg07015 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 14:48: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 h48ImA807005 for ; Thu, 8 May 2003 14:48: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 OAA02952 for ; Thu, 8 May 2003 14:38:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DqJM-0004yW-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:40:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DqJL-0004yT-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:40:07 -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 h48Il6806935; Thu, 8 May 2003 14:47:06 -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 h48Ikx806916 for ; Thu, 8 May 2003 14:46:59 -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 OAA02901 for ; Thu, 8 May 2003 14:36:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DqID-0004xy-00 for rddp@ietf.org; Thu, 08 May 2003 14:38:57 -0400 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 19DqIB-0004xu-00 for rddp@ietf.org; Thu, 08 May 2003 14:38:56 -0400 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.105.250.94]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 5198E4176; Thu, 8 May 2003 11:39:20 -0700 (PDT) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.244]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 11:39:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rddp] Optional CRC: Proposed Compromise Date: Thu, 8 May 2003 13:39:19 -0500 Message-ID: <717252EC3E37AE4392E2614EA24E9F2B04DF15A4@txnexc01.americas.cpqcorp.net> Thread-Topic: [rddp] Optional CRC: Proposed Compromise Thread-Index: AcMVjOC9ZTcC+WnVQ1uUVgKpQwLbvwAAp7Gw From: "Teisberg, Robert" To: "Caitlin Bestler" , Cc: "Somesh Gupta" X-OriginalArrivalTime: 08 May 2003 18:39:20.0126 (UTC) FILETIME=[232F75E0:01C31591] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48Ikx806917 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit What Caitlin said, and "simplify[ing] coding" applies even more strongly to hardware implementations than to software. Somesh, apart from increasing payload space per FPDU by 4 octets, what is the benefit of eliminating an unused CRC field? I can't think of any, and I don't find a 4 octet saving very compelling, especially in light of the considerations Caitlin brings up. > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, May 08, 2003 1:02 PM > To: rddp@ietf.org > Cc: Somesh Gupta > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > On 5/8/03, Somesh Gupta wrote: > > >I don't think the CRC field should be present if not in use (It does > >make sense to have it be present or absent in both directions at the > >same time). > > Having the field always be present simplifies startup. > > If the CRC field is always present, a sender could transmit > the MPA mode frame and the first data frame with a valid > CRC. A valid CRC is acceptable to the other side whether > it support CRC suppression or not. > > If the CRC field were to be omitted, not merely voided, > neither side could transmit the first data frame until > after receiving the other's mode frame. That would delay > the start of productive data transfer. > > Always having the CRC field present will also simplify > coding. There will be fewer places where the mode will > have to be checked. > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 14:43:19 2003 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 OAA03139 for ; Thu, 8 May 2003 14:43:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48Iqs607280 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 14:52:54 -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 h48Iqr807277 for ; Thu, 8 May 2003 14:52:53 -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 OAA03130 for ; Thu, 8 May 2003 14:42:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DqNv-00050u-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:44:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DqNu-00050r-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:44:50 -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 h48ImT807077; Thu, 8 May 2003 14:48:29 -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 h48Ilg806962 for ; Thu, 8 May 2003 14:47:42 -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 OAA02926 for ; Thu, 8 May 2003 14:37:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DqIt-0004yI-00 for rddp@ietf.org; Thu, 08 May 2003 14:39:39 -0400 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 19DqIt-0004y8-00 for rddp@ietf.org; Thu, 08 May 2003 14:39:39 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 92AE524488B; Thu, 8 May 2003 14:40:24 -0400 (EDT) Date: Thu, 8 May 2003 13:40:14 -0500 From: Caitlin Bestler To: Somesh Gupta Cc: rddp@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Subject: [rddp] MPA Mode Exchange (Was re Proposed Compromise) 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/8/03, Somesh Gupta wrote: >I think it is safe to assume that there is a negotiation >phase of some kind in our future. > I would be opposed to any MPA modification that prevents immediate sending of DDP Segments. RDMA is applicable to a wide variety of protocols to fetch public resources "on demand", such as HTTP. We cannot assume that all RDMA applications are predicated with a session setup phase where client and server both authenticate themselves. How much validation/handshaking is required is dependent on the ULP, and should remain there to the greatest extent that is possible. All of the options that have been proposed fit within a single "MPA Mode frame" that would be the first frame sent in MPA mode. With packing, another MPA frame containing a DDP Segment could follow within the same TCP segment. My enumeration includes the following contents for the MPA Mode frame: -- Some sort of signature that makes it unlikely for non-MPA traffic to be mistaken for this frame. Actually just having a CRC on this frame would be a fairly good way to do that, but a straight- forward signature may be enough. -- Receiver Marker Mode preferred. -- Whether the alternate mode will be accepted. -- Sender's preferred Marker Mode. -- Supports CRC voiding on send. -- Supports CRC voiding on receive. Such a definition supports immediate transmission of the first DDP Segment even before receipt of the partner's MPA Mode frame. A "quick sender" should be confident that the other end will accept the "Sender's Preferred Marker Mode". If wrong the connection will be torn down, and any speculative transmissions will have been wasted. Unless very confident the sender SHOULD NOT send extra TCP segments before confirming the peer's acceptable Marker Modes. Before receiving confirmation that the peer will work in voided CRC mode, and frames sent MUST have a valid CRC. If in fact voided CRC mode is acceptable to both ends these CRCs will simply not be checked upon receipt. All of this can be accomplished without requiring a round-trip delay. I am not aware of any other options that have even been discussed which would require such a delay. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 14:53:22 2003 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 OAA03401 for ; Thu, 8 May 2003 14:53:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48J2vP07908 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 15:02:57 -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 h48J2v807905 for ; Thu, 8 May 2003 15:02:57 -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 OAA03374 for ; Thu, 8 May 2003 14:52:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DqXf-000540-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:54:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DqXe-00053w-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 14:54:54 -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 h48J21807845; Thu, 8 May 2003 15:02:01 -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 h48J1D807771 for ; Thu, 8 May 2003 15:01:13 -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 OAA03323 for ; Thu, 8 May 2003 14:51:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DqVy-00053C-00 for rddp@ietf.org; Thu, 08 May 2003 14:53:10 -0400 Received: from zcamail03.zca.compaq.com ([161.114.32.103]) by ietf-mx with esmtp (Exim 4.12) id 19DqVy-000539-00 for rddp@ietf.org; Thu, 08 May 2003 14:53:10 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.105.250.119]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id CC78A824D; Thu, 8 May 2003 11:53:34 -0700 (PDT) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.244]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 11:53:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rddp] Optional CRC: Proposed Compromise Date: Thu, 8 May 2003 13:53:32 -0500 Message-ID: <717252EC3E37AE4392E2614EA24E9F2B04DF15B2@txnexc01.americas.cpqcorp.net> Thread-Topic: [rddp] Optional CRC: Proposed Compromise Thread-Index: AcMVj8EF0XJeU0OaTQCLd3YCkruTIwAAZfNw From: "Teisberg, Robert" To: "Somesh Gupta" , "Caitlin Bestler" , X-OriginalArrivalTime: 08 May 2003 18:53:33.0593 (UTC) FILETIME=[1FE43090:01C31593] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48J1D807772 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Thursday, May 08, 2003 1:20 PM > To: Caitlin Bestler; rddp@ietf.org > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > I think it is safe to assume that there is a negotiation > phase of some kind in our future. This seems premature. Let's be careful about self-fulfilling prophecies. > > As far as advantages/disadvantages are concerned - there > are both. An addition vector to be > allocate/pinned/deallocated etc is additional cost. I don't see this. Care to elaborate? > On > receive side with plain TOE, it pollutes the data stream. > > How so? If 4 extra octets at the end of an FPDU are a problem, just think of them as 4 extra octets preceding the next MPA header. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 16:48:41 2003 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 QAA10333 for ; Thu, 8 May 2003 16:48:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48KwJb17618 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 16:58:19 -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 h48KwJ817615 for ; Thu, 8 May 2003 16:58:19 -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 QAA10294 for ; Thu, 8 May 2003 16:48:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DsLG-0006O1-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 16:50:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DsLF-0006Ny-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 16:50:13 -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 h48Kv9817515; Thu, 8 May 2003 16:57:09 -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 h48Kum817477 for ; Thu, 8 May 2003 16:56:48 -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 QAA10215 for ; Thu, 8 May 2003 16:46:40 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DsJn-0006NI-00 for rddp@ietf.org; Thu, 08 May 2003 16:48:43 -0400 Received: from unk-for-smtp.isus.emc.com ([128.222.32.10] helo=mxic1.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 19DsJn-0006N1-00 for rddp@ietf.org; Thu, 08 May 2003 16:48:43 -0400 Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 May 2003 16:49:08 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CBE9@corpmx14.corp.emc.com> To: rddp@ietf.org Date: Thu, 8 May 2003 16:42:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rddp] Marker Consensus 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Many thanks to those who have commented. I see RDDP WG rough consensus for: Make marker usage OPTIONAL, but put control of this option entirely in the hands of the receiver - senders MUST implement both markers and not-markers, receivers MUST implement one OR the other, and each receiver gets to pick which one is used as the benefits of markers are primarily on the receiver side. With the following additions: - When markers are used, the marker interval MUST be 512 bytes. - This proposed rough consensus assumes that we will be forced to do some sort of setup announcement as part of the "proof" requirement, which will provide a place to transmit options (and a version number). Details of exactly how this works so that each receiver gets to pick what is sent to it are TBD. Any further disagreements should be posted to the list. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 17:19:20 2003 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 RAA11757 for ; Thu, 8 May 2003 17:19:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48LSwM21163 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 17:28:58 -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 h48LSw821160 for ; Thu, 8 May 2003 17:28:58 -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 RAA11738 for ; Thu, 8 May 2003 17:18:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dsov-0006gA-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 17:20:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dsou-0006g7-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 17:20:52 -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 h48LS8821081; Thu, 8 May 2003 17:28:08 -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 h48LKm820674 for ; Thu, 8 May 2003 17:20:48 -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 RAA11397 for ; Thu, 8 May 2003 17:10:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dsh1-0006dJ-00 for rddp@ietf.org; Thu, 08 May 2003 17:12:43 -0400 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 19Dsh0-0006cx-00 for rddp@ietf.org; Thu, 08 May 2003 17:12:42 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id BC5422450D3 for ; Thu, 8 May 2003 17:13:23 -0400 (EDT) Date: Thu, 8 May 2003 16:13:12 -0500 From: Caitlin Bestler Subject: Re: [rddp] Marker Consensus To: rddp@ietf.org X-Priority: 3 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CBE9@corpmx14.corp.emc.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/8/03, Black_David@emc.com wrote: >With the following additions: > >- When markers are used, the marker interval MUST be 512 bytes. >- This proposed rough consensus assumes that we will be forced > to do some sort of setup announcement as part of the > "proof" requirement, which will provide a place to > transmit options (and a version number). Oops, forgot the version number in my earlier list on what has to go into the MPA Mode Frame. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 17:19:21 2003 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 RAA11771 for ; Thu, 8 May 2003 17:19:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48LT0Y21186 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 17:29:00 -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 h48LT0821181 for ; Thu, 8 May 2003 17:29:00 -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 RAA11742 for ; Thu, 8 May 2003 17:18:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dsow-0006gG-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 17:20:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dsow-0006gD-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 17:20:54 -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 h48LSA821109; Thu, 8 May 2003 17:28:10 -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 h48LOk820855 for ; Thu, 8 May 2003 17:24:46 -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 RAA11555 for ; Thu, 8 May 2003 17:14:37 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dskq-0006er-00 for rddp@ietf.org; Thu, 08 May 2003 17:16:40 -0400 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by ietf-mx with esmtp (Exim 4.12) id 19Dskq-0006eo-00 for rddp@ietf.org; Thu, 08 May 2003 17:16:40 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 May 2003 17:17:01 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CBEA@corpmx14.corp.emc.com> To: rddp@ietf.org Date: Thu, 8 May 2003 17:10:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rddp] Negotiation: Warning 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , We seem to have a problem on the list in that some people use the term "negotiation" to broadly include any mechanism that provides any check on configuration (e.g., the SCTP adaption indication would be "negotiation" under this definition) and others use the term only for mechanisms that always lead to successful agreement and continuation of a connection, with the consequence that an extra round-trip or part thereof is generally required (e.g., the SCTP adaption indication would not be "negotiation" under this definition, as it's purely declarative - "I'm doing this"). I'd advise people using the term "negotiation" to be precise about which of these two meanings they intend to avoid future confusion, as there are strong objections in the WG to anything that requires an extra round-trip or part thereof (delay to send beyond initial TCP handshake). I believe that we will wind up with at least some sort of declarative mechanism for RDDP over TCP in order to deal with the "proof" requirement (both ends of a connection are using RDDP or both ends are not, but a mixture cannot happen), but I see strong interest in the WG that any such mechanism not require any additional delays in sending data at the start of a connection. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 17:30:08 2003 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 RAA12062 for ; Thu, 8 May 2003 17:30:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48Ldle22632 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 17:39:47 -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 h48Ldk822629 for ; Thu, 8 May 2003 17:39:46 -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 RAA12047 for ; Thu, 8 May 2003 17:29:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DszN-0006k2-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 17:31:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DszM-0006jz-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 17:31:40 -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 h48Ld1822588; Thu, 8 May 2003 17:39:01 -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 h48Lck822566 for ; Thu, 8 May 2003 17:38:46 -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 RAA12029 for ; Thu, 8 May 2003 17:28:37 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DsyO-0006jX-00 for rddp@ietf.org; Thu, 08 May 2003 17:30:40 -0400 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by ietf-mx with esmtp (Exim 4.12) id 19DsyO-0006jD-00 for rddp@ietf.org; Thu, 08 May 2003 17:30:40 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 May 2003 17:31:05 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CBEB@corpmx14.corp.emc.com> To: rddp@ietf.org Date: Thu, 8 May 2003 17:24:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rddp] CRC - partial rough consensus 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , The CRC discussion does not seem to be finished, but I'd like to try to nail down some of the progress that has been made. I believe that there is RDDP WG rough consensus for: (A) CRC support MUST be implemented. I'm going to refrain from calling consensus on "OPTIONAL vs. MANDATORY to use" at this time (although I think the discussion has focused on the key issue of the level of service a ULP using RDDP over TCP should expect). Nonetheless, *if* CRC usage is optional I believe that there is WG rough consensus for: (B) CRC usage is all-or-nothing on header and data. There is no requirement for CRC on header but not on data or CRC on data but not on header. NB: This does not imply that there is a single CRC vs. split header and data CRCs, as there are some additional issues bearing on this. (C) CRC usage is bidirectional. Either CRCs are used in both directions on a connection, or in neither. There is no requirement for CRC usage in one direction and not the other. (D) CRC omission requires consent of both ends of the connection. If either end of the connection specifies that CRCs are to be used, then they MUST be used [in both directions (C)]. This entails some sort of mechanism to enforce CRC usage when the two ends of the connection start out with different preferences (or break the connection if the different preference have created a situation from which it is impossible to continue). I'm also going to refrain from calling consensus on whether the CRC field is present if CRC is not used - that seems like an issue that ought to be taken up after the requirements are settled. Objections to the above four items of rough consensus should be posted to the list. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 17:59:15 2003 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 RAA12940 for ; Thu, 8 May 2003 17:59:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48M8tM25021 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 18:08:55 -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 h48M8t825018 for ; Thu, 8 May 2003 18:08:55 -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 RAA12937 for ; Thu, 8 May 2003 17:58:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtRZ-0006wf-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:00:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DtRY-0006wc-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:00:48 -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 h48M89824915; Thu, 8 May 2003 18:08:09 -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 h48M7C824134 for ; Thu, 8 May 2003 18:07:12 -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 RAA12797 for ; Thu, 8 May 2003 17:57:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtPt-0006uB-00 for rddp@ietf.org; Thu, 08 May 2003 17:59:05 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19DtPs-0006tr-00 for rddp@ietf.org; Thu, 08 May 2003 17:59:05 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 64A30D46A; Thu, 8 May 2003 14:59:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4BDA521A69; Thu, 8 May 2003 14:59:16 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 8 May 2003 14:59:14 -0700 From: "Somesh Gupta" Importance: Normal In-reply-to: <277DD60FB639D511AC0400B0D068B71E0564CBEB@corpmx14.corp.emc.com> Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 10898-4E46E9A9; Thu, 08 May 2003 14:59:01 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id 34A642191F; Thu, 8 May 2003 14:59:01 -0700 (PDT) Subject: RE: [rddp] CRC - partial rough consensus To: , X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, I am not quite sure about the range of apps RDMA is intended for, but Caitlin mentioned accessing web content. It seems possible that if streaming media is one of the apps, it may be acceptable to not have CRC on data, while requiring CRC on the header?? Somesh > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > Black_David@emc.com > Sent: Thursday, May 08, 2003 2:25 PM > To: rddp@ietf.org > Subject: [rddp] CRC - partial rough consensus > > > The CRC discussion does not seem to be finished, but > I'd like to try to nail down some of the progress that > has been made. I believe that there is RDDP WG rough > consensus for: > > (A) CRC support MUST be implemented. > > I'm going to refrain from calling consensus on > "OPTIONAL vs. MANDATORY to use" at this time (although I > think the discussion has focused on the key issue of the > level of service a ULP using RDDP over TCP should expect). > > Nonetheless, *if* CRC usage is optional I believe that > there is WG rough consensus for: > > (B) CRC usage is all-or-nothing on header and data. > There is no requirement for CRC on header but > not on data or CRC on data but not on header. > > NB: This does not imply that there is a single CRC > vs. split header and data CRCs, as there are some > additional issues bearing on this. > > (C) CRC usage is bidirectional. Either CRCs are used > in both directions on a connection, or in neither. > There is no requirement for CRC usage in one > direction and not the other. > > (D) CRC omission requires consent of both ends of the > connection. If either end of the connection > specifies that CRCs are to be used, then they > MUST be used [in both directions (C)]. This entails > some sort of mechanism to enforce CRC usage when > the two ends of the connection start out with > different preferences (or break the connection > if the different preference have created a > situation from which it is impossible to continue). > > I'm also going to refrain from calling consensus on whether > the CRC field is present if CRC is not used - that seems > like an issue that ought to be taken up after the > requirements are settled. > > Objections to the above four items of rough consensus should > be posted to the list. > > Thanks, > --David > > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 18:00:22 2003 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 SAA13001 for ; Thu, 8 May 2003 18:00:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48MA1Z25130 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 18:10:01 -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 h48MA1825127 for ; Thu, 8 May 2003 18:10:01 -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 RAA12966 for ; Thu, 8 May 2003 17:59:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtSd-0006xD-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:01:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DtSc-0006xA-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:01:54 -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 h48M92825061; Thu, 8 May 2003 18:09:02 -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 h48M8i825005 for ; Thu, 8 May 2003 18:08:44 -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 RAA12903 for ; Thu, 8 May 2003 17:58:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtRO-0006wD-00 for rddp@ietf.org; Thu, 08 May 2003 18:00:38 -0400 Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx with esmtp (Exim 4.12) id 19DtRN-0006vd-00 for rddp@ietf.org; Thu, 08 May 2003 18:00:37 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 639599B70; Thu, 8 May 2003 17:00:56 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 17:00:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] Optional CRC: Proposed Compromise Date: Thu, 8 May 2003 17:00:55 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F87240314317B@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] Optional CRC: Proposed Compromise Thread-Index: AcMVicdBgnFaJqJ1Qi61XoJ5PWTcLgAHuKCw From: "Barron, Dwight" To: "Somesh Gupta" , X-OriginalArrivalTime: 08 May 2003 22:00:56.0182 (UTC) FILETIME=[4CFF2160:01C315AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48M8i825006 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I believe the ability of to use IPSEC as a substitute for E2E CRC is not an acceptable tradeoff for the following reasons: 1) there is no architectural method to discover which streams are actually using IPSEC at the RDDP/MPA layers. In a previous posting, Somesh stated "There is always an administration/config plane to any and all apps" which I consider to be an implementation specific knob for the administrator to twist and is not a candidate for becoming an architected interface at the RDDP/MPA layers. 2) the decision to implement IPSEC for free in silicon does not appear to be pervasive in the industry just yet, and is further gated by the deployment of sufficient management infrastructure to actually use the IPSEC mechanisms. No additional infrastructure is needed to use CRCs. 3) Valid and popular topologies remove the IPSEC engine one or more links from the end node, so it is not a true end-end protection 4) While I believe layering an E2E CRC above TCP at the MPA layer will in fact help detect and diagnose latent faults in the TCP/checksum layer, if it is layered below TCP, as in IPSEC, I agree with Somesh' earlier comment, it will only encapsulate and deliver the latent TCP faults Regards, Dwight > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Thursday, May 08, 2003 12:38 PM > To: rddp@ietf.org > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > I don't think the CRC field should be present if not in use > (It does make sense to have it be present or absent in both > directions at the same time). > > There are fairly reasonable scenarios that make it completely > not useful (to be PC here). A combination of IPSec offload that > is likely to become common and free (part of the NIC cost) combined > with the first hack of an iSCSI based storage server is likely to > make IPSec a must have for authentication. This will take care > of worries about integrity as well as resegmenting middle boxes. > > As always caveats etc. for something not here. > > Somesh > > > -----Original Message----- > > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > > Barron, Dwight > > Sent: Wednesday, May 07, 2003 11:03 AM > > To: Williams, Jim; rddp@ietf.org > > Subject: RE: [rddp] Optional CRC: Proposed Compromise > > > > > > Jim, would provide comments on the acceptability of the following > > clarification points (aka fine print)? > > > > - The CRC option always applies to both directions of a connection > > - The CRC field is always present, but sometimes may not be valid > > - The disposition of the CRC option is never made available > to the ULP > > > > This last item probably deserves some explanation. One of the > > reasons that I want CRCs mandatory is to stop the proliferation > > of "sufficient" transport error checking up to the ULP. I believe > > that one of the reasons you want CRCs optional is that you deem > > link CRC+TCP checksum "sufficient." In both cases, I don't > > believe either of us are proposing that the ULP take > additional measures. > > > > Regards, > > Dwight > > > > > -----Original Message----- > > > From: Williams, Jim [mailto:Jim.Williams@emulex.com] > > > Sent: Wednesday, May 07, 2003 12:40 PM > > > To: rddp@ietf.org > > > Subject: [rddp] Optional CRC: Proposed Compromise > > > > > > > > > I would like to throw out the following > > > proposed compromise position. I will > > > withdraw it if there is strong opposition > > > from either side of this discussion. > > > > > > CRC is optional. If used, CRC coverage > > > must include both header and payload. > > > CRC MUST be used unless BOTH ends of a > > > connection opt to not use it. > > > An implementation MAY choose to > > > always require CRC and therefore > > > not implement non-CRC mode. > > > (I.e. optional CRCs are optional > > > to implement, with the default > > > being to use CRCs.) > > > > > > If both ends opt to not use CRCs, > > > then neither header or payload > > > will be covered by CRC. > > > > > > I believe this is totally transparent > > > and painless to implementers that want > > > to always use CRCs. But it doesn't > > > preclude other vendors that think > > > there might be a subset of the market > > > that could benefit from software > > > implementations not using CRCs. > > > > > > My intent is NOT to address the question > > > of whether header and payload are > > > covered by the same CRC or different. > > > That is a separate discussion. > > > > > > > > > _______________________________________________ > > > rddp mailing list > > > rddp@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rddp > > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 18:08:29 2003 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 SAA13769 for ; Thu, 8 May 2003 18:08:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48MI6R25529 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 18:18:06 -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 h48MI6825526 for ; Thu, 8 May 2003 18:18:06 -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 SAA13696 for ; Thu, 8 May 2003 18:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtaS-000712-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:10:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DtaR-00070z-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:09:59 -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 h48MH1825421; Thu, 8 May 2003 18:17:01 -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 h48MEM825282 for ; Thu, 8 May 2003 18:14:22 -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 SAA13221 for ; Thu, 8 May 2003 18:04:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtWp-0006yc-00 for rddp@ietf.org; Thu, 08 May 2003 18:06:15 -0400 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 19DtWp-0006yM-00 for rddp@ietf.org; Thu, 08 May 2003 18:06:15 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id E6D312456E8; Thu, 8 May 2003 18:06:53 -0400 (EDT) Date: Thu, 8 May 2003 17:06:41 -0500 From: Caitlin Bestler Subject: RE: [rddp] CRC - partial rough consensus To: Somesh Gupta , rddp@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/8/03, Somesh Gupta wrote: >I am not quite sure about the range of apps RDMA is >intended for, but Caitlin mentioned accessing web content. > >It seems possible that if streaming media is one of >the apps, it may be acceptable to not have CRC on data, >while requiring CRC on the header?? Streaming Media could indeed use RDMA, but would definitely prefer an unreliable or partially reliable transport. Randall's proposed PR-SCTP would serve as an excellent transport. DCP would also work. Discussions on whether RDMA inherently requires flow control (and hence not UDP) can be dealt with when we are through with reliable services. In that context omission of payload protection may be appropriate, or in the flip direction use of FEC might be just as valid of an option. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 18:09:29 2003 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 SAA13862 for ; Thu, 8 May 2003 18:09:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48MJ7u25604 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 18:19:07 -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 h48MJ7825601 for ; Thu, 8 May 2003 18:19:07 -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 SAA13827 for ; Thu, 8 May 2003 18:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtbR-00071a-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:11:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DtbQ-00071X-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:11:00 -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 h48MI1825510; Thu, 8 May 2003 18:18:01 -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 h48MHQ825463 for ; Thu, 8 May 2003 18:17:26 -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 SAA13621 for ; Thu, 8 May 2003 18:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtZo-00070V-00 for rddp@ietf.org; Thu, 08 May 2003 18:09:20 -0400 Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx with esmtp (Exim 4.12) id 19DtZn-000701-00 for rddp@ietf.org; Thu, 08 May 2003 18:09:19 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 6E7ED9916; Thu, 8 May 2003 17:09:44 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 17:09:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] CRC - partial rough consensus Date: Thu, 8 May 2003 17:09:43 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F87240314317C@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] CRC - partial rough consensus Thread-Index: AcMVqkZgko7Tcg7pSNqqm6rn7svrcwAA8bJw From: "Barron, Dwight" To: , X-OriginalArrivalTime: 08 May 2003 22:09:44.0240 (UTC) FILETIME=[87BE6300:01C315AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48MHQ825464 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit There was also some discussion around *if* CRC usage is optional it should be specified in a manner that does not compel ULPs to compensate with their own CRC. Regards, Dwight > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Thursday, May 08, 2003 4:25 PM > To: rddp@ietf.org > Subject: [rddp] CRC - partial rough consensus > > > The CRC discussion does not seem to be finished, but > I'd like to try to nail down some of the progress that > has been made. I believe that there is RDDP WG rough > consensus for: > > (A) CRC support MUST be implemented. > > I'm going to refrain from calling consensus on > "OPTIONAL vs. MANDATORY to use" at this time (although I > think the discussion has focused on the key issue of the > level of service a ULP using RDDP over TCP should expect). > > Nonetheless, *if* CRC usage is optional I believe that > there is WG rough consensus for: > > (B) CRC usage is all-or-nothing on header and data. > There is no requirement for CRC on header but > not on data or CRC on data but not on header. > > NB: This does not imply that there is a single CRC > vs. split header and data CRCs, as there are some > additional issues bearing on this. > > (C) CRC usage is bidirectional. Either CRCs are used > in both directions on a connection, or in neither. > There is no requirement for CRC usage in one > direction and not the other. > > (D) CRC omission requires consent of both ends of the > connection. If either end of the connection > specifies that CRCs are to be used, then they > MUST be used [in both directions (C)]. This entails > some sort of mechanism to enforce CRC usage when > the two ends of the connection start out with > different preferences (or break the connection > if the different preference have created a > situation from which it is impossible to continue). > > I'm also going to refrain from calling consensus on whether > the CRC field is present if CRC is not used - that seems > like an issue that ought to be taken up after the > requirements are settled. > > Objections to the above four items of rough consensus should > be posted to the list. > > Thanks, > --David > > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 8 18:10:22 2003 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 SAA13954 for ; Thu, 8 May 2003 18:10:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48MK0n25649 for rddp-archive@odin.ietf.org; Thu, 8 May 2003 18:20:00 -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 h48MJx825646 for ; Thu, 8 May 2003 18:19:59 -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 SAA13905 for ; Thu, 8 May 2003 18:09:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtcH-00071m-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:11:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DtcG-00071j-00 for rddp-web-archive@ietf.org; Thu, 08 May 2003 18:11:52 -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 h48MJ1825581; Thu, 8 May 2003 18:19:01 -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 h48MI3825522 for ; Thu, 8 May 2003 18:18:03 -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 SAA13689 for ; Thu, 8 May 2003 18:07:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtaO-00070w-00 for rddp@ietf.org; Thu, 08 May 2003 18:09:56 -0400 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 19DtaO-00070e-00 for rddp@ietf.org; Thu, 08 May 2003 18:09:56 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id D79A624536E; Thu, 8 May 2003 18:10:36 -0400 (EDT) Date: Thu, 8 May 2003 17:10:25 -0500 From: Caitlin Bestler Subject: Re: [rddp] CRC - partial rough consensus To: Black_David@emc.com, rddp@ietf.org X-Priority: 3 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CBEB@corpmx14.corp.emc.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/8/03, Black_David@emc.com wrote: > >(C) CRC usage is bidirectional. Either CRCs are used > in both directions on a connection, or in neither. > There is no requirement for CRC usage in one > direction and not the other. > I have no objection to this, but I am not certain as to the benefit of it. Philosophically, I don't see why my decision to require error protection on buffers sent to my memory should be binding on my peer. The only real benefit I can see is reducing two option bits to one. But realistically, the specialized deployments and applications where voiding the CRC would make sense are likely to be symmetrical anyway. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 9 16:35:41 2003 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 QAA01082 for ; Fri, 9 May 2003 16:35:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49Kjlk11256 for rddp-archive@odin.ietf.org; Fri, 9 May 2003 16:45:47 -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 h49Kjl811253 for ; Fri, 9 May 2003 16:45:47 -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 QAA01065 for ; Fri, 9 May 2003 16:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEcC-0007F9-00 for rddp-web-archive@ietf.org; Fri, 09 May 2003 16:37:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EEcB-0007F5-00 for rddp-web-archive@ietf.org; Fri, 09 May 2003 16:37:11 -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 h49KiF811160; Fri, 9 May 2003 16:44:15 -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 h49Khn811124 for ; Fri, 9 May 2003 16:43:49 -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 QAA00922 for ; Fri, 9 May 2003 16:33:12 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEaI-0007ED-00 for rddp@ietf.org; Fri, 09 May 2003 16:35:14 -0400 Received: from mxic2.corp.emc.com ([128.221.31.40]) by ietf-mx with esmtp (Exim 4.12) id 19EEaH-0007E1-00 for rddp@ietf.org; Fri, 09 May 2003 16:35:13 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 May 2003 16:35:38 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CBFA@corpmx14.corp.emc.com> To: cait@asomi.com, rddp@ietf.org Subject: RE: [rddp] CRC - partial rough consensus Date: Fri, 9 May 2003 16:29:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , I think this conflates two sense of "reliable": - Data is delivered to receiver in the face of drops/errors/etc. [Caitlin's discussion of unreliable transports like PR-SCTP] - Data integrity is preserved (what is received is what is sent). [Somesh's question about no CRC on data - note that PR-SCTP uses a CRC on data] While I'm not an expert, I would hazard a guess that the degree of compression used in bandwidth- optimized codecs makes transmission errors rather unwelcome when they are used for streaming media. At least for that sort of codec, the argument that concerns about errors in header are usually accompanied by concerns about errors in data would appear to apply. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, May 08, 2003 6:07 PM > To: Somesh Gupta; rddp@ietf.org > Subject: RE: [rddp] CRC - partial rough consensus > > > On 5/8/03, Somesh Gupta wrote: > > >I am not quite sure about the range of apps RDMA is > >intended for, but Caitlin mentioned accessing web content. > > > >It seems possible that if streaming media is one of > >the apps, it may be acceptable to not have CRC on data, > >while requiring CRC on the header?? > > Streaming Media could indeed use RDMA, but would definitely > prefer an unreliable or partially reliable transport. > Randall's proposed PR-SCTP would serve as an excellent > transport. DCP would also work. Discussions on whether > RDMA inherently requires flow control (and hence not UDP) > can be dealt with when we are through with reliable > services. In that context omission of payload protection > may be appropriate, or in the flip direction use of FEC > might be just as valid of an option. > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 9 16:51:01 2003 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 QAA01758 for ; Fri, 9 May 2003 16:51:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49L18o12800 for rddp-archive@odin.ietf.org; Fri, 9 May 2003 17:01:08 -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 h49L18812797 for ; Fri, 9 May 2003 17:01:08 -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 QAA01748 for ; Fri, 9 May 2003 16:50:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEr3-0007OI-00 for rddp-web-archive@ietf.org; Fri, 09 May 2003 16:52:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EEr2-0007OF-00 for rddp-web-archive@ietf.org; Fri, 09 May 2003 16:52:32 -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 h49L05812321; Fri, 9 May 2003 17:00:05 -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 h49Kxe812146 for ; Fri, 9 May 2003 16:59:40 -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 QAA01572 for ; Fri, 9 May 2003 16:49:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEpd-0007Ka-00 for rddp@ietf.org; Fri, 09 May 2003 16:51:05 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19EEpc-0007K4-00 for rddp@ietf.org; Fri, 09 May 2003 16:51:04 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 8D0E1244E8D; Fri, 9 May 2003 16:51:50 -0400 (EDT) Date: Fri, 9 May 2003 15:51:43 -0500 From: Caitlin Bestler Subject: RE: [rddp] CRC - partial rough consensus To: Black_David@emc.com, rddp@ietf.org X-Priority: 3 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CBFA@corpmx14.corp.emc.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/9/03, Black_David@emc.com wrote: >I think this conflates two sense of "reliable": > >- Data is delivered to receiver in the face of > drops/errors/etc. [Caitlin's discussion of > unreliable transports like PR-SCTP] >- Data integrity is preserved (what is received > is what is sent). [Somesh's question about > no CRC on data - note that PR-SCTP uses a > CRC on data] > >While I'm not an expert, I would hazard a guess >that the degree of compression used in bandwidth- >optimized codecs makes transmission errors rather >unwelcome when they are used for streaming media. >At least for that sort of codec, the argument that >concerns about errors in header are usually >accompanied by concerns about errors in data >would appear to apply. > If you are compressing for the sake of compression then any good compression will be very loss intolerant. However, most real-world compression is designed to be resilient when delivered over imperfect transports. The key is to preserve presentation order whether than to wait for retries. The most obvious examples of imperfect transports would include broadcast or cable MPEG transport, and home Internet connections that are barely fast enough even before there are any retransmits. It also includes CDs that can be scratched and/or played while somebody is jogging. Whether or not a retransmit or reread is feasible, you can't *stop* the presentation to fetch it without being very obvious about it. Fuzzing the audio a bit works much better. One common technique is to spread the data for any one time period over a longer time period. That way a loss of one packet degrades the picture/audio slightly for a longer period of time rather than totally wiping it out for a short period. Anyway, this is mostly off topic. The point is that there are applications that engage in bulk data transfer that can tolerate *loss* of data. They are, however, very sensitive to *false* data delivery. All MPEG (or related) decoders include logic to conceal errors, but they have to know that there was an error. If you examine transports designed for this environment, such as MPEG Transport, you will see that they have strong protection against false delivery of data. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 9 21:56:40 2003 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 VAA09528 for ; Fri, 9 May 2003 21:56:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4A26ro01517 for rddp-archive@odin.ietf.org; Fri, 9 May 2003 22:06:53 -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 h4A26r801514 for ; Fri, 9 May 2003 22:06:53 -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 VAA09525 for ; Fri, 9 May 2003 21:56:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EJcp-0001Ao-00 for rddp-web-archive@ietf.org; Fri, 09 May 2003 21:58:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EJco-0001Al-00 for rddp-web-archive@ietf.org; Fri, 09 May 2003 21:58:10 -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 h4A26D801496; Fri, 9 May 2003 22:06:13 -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 h4A259801478 for ; Fri, 9 May 2003 22:05:09 -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 VAA09521 for ; Fri, 9 May 2003 21:54:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EJb9-0001Ai-00 for rddp@ietf.org; Fri, 09 May 2003 21:56:27 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19EJb8-0001Af-00 for rddp@ietf.org; Fri, 09 May 2003 21:56:26 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 9A924245381 for ; Fri, 9 May 2003 21:57:14 -0400 (EDT) Date: Fri, 9 May 2003 20:57:08 -0500 From: Caitlin Bestler To: rddp@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Subject: [rddp] L3 Layering as Security Issue 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We've been concentrating on being cleanly layered of L4, while allowing rototilling, that I think we forgot to kick the tires on L3 layering. Specifically, expecting RNICs to enforce local in-host firewall rules would be a) difficult and b) not very useful. With all proper layering, a DDP Segment contained within an IP Datagram that the local firewall rules will drop should not result in placement to user memory let alone a valid completion. Realistically, it is highly unlikely that an IP Datagram that is part of an established TCP connection or SCTP association will not pass the firewall rules. Rather than hoping for a standard interface between RNICs and in-host firewalls I would suggest we just add a section to the security concerns section that documents that firewall rules should be drafted to prevent the TCP connection or SCTP association from being established. Once a DDP Stream is up and running it is might not be affect by an in-host firewall. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Fri May 16 10:34:33 2003 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 KAA27498 for ; Fri, 16 May 2003 10:34:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GE24l13668 for rddp-archive@odin.ietf.org; Fri, 16 May 2003 10:02:04 -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 h4GE24B13665 for ; Fri, 16 May 2003 10:02:04 -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 KAA27477 for ; Fri, 16 May 2003 10:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GgJP-00004o-00 for rddp-web-archive@ietf.org; Fri, 16 May 2003 10:35:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19GgJO-00004k-00 for rddp-web-archive@ietf.org; Fri, 16 May 2003 10:35:54 -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 h4GE1HB13601; Fri, 16 May 2003 10:01:17 -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 h4GE06B13485 for ; Fri, 16 May 2003 10:00:06 -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 KAA27433 for ; Fri, 16 May 2003 10:32:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GgHV-00003Y-00 for rddp@ietf.org; Fri, 16 May 2003 10:33:57 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 19GgHU-00003D-00 for rddp@ietf.org; Fri, 16 May 2003 10:33:56 -0400 Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.9/8.12.9/NTAP-1.4) with ESMTP id h4GEYbFB025794 for ; Fri, 16 May 2003 07:34:37 -0700 (PDT) Received: from tmt.netapp.com (tmt [10.97.1.31]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id h4GEYaXw027082 for ; Fri, 16 May 2003 07:34:36 -0700 (PDT) Message-Id: <5.2.1.1.2.20030516103220.02a83a98@silver.nane.netapp.com> Date: Fri, 16 May 2003 10:34:13 -0400 To: rddp@ietf.org From: "Talpey, Thomas" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [rddp] Fwd: [nfsv4] Resend: NFS / RPC / RDMA drafts available 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Below is an announcement of three new internet-drafts relevant to RDDP. Please be aware that the filename is incorrect for one document. The "rpcrdma" document should be named "nfsdirect". Here are the three current URLs: Discussion is in the NFSv4 WG on nfsv4@ietf.org. Tom. > ---------- Forwarded Message ---------- >Subject: [nfsv4] Resend: NFS / RPC / RDMA drafts available >Date: Fri, 16 May 2003 09:40:32 -0400 >List-Help: >List-Subscribe: >,g?subject=subscribe> >From: "Talpey, Thomas" >To: > >Three new drafts are available in the I-D directory today: > (http://www.ietf.org/ids.by.wg/none.html) > >We look forward to discussing these on the list, and at the >interim working group meeting next month! > >Apparently the URLs are slightly scrambled for two of the documents, >the first draft appears under the second's title! We'll look to clean this >up, obviously... The correctly associated URLs appear below, fixed >from my first mail. Sorry for the glitch. > >"RDMA Transport for ONC RPC", Thomas Talpey, Brent Callaghan, 15-May-03. >(11729 bytes) > >A protocol is described providing RDMA as a new transport for ONC RPC. The >RDMA transport binding conveys the benefits of efficient, bulk data >transport over high speed networks, while providing for minimal change to >RPC applications and with no required revision of the application RPC >protocol, or the RPC protocol itself. > >"NFS Direct Data Placement", Thomas Talpey, Brent Callaghan, 15-May-03. ( >bytes) > >The RDMA transport for ONC RPC supports direct data placement for NFS data. >Direct data placement not only reduces the amount of data that needs to be >copied in an NFS call, but allows much of the data movement over the network >to be implemented in RDMA hardware. This draft describes the use of direct >data placement by means of server- initiated RDMA Writes into >client-supplied buffers in a Write list for implementations of NFS versions >2, 3, and 4 over an RDMA transport. > >"NFSv4 RDMA and Session Extensions", Thomas Talpey, Spencer Shepler, >15-May-03. (111000 bytes) > >Extensions are proposed to NFS version 4 which enable it to support >sessions, connection management, and operation atop RDMA-capable RPC. These >extensions enable universal support for Exactly-once Semantics by NFSv4 >servers, enhanced security, and multipathing and trunking of transport >connections. These extensions provide identical benefit over both TCP and >RDMA connection types. > >_______________________________________________ >nfsv4 mailing list >nfsv4@ietf.org >https://www1.ietf.org/mailman/listinfo/nfsv4 > ---------- End of Forwarded Message ---------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 16:53:34 2003 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 QAA22976 for ; Wed, 28 May 2003 16:53:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SKr7h10714 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 16:53:07 -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 h4SKr7B10711 for ; Wed, 28 May 2003 16:53:07 -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 QAA22961 for ; Wed, 28 May 2003 16:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7tQ-0007eq-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 16:51:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L7tP-0007em-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 16:51:27 -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 h4SKq8B10622; Wed, 28 May 2003 16:52:08 -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 h4SKpBB10586 for ; Wed, 28 May 2003 16:51: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 QAA22861 for ; Wed, 28 May 2003 16:51:08 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7rY-0007df-00 for rddp@ietf.org; Wed, 28 May 2003 16:49:32 -0400 Received: from unk-for-smtp.isus.emc.com ([128.222.32.10] helo=mxic1.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 19L7rX-0007dR-00 for rddp@ietf.org; Wed, 28 May 2003 16:49:31 -0400 Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 May 2003 16:50:38 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CCA8@corpmx14.corp.emc.com> To: John_Carrier@adaptec.com, rddp@ietf.org Date: Fri, 23 May 2003 17:30:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rddp] CRC - issue E consensus call. 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , > I don't think this is an accurate characterization. With > CRCs done below DDP/RDMAP, there is no concept of header and > data. A single CRC covering the entire MPA payload maintains > layer separation and allows DDP/RDMAP to assume that the data > they receive from the LLP is a complete, CRC-protected > message regardless of whether the underlying transport is SCTP or TCP. > > I thought there was some concensus building towards this position. Possibly, but we're not there yet. With the exception of there being no need to support "CRC on data, no CRC on header", this issue (B) [CRC coverage] is open. With respect to my letters, I believe my prior statement that there is WG rough consensus for (A) [MUST implement], (C) [usage is bidirectional both-or-none], and (D) [either side can force CRC usage] has held up. I hereby augment that by stating that I believe that there is WG rough consensus for: (E) CRCs are OPTIONAL to use, but (per (D) above), either end of the connection can force CRC usage in both directions. augmented by: (E') CRC usage is an administrative configuration decision - it is not intended to be visible to ULPs. The rationale for (E') is a desire to avoid ULP implementations of additional integrity that is used only when the ULP detects that it is running over RDDP over TCP without CRC. I'd like to get this settled before circling back to (B} [CRC coverage] and the related well-explored "one vs. two CRCs" tarpit. So, any disagreements with (E) or (E') need to be posted to the list promptly. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 17:06:07 2003 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 RAA24017 for ; Wed, 28 May 2003 17:06:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SL5fB12262 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 17:05:41 -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 h4SL5fB12259 for ; Wed, 28 May 2003 17:05:41 -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 RAA23990 for ; Wed, 28 May 2003 17:05:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L85Z-00008k-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 17:04:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L85Y-00008h-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 17:04:00 -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 h4SL40B12175; Wed, 28 May 2003 17:04:00 -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 h4SL3JB12131 for ; Wed, 28 May 2003 17:03:19 -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 RAA23868 for ; Wed, 28 May 2003 17:03:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L83H-00006l-00 for rddp@ietf.org; Wed, 28 May 2003 17:01:39 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19L83G-00006S-00 for rddp@ietf.org; Wed, 28 May 2003 17:01:38 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id D2D7F24528C for ; Wed, 28 May 2003 17:03:12 -0400 (EDT) Date: Wed, 28 May 2003 16:02:44 -0500 From: Caitlin Bestler Subject: Re: [rddp] CRC - issue E consensus call. To: rddp@ietf.org X-Priority: 3 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CCA8@corpmx14.corp.emc.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/23/03, Black_David@emc.com wrote: >(E') CRC usage is an administrative configuration >decision - it is not intended to be visible to ULPs. I would like to refine that as follows: Administrative permission to suppress CRCs for a given connection MAY be given if the paths over which the connection will travel are known to provide the equivalent of an end-to-end CRC32c protection, or meet other criteria explicitly established for the ULP. That is, there can never be less than the equivalent of end-to-end CRC32c unless the ULP explicitly allows for this. The mechanism for doing so would be out-of-scope. I would also be comfortable with dropping the "or meet other criteria explicitly established for the ULP." clause. The important thing is that to be truly invisible to the ULP, the ULP must be able to presume that its minimum standards will be met. Further that standard is an end-to-end CRC32c by default. An ULP MAY set a lower standard, if it so desires. If a ULP wants a higher standard, it provide its own supplemental solutions. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 17:30:45 2003 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 RAA25143 for ; Wed, 28 May 2003 17:30:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SLUJ214163 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 17:30:19 -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 h4SLUJB14160 for ; Wed, 28 May 2003 17:30:19 -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 RAA25127 for ; Wed, 28 May 2003 17:30:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L8TO-0000SA-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 17:28:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L8TO-0000S7-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 17:28:38 -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 h4SLQ2B13945; Wed, 28 May 2003 17:26:02 -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 h4SLPKB13904 for ; Wed, 28 May 2003 17:25:20 -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 RAA24981 for ; Wed, 28 May 2003 17:25:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L8OZ-0000Po-00 for rddp@ietf.org; Wed, 28 May 2003 17:23:39 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 19L8OZ-0000Nv-00 for rddp@ietf.org; Wed, 28 May 2003 17:23:39 -0400 Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.9/8.12.9/NTAP-1.4) with ESMTP id h4SLOjJo025585; Wed, 28 May 2003 14:24:45 -0700 (PDT) Received: from tmt.netapp.com ([10.32.10.1]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id h4SLOjXw017433; Wed, 28 May 2003 14:24:45 -0700 (PDT) Message-Id: <5.2.1.1.2.20030528172020.00b7a0a8@silver.nane.netapp.com> Date: Wed, 28 May 2003 17:24:27 -0400 To: "John Hufferd" From: "Talpey, Thomas" Subject: RE: [rddp] CRC - rough consensus update Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , At 02:35 PM 5/28/2003, John Hufferd wrote: >So, lets propose that based on the perceived fact >that SW overhead is NOT an issue, we just say that the requirement from the >iWARP layers is to provide to the ULP protection at least as strong as that >provided by CRC32c. ... >If the above is reasonable, then since we have stated that if either side >wants it, the CRC must be sent. And if a side can not tell if it has IPSec >Encryption but the other side can and says that it does not want the CRC, >then don't generate the CRC. However, if the other side does not explicitly >say it does not want the CRC, then it should be provided. If overhead is not an issue, then what difference does it make whether the CRC is included or not? In other words, why bother to negotiate leaving it out? Just calculate it and let the receiver decide whether to pay attention. Everyone wins. This has been my point, at least. Tom. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 18:17:18 2003 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 SAA27541 for ; Wed, 28 May 2003 18:17:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SMGsW17487 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 18:16:54 -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 h4SMGsB17484 for ; Wed, 28 May 2003 18:16:54 -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 SAA27509 for ; Wed, 28 May 2003 18:16:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9CS-0000kZ-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 18:15:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L9CR-0000kW-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 18:15:11 -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 h4SMG9B17442; Wed, 28 May 2003 18:16:09 -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 h4SMFPB17393 for ; Wed, 28 May 2003 18:15:25 -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 SAA27366 for ; Wed, 28 May 2003 18:15:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9B1-0000k3-00 for rddp@ietf.org; Wed, 28 May 2003 18:13:43 -0400 Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx with esmtp (Exim 4.12) id 19L9B0-0000k0-00 for rddp@ietf.org; Wed, 28 May 2003 18:13:42 -0400 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id A2E66A6F6; Wed, 28 May 2003 17:14:45 -0500 (CDT) Received: from cceexc16.americas.cpqcorp.net ([16.110.250.58]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 28 May 2003 17:14:45 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rddp] CRC - rough consensus update Date: Wed, 28 May 2003 17:14:45 -0500 Message-ID: <01CA1B1F74A4EC40A9C887F7B58F872403143198@cceexc16.americas.cpqcorp.net> Thread-Topic: [rddp] CRC - rough consensus update Thread-Index: AcMlWcJF9rc1zPtHRsyorXWAoPzkzAACr3zA From: "Barron, Dwight" To: Cc: X-OriginalArrivalTime: 28 May 2003 22:14:45.0453 (UTC) FILETIME=[8B8AD7D0:01C32566] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4SMFPB17394 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit wrstuden wrote: > Ah! My appologies. > > I think though that I agree with Caitlin here, that if we are > going to let > some ULPs take advantage of not computing CRCs, we should do > it both for > calculating and comparing. We should get the full umpf. > > Also, I'm not sure if we can really get away without > "negotiation" (well, > expression of preferences). While Caitlin and I are disagreeing about > where the admin fits in the scheme of things, I agree with > her that there > will be some ULPs that will really not want the other side to > ignore CRCs. > Say in the case where I have a lot of open buffers for you to > send to, I > wamt to make sure that you check the CRCs to make sure that you get my > STags & such right. Given the desire to mask latency with multiple outstanding requests, wouldn't this description apply to just about any ULP that would be architected for RDDP? Or conversely, would you propose that ULP designers purposely constrain the number of advertised buffers just to "optimize" for the case where CRCs were turned off? Regards, Dwight _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 18:34:25 2003 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 SAA28086 for ; Wed, 28 May 2003 18:34:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SMY0G18245 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 18:34:00 -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 h4SMY0B18242 for ; Wed, 28 May 2003 18:34:00 -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 SAA28081 for ; Wed, 28 May 2003 18:33:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9T1-0000sD-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 18:32:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L9T0-0000sA-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 18:32:18 -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 h4SMX1B18208; Wed, 28 May 2003 18:33:01 -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 h4SMWDB18182 for ; Wed, 28 May 2003 18:32:13 -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 SAA28060 for ; Wed, 28 May 2003 18:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L9RH-0000rr-00 for rddp@ietf.org; Wed, 28 May 2003 18:30:31 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 19L9RH-0000ro-00 for rddp@ietf.org; Wed, 28 May 2003 18:30:31 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id 4EC021C00AA7 for ; Wed, 28 May 2003 15:32:07 -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 h4SMRf203046 for ; Wed, 28 May 2003 15:27:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20030528151036.03654d80@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 May 2003 15:11:47 -0700 To: rddp@ietf.org From: Michael Krause Subject: RE: [rddp] CRC - rough consensus update In-Reply-To: <5.2.1.1.2.20030528172020.00b7a0a8@silver.nane.netapp.com> References: 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , At 05:24 PM 5/28/2003 -0400, Talpey, Thomas wrote: >At 02:35 PM 5/28/2003, John Hufferd wrote: > >So, lets propose that based on the perceived fact > >that SW overhead is NOT an issue, we just say that the requirement from the > >iWARP layers is to provide to the ULP protection at least as strong as that > >provided by CRC32c. >... > >If the above is reasonable, then since we have stated that if either side > >wants it, the CRC must be sent. And if a side can not tell if it has IPSec > >Encryption but the other side can and says that it does not want the CRC, > >then don't generate the CRC. However, if the other side does not > explicitly > >say it does not want the CRC, then it should be provided. > >If overhead is not an issue, then what difference does it make whether the >CRC is included or not? In other words, why bother to negotiate leaving it >out? >Just calculate it and let the receiver decide whether to pay attention. >Everyone wins. Making this a receiver issue to check or not seems like a step in the right direction. KISS is preferred over negotiation (round-trip latency, complexity, etc.). Mike _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 19:48:33 2003 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 TAA00201 for ; Wed, 28 May 2003 19:48:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SNm6523248 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 19:48:06 -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 h4SNm6B23245 for ; Wed, 28 May 2003 19:48:06 -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 TAA00198 for ; Wed, 28 May 2003 19:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LAcm-0001Nl-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 19:46:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LAcl-0001Ni-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 19:46:27 -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 h4SNlAB23218; Wed, 28 May 2003 19:47:10 -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 h4SNkfB23174 for ; Wed, 28 May 2003 19:46:41 -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 TAA00167; Wed, 28 May 2003 19:46:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LAbO-0001NU-00; Wed, 28 May 2003 19:45:02 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19LAbK-0001NN-00; Wed, 28 May 2003 19:44:58 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4SNk4Qs235600; Wed, 28 May 2003 19:46:04 -0400 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4SNk4WS159226; Wed, 28 May 2003 17:46:04 -0600 To: "Talpey, Thomas" Cc: rddp@ietf.org, rddp-admin@ietf.org MIME-Version: 1.0 Subject: RE: [rddp] CRC - rough consensus update X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Wed, 28 May 2003 16:45:51 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.1 [IBM]|May 6, 2003) at 05/28/2003 17:46:03, Serialize complete at 05/28/2003 17:46:03 Content-Type: multipart/alternative; boundary="=_alternative 00827FAD88256D34_=" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00827FAD88256D34_= Content-Type: text/plain; charset="us-ascii" I do not think it is an overhead issue, but it may simplify some of the actions that need to be handled with HW RNICs, because the packets are manipulated at different points with different state engines etc. However, if it does not matter to the RNIC vendors, then with the overhead low, it should just always be done. And in that case there is no Admin action for CRC. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Talpey, Thomas" Sent by: rddp-admin@ietf.org 05/28/2003 02:24 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: RE: [rddp] CRC - rough consensus update At 02:35 PM 5/28/2003, John Hufferd wrote: >So, lets propose that based on the perceived fact >that SW overhead is NOT an issue, we just say that the requirement from the >iWARP layers is to provide to the ULP protection at least as strong as that >provided by CRC32c. ... >If the above is reasonable, then since we have stated that if either side >wants it, the CRC must be sent. And if a side can not tell if it has IPSec >Encryption but the other side can and says that it does not want the CRC, >then don't generate the CRC. However, if the other side does not explicitly >say it does not want the CRC, then it should be provided. If overhead is not an issue, then what difference does it make whether the CRC is included or not? In other words, why bother to negotiate leaving it out? Just calculate it and let the receiver decide whether to pay attention. Everyone wins. This has been my point, at least. Tom. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --=_alternative 00827FAD88256D34_= Content-Type: text/html; charset="us-ascii"
I do not think it is an overhead issue, but it may simplify some of the actions that need to be handled with HW RNICs, because the packets are manipulated at different points with different state engines etc.  

However, if it does not matter to the RNIC vendors, then with the overhead low, it should just always be done.  And in that case there is no Admin action for CRC.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Talpey, Thomas" <Thomas.Talpey@netapp.com>
Sent by: rddp-admin@ietf.org

05/28/2003 02:24 PM

       
        To:        John Hufferd/San Jose/IBM@IBMUS
        cc:        <rddp@ietf.org>
        Subject:        RE: [rddp] CRC - rough consensus update



At 02:35 PM 5/28/2003, John Hufferd wrote:
>So, lets propose that based on the perceived fact
>that SW overhead is NOT an issue, we just say that the requirement from the
>iWARP layers is to provide to the ULP protection at least as strong as that
>provided by CRC32c.  
...
>If the above is reasonable, then since we have stated that if either side
>wants it, the CRC must be sent.  And if a side can not tell if it has IPSec
>Encryption but the other side can and says that it does not want the CRC,
>then don't generate the CRC.  However, if the other side does not explicitly
>say it does not want the CRC, then it should be provided.

If overhead is not an issue, then what difference does it make whether the
CRC is included or not? In other words, why bother to negotiate leaving it out?
Just calculate it and let the receiver decide whether to pay attention.
Everyone wins.

This has been my point, at least.

Tom.

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

--=_alternative 00827FAD88256D34_=-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 19:50:22 2003 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 TAA00246 for ; Wed, 28 May 2003 19:50:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SNntu23297 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 19:49:55 -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 h4SNntB23294 for ; Wed, 28 May 2003 19:49:55 -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 TAA00231 for ; Wed, 28 May 2003 19:49:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LAeW-0001OE-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 19:48:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LAeW-0001OB-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 19:48:16 -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 h4SNn1B23280; Wed, 28 May 2003 19:49:01 -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 h4SNmoB23265 for ; Wed, 28 May 2003 19:48:50 -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 TAA00216 for ; Wed, 28 May 2003 19:48:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LAdU-0001Nr-00 for rddp@ietf.org; Wed, 28 May 2003 19:47:12 -0400 Received: from lion.ninthwonder.com ([151.199.66.147]) by ietf-mx with esmtp (Exim 4.12) id 19LAdT-0001No-00 for rddp@ietf.org; Wed, 28 May 2003 19:47:11 -0400 Received: by lion.ninthwonder.com (Postfix, from userid 1021) id E7F7130706; Wed, 28 May 2003 19:48:42 -0400 (EDT) Date: Wed, 28 May 2003 23:47:52 +0000 (UTC) From: wrstuden@wasabisystems.com X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Caitlin Bestler Cc: rddp@ietf.org Subject: RE: [rddp] CRC - rough consensus update In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , On Wed, 28 May 2003, Caitlin Bestler wrote: First off, thank you for the thoughtful note. > On 5/28/03, wrstuden@wasabisystems.com wrote: > > >On Tue, 27 May 2003, Caitlin Bestler wrote: > > > >> On 5/27/03, Michael Krause wrote: > >> > >> >>My point is that the data belongs to the application, > >> >>not to the system administrator. > >> > > >> >The system belongs to the administrator / customer not > >> >the application designer or the ULP. > >> > >> On the contrary, it is the ULP. > > > >I'm sorry. I'm missing something. I go out and buy ten > >computers. One of them will be a server to the other nine. > >I pay for them myself. I install the OS myself. I buy & > >install the applications myself. I seed the data myself. > >At what point did the computers, software, and data start > >belonging to themselves and not me? > > > And if you want to use email on those computers that you > just bought, do you sit down and decide to do it on your > own? Of course not, you use an existing Upper Layer > Protocol. True, but the data still belong to me, don't they? I'm not sure if EMail is the best example here, for three reasons. First, EMail is an application, not just a ULP. Second, Email gets transfered over a number of different protocols. While SMTP is the most common, POP and IMAP and other protocols get used. Third, EMail is, well, complicated. :-) It's a mess. Configuring sendmail or postfix is something I'd rather not do. I'd rather build a new kernel file system or iSCSI stack or RDMA implementation instead. ;-) > Or, occassionally, you design your own ULP to meet your > own custom needs. > > The point is that it is the ULP that decides if additional > data integrity is required, because it is the ULP that > must specify what form (if any) that additional integrity > will take. I definitely agree that the ULP knows better than the RDMA layer how risk- sensitive it is. My whole point though is that the ULP should listen to the admin about relaxing requirements on CRCs. i.e. for just the ULP & RDMA, the ULP knows better. But when we add the admin to things, the admin should be further up the authority chain than either the ULP or RDMA. > For example, RDDP offers no services to authenticate the > end user. A ULP that requires those services must add > them on their own. Virtually everyone agrees that this > is a good thing because the needs for user authentication > vary so widely amongst different ULPs. It is not a natural > service for a transport layer. > > So when I design a ULP using RDMA, can I rely upon > end-to-end CRC32c (or equivalent) data protection or not? Yes. I think it is reasonable to assume that you will have CRC32C or equivalent data protection. The only time you wouldn't have CRCs in active use are times when the admin(s) have decided that the links a connection will travel over will be safe enough with the TCP checksum. Given how contentious this point is, I think it would be reasonable to add text indicating that SHOULD not disable RDMA CRCs (well indicate a desire to ignore them) without assessing both the links such a connection will traverse and the error sensitivity of the ULP. Yes, it's not enforceable by RDMA, but it can serve as an agreement between the ULPs and the admins as to when CRCs will be ignorable. > If I have to actively *check* something that I really do > not. An active control is an additional failure point. > It is one more thing that has to be tested and monitored > forever. It is a permanent ongoing cost for all > applications, well at least those that do QA. > > And for what benefit? So *some* implementations can > safe a very small amount of CPU power? When *most* > will either perform the check in hardware and/or > have adequate CPU power? > > Reduced data-integrity checking is a specialized > need. I have no problem allowing it, provided that > it costs the general application nothing. And I don't think this will really cost the general application anything. Everything we're saying (or everything I've been hearing) indicates that everyone is fine with CRCs defaulting to enabled, and having either side being able to require them. Thus for them to NOT be active would mean that a deliberate policy decision by the admin(s) covering the connection has been made. > That means that an affirmative step should be required, > *for each ULP* and *for each path* to enable voiding CRCs. > > Anything that resembles a "big red switch" to disable CRCs, > that applications must check to make sure it wasn't thrown > on accident, is imposing an unacceptable cost on all > applications for the benefit of a small handful. Then let's make that part of the spec. I think it is appropriate for CRC disabling to be performable on a port by port basis. We can make it a SHOULD in the RFC. In fact, it sounds like we should. I've certainly had "it's not a big red switch" in my mind as to how things should be. Actually, something closer to how IPsec policy is set up would be best. Then you can throw address ranges into the policy. So you can permit not using CRCs over the direct connection you have to a box, but not permit them being skipped over the connection that goes through the wiring closet. If you want. It's sounding like an informational guide for administrators RFC may be in order for the working group to create. > That means the ULP must take an affirmative act to indicate > a willingness to accept less than end-to-end CRC32c > protection. Avoiding taking an affirmative act is not > something that you have to test for with each release > (after all, there an an infinite number of affirmative > actions that any application has not taken, they obviously > cannot be tested for). If we do it like that (say something like the TCP_NDELAY option), then the ULP or its implementing application really MUST be configurable to forgo requiring CRCs. Otherwise the ULP is making a policy decision for the admin, when it should be the other way around. > While I cannot think of a way to make it an enforceable MUST > or SHOULD, any determination by a network administrator that > a given path offers the equivalent of end-to-end CRC32c > protection should last only as long as that path is stable. At some point we have to say, "Yes, there's the rope. If you hang yourself, that's your own foolishness." Because every time we prevent admins from doing something stupid, we also prevent them from doing something clever. > Further, the network administrator MUST NOT make predictions > for any path that goes through any middle-box not under > their exclusive control. To do otherwise creates an > obligation on a middlebox to continue to function as > it has in the past. Any such requirement would be contrary > to the fundamental nature of an IP network. > > Ultimately, the futility of CRC suppression based on > "network quality" is that the environments where that > assertion can be made are exactly those where software > implementations are the least likely. > > Any real value will more likely be found with software > stacks running on remote clients for those applications that > can actively assert that an end-to-end 16-bit TCP checksum > is adequate for their needs. The gotcha there is that > calculating a CRC32c for even T1 speeds is trivial. Since we're talking hypotheticals, it's not to hard to find a counter example. :-) I think a common and reasonable case would be one where we have end-to-end IPsec. It is my understanding that the cryptographic hashes in IPsec are stronger than CRC32C, so the CRC will, in a well-crafted system, add no value. So there's a case that will be using high-performance hardware where an application/ULP will see CRC32C equivalent protection w/o a CRC. I agree that IPsec in and of itself isn't the cure-all, since there may be perfectly-valid systems that have the IPsec calculation far enough away that the TCP checksum isn't good enough. But there can (and I expect will) be times when it is. Also, haven't we been talking about (as one installation scenario) the case of fan-in systems, where a number of clients fan into one system? While it's not hard to calculate the CRCs at T1 rates, if you have a few thousand simultaneous feeds (or ten thousand feeds), you start to notice. Take care, Bill _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 20:29:20 2003 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 UAA01043 for ; Wed, 28 May 2003 20:29:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4T0Sq725411 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 20:28:52 -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 h4T0SqB25408 for ; Wed, 28 May 2003 20:28:52 -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 UAA01032 for ; Wed, 28 May 2003 20:28:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LBGC-0001bl-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 20:27:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LBGC-0001bi-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 20:27:12 -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 h4T0S2B25381; Wed, 28 May 2003 20:28:02 -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 h4T0RxB25366 for ; Wed, 28 May 2003 20:27:59 -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 UAA01019 for ; Wed, 28 May 2003 20:27:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LBFL-0001bV-00 for rddp@ietf.org; Wed, 28 May 2003 20:26:19 -0400 Received: from magic-mail.adaptec.com ([208.236.45.100] helo=magic.adaptec.com) by ietf-mx with esmtp (Exim 4.12) id 19LBFK-0001bH-00 for rddp@ietf.org; Wed, 28 May 2003 20:26:18 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4T0MhZ11210 for ; Wed, 28 May 2003 17:22:43 -0700 Received: from aimexc07.adaptec.com (aimexc07.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id RAA16142 for ; Wed, 28 May 2003 17:27:25 -0700 (PDT) Received: by aimexc07.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 May 2003 17:27:24 -0700 Message-ID: From: "Carrier, John" To: rddp@ietf.org Subject: RE: [rddp] CRC - rough consensus update Date: Wed, 28 May 2003 17:27:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , I am sorry, but I think this discussion is meandering way out of scope: remember that DDP/RDMAP will be layered over SCTP as well as TCP. There is no way to disable the CRC in SCTP; therefore, there really should be no way to disable the CRC for MPA/TCP. I would prefer to think that the RDMAP consumer can be indifferent to the underlying transport. Otherwise, ULPs using DDP/RDMAP would have to be written with two different expectations of the RDMA transport depending on whether it uses SCTP or MPA/TCP. If we keep the overall architecture in mind, then I don't think the options discussed in this thread belong in the protocol. --jc > -----Original Message----- > From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] > Sent: Wednesday, May 28, 2003 4:48 PM > To: Caitlin Bestler > Cc: rddp@ietf.org > Subject: RE: [rddp] CRC - rough consensus update > > > On Wed, 28 May 2003, Caitlin Bestler wrote: > > First off, thank you for the thoughtful note. > > > On 5/28/03, wrstuden@wasabisystems.com wrote: > > > > >On Tue, 27 May 2003, Caitlin Bestler wrote: > > > > > >> On 5/27/03, Michael Krause wrote: > > >> > > >> >>My point is that the data belongs to the application, > > >> >>not to the system administrator. > > >> > > > >> >The system belongs to the administrator / customer not > > >> >the application designer or the ULP. > > >> > > >> On the contrary, it is the ULP. > > > > > >I'm sorry. I'm missing something. I go out and buy ten > > >computers. One of them will be a server to the other nine. > > >I pay for them myself. I install the OS myself. I buy & > > >install the applications myself. I seed the data myself. > > >At what point did the computers, software, and data start > > >belonging to themselves and not me? > > > > > And if you want to use email on those computers that you > > just bought, do you sit down and decide to do it on your > > own? Of course not, you use an existing Upper Layer > > Protocol. > > True, but the data still belong to me, don't they? > > I'm not sure if EMail is the best example here, for three > reasons. First, > EMail is an application, not just a ULP. Second, Email gets transfered > over a number of different protocols. While SMTP is the most > common, POP > and IMAP and other protocols get used. Third, EMail is, well, > complicated. > :-) It's a mess. Configuring sendmail or postfix is something > I'd rather > not do. I'd rather build a new kernel file system or iSCSI > stack or RDMA > implementation instead. ;-) > > > Or, occassionally, you design your own ULP to meet your > > own custom needs. > > > > The point is that it is the ULP that decides if additional > > data integrity is required, because it is the ULP that > > must specify what form (if any) that additional integrity > > will take. > > I definitely agree that the ULP knows better than the RDMA > layer how risk- > sensitive it is. > > My whole point though is that the ULP should listen to the admin about > relaxing requirements on CRCs. i.e. for just the ULP & RDMA, > the ULP knows > better. But when we add the admin to things, the admin should > be further > up the authority chain than either the ULP or RDMA. > > > For example, RDDP offers no services to authenticate the > > end user. A ULP that requires those services must add > > them on their own. Virtually everyone agrees that this > > is a good thing because the needs for user authentication > > vary so widely amongst different ULPs. It is not a natural > > service for a transport layer. > > > > So when I design a ULP using RDMA, can I rely upon > > end-to-end CRC32c (or equivalent) data protection or not? > > Yes. > > I think it is reasonable to assume that you will have CRC32C > or equivalent > data protection. The only time you wouldn't have CRCs in > active use are > times when the admin(s) have decided that the links a connection will > travel over will be safe enough with the TCP checksum. > > Given how contentious this point is, I think it would be > reasonable to add > text indicating that SHOULD not disable RDMA CRCs (well > indicate a desire > to ignore them) without assessing both the links such a > connection will > traverse and the error sensitivity of the ULP. Yes, it's not > enforceable by > RDMA, but it can serve as an agreement between the ULPs and > the admins as > to when CRCs will be ignorable. > > > If I have to actively *check* something that I really do > > not. An active control is an additional failure point. > > It is one more thing that has to be tested and monitored > > forever. It is a permanent ongoing cost for all > > applications, well at least those that do QA. > > > > And for what benefit? So *some* implementations can > > safe a very small amount of CPU power? When *most* > > will either perform the check in hardware and/or > > have adequate CPU power? > > > > Reduced data-integrity checking is a specialized > > need. I have no problem allowing it, provided that > > it costs the general application nothing. > > And I don't think this will really cost the general > application anything. > > Everything we're saying (or everything I've been hearing) > indicates that > everyone is fine with CRCs defaulting to enabled, and having > either side > being able to require them. Thus for them to NOT be active > would mean that > a deliberate policy decision by the admin(s) covering the > connection has > been made. > > > That means that an affirmative step should be required, > > *for each ULP* and *for each path* to enable voiding CRCs. > > > > Anything that resembles a "big red switch" to disable CRCs, > > that applications must check to make sure it wasn't thrown > > on accident, is imposing an unacceptable cost on all > > applications for the benefit of a small handful. > > Then let's make that part of the spec. > > I think it is appropriate for CRC disabling to be performable > on a port by > port basis. We can make it a SHOULD in the RFC. In fact, it > sounds like we > should. I've certainly had "it's not a big red switch" in my > mind as to > how things should be. > > Actually, something closer to how IPsec policy is set up > would be best. > Then you can throw address ranges into the policy. So you can > permit not > using CRCs over the direct connection you have to a box, but > not permit > them being skipped over the connection that goes through the wiring > closet. If you want. > > It's sounding like an informational guide for administrators > RFC may be in > order for the working group to create. > > > That means the ULP must take an affirmative act to indicate > > a willingness to accept less than end-to-end CRC32c > > protection. Avoiding taking an affirmative act is not > > something that you have to test for with each release > > (after all, there an an infinite number of affirmative > > actions that any application has not taken, they obviously > > cannot be tested for). > > If we do it like that (say something like the TCP_NDELAY > option), then the > ULP or its implementing application really MUST be > configurable to forgo > requiring CRCs. > > Otherwise the ULP is making a policy decision for the admin, when it > should be the other way around. > > > While I cannot think of a way to make it an enforceable MUST > > or SHOULD, any determination by a network administrator that > > a given path offers the equivalent of end-to-end CRC32c > > protection should last only as long as that path is stable. > > At some point we have to say, "Yes, there's the rope. If you hang > yourself, that's your own foolishness." Because every time we prevent > admins from doing something stupid, we also prevent them from doing > something clever. > > > Further, the network administrator MUST NOT make predictions > > for any path that goes through any middle-box not under > > their exclusive control. To do otherwise creates an > > obligation on a middlebox to continue to function as > > it has in the past. Any such requirement would be contrary > > to the fundamental nature of an IP network. > > > > Ultimately, the futility of CRC suppression based on > > "network quality" is that the environments where that > > assertion can be made are exactly those where software > > implementations are the least likely. > > > > Any real value will more likely be found with software > > stacks running on remote clients for those applications that > > can actively assert that an end-to-end 16-bit TCP checksum > > is adequate for their needs. The gotcha there is that > > calculating a CRC32c for even T1 speeds is trivial. > > Since we're talking hypotheticals, it's not to hard to find a counter > example. :-) > > I think a common and reasonable case would be one where we > have end-to-end > IPsec. It is my understanding that the cryptographic hashes > in IPsec are > stronger than CRC32C, so the CRC will, in a well-crafted > system, add no > value. So there's a case that will be using high-performance hardware > where an application/ULP will see CRC32C equivalent > protection w/o a CRC. > > I agree that IPsec in and of itself isn't the cure-all, since > there may be > perfectly-valid systems that have the IPsec calculation far > enough away > that the TCP checksum isn't good enough. But there can (and I > expect will) > be times when it is. > > Also, haven't we been talking about (as one installation > scenario) the case > of fan-in systems, where a number of clients fan into one > system? While > it's not hard to calculate the CRCs at T1 rates, if you have a few > thousand simultaneous feeds (or ten thousand feeds), you > start to notice. > > Take care, > > Bill > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Wed May 28 21:23:17 2003 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 VAA02161 for ; Wed, 28 May 2003 21:23:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4T1Mos29337 for rddp-archive@odin.ietf.org; Wed, 28 May 2003 21:22:50 -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 h4T1MoB29334 for ; Wed, 28 May 2003 21:22:50 -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 VAA02145 for ; Wed, 28 May 2003 21:22:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LC6P-0001r9-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 21:21:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LC6P-0001r6-00 for rddp-web-archive@ietf.org; Wed, 28 May 2003 21:21:09 -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 h4T1M6B29307; Wed, 28 May 2003 21:22:06 -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 h4T1LZB29229 for ; Wed, 28 May 2003 21:21:35 -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 VAA02106 for ; Wed, 28 May 2003 21:21:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LC5C-0001qa-00 for rddp@ietf.org; Wed, 28 May 2003 21:19:54 -0400 Received: from lion.ninthwonder.com ([151.199.66.147]) by ietf-mx with esmtp (Exim 4.12) id 19LC5C-0001qX-00 for rddp@ietf.org; Wed, 28 May 2003 21:19:54 -0400 Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 06CBA30706; Wed, 28 May 2003 21:21:30 -0400 (EDT) Date: Thu, 29 May 2003 01:20:40 +0000 (UTC) From: wrstuden@wasabisystems.com X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Barron, Dwight" Cc: rddp@ietf.org Subject: RE: [rddp] CRC - rough consensus update In-Reply-To: <01CA1B1F74A4EC40A9C887F7B58F872403143198@cceexc16.americas.cpqcorp.net> Message-ID: References: <01CA1B1F74A4EC40A9C887F7B58F872403143198@cceexc16.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , On Wed, 28 May 2003, Barron, Dwight wrote: > wrstuden wrote: > > > Also, I'm not sure if we can really get away without > > "negotiation" (well, > > expression of preferences). While Caitlin and I are disagreeing about > > where the admin fits in the scheme of things, I agree with > > her that there > > will be some ULPs that will really not want the other side to > > ignore CRCs. > > Say in the case where I have a lot of open buffers for you to > > send to, I > > wamt to make sure that you check the CRCs to make sure that you get my > > STags & such right. > > Given the desire to mask latency with multiple outstanding requests, > wouldn't this description apply to just about any ULP that would be > architected for RDDP? Or conversely, would you propose that ULP > designers purposely constrain the number of advertised buffers just to > "optimize" for the case where CRCs were turned off? Neither. I think that ULPs should assume it has a CRC-quality connection. If CRCs are being ignored, it is because the system admin(s) determined that the connection will have CRC32C-quality protection. If ULPs assume anything else, we will be in for a royal mess. Take care, Bill _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 29 12:47:25 2003 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 MAA09759 for ; Thu, 29 May 2003 12:47:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TGkxN04120 for rddp-archive@odin.ietf.org; Thu, 29 May 2003 12:46:59 -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 h4TGkxB04117 for ; Thu, 29 May 2003 12:46:59 -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 MAA09754 for ; Thu, 29 May 2003 12:46:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQWk-0000dl-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 12:45:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LQWj-0000di-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 12:45:17 -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 h4TGk8B04085; Thu, 29 May 2003 12:46:08 -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 h4TGjhB04060 for ; Thu, 29 May 2003 12:45:43 -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 MAA09742 for ; Thu, 29 May 2003 12:45:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQVW-0000dU-00 for rddp@ietf.org; Thu, 29 May 2003 12:44:02 -0400 Received: from lion.ninthwonder.com ([151.199.66.147]) by ietf-mx with esmtp (Exim 4.12) id 19LQVV-0000dR-00 for rddp@ietf.org; Thu, 29 May 2003 12:44:01 -0400 Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 097A430706; Thu, 29 May 2003 12:45:39 -0400 (EDT) Date: Thu, 29 May 2003 16:44:48 +0000 (UTC) From: wrstuden@wasabisystems.com X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Caitlin Bestler Cc: rddp@ietf.org Subject: Re: [rddp] CRC - issue E consensus call. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , On Wed, 28 May 2003, Caitlin Bestler wrote: > On 5/23/03, Black_David@emc.com wrote: > > >(E') CRC usage is an administrative configuration > >decision - it is not intended to be visible to ULPs. > > I would like to refine that as follows: > > Administrative permission to suppress CRCs for a given > connection MAY be given if the paths over which the > connection will travel are known to provide the equivalent > of an end-to-end CRC32c protection, or meet other criteria > explicitly established for the ULP. > > > > That is, there can never be less than the equivalent of > end-to-end CRC32c unless the ULP explicitly allows for this. > The mechanism for doing so would be out-of-scope. > > I would also be comfortable with dropping the "or meet other > criteria explicitly established for the ULP." clause. What would be an example of, "other criteria explicitly established for the ULP"? > The important thing is that to be truly invisible to the > ULP, the ULP must be able to presume that its minimum > standards will be met. Further that standard is an > end-to-end CRC32c by default. An ULP MAY set a lower > standard, if it so desires. If a ULP wants a higher > standard, it provide its own supplemental solutions. Sounds fine. I agree that if CRCs are off, that means that the admin has determined the link is as safe as if the CRC were there (because if the admin hasn't made that determination, CRCs should not be off). Both the ULP should trust the admin is right and the admin should know what she or he is doing in permitting them to not be used. Take care, Bill _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 29 13:03:11 2003 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 NAA10202 for ; Thu, 29 May 2003 13:03:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TH2jE04754 for rddp-archive@odin.ietf.org; Thu, 29 May 2003 13:02:45 -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 h4TH2jB04751 for ; Thu, 29 May 2003 13:02:45 -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 NAA10197 for ; Thu, 29 May 2003 13:02:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQlz-0000hx-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 13:01:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LQlz-0000hu-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 13:01:03 -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 h4TH26B04734; Thu, 29 May 2003 13:02:06 -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 h4TH1HB04698 for ; Thu, 29 May 2003 13:01:17 -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 NAA10122 for ; Thu, 29 May 2003 13:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQka-0000hT-00 for rddp@ietf.org; Thu, 29 May 2003 12:59:36 -0400 Received: from lion.ninthwonder.com ([151.199.66.147]) by ietf-mx with esmtp (Exim 4.12) id 19LQkZ-0000hO-00 for rddp@ietf.org; Thu, 29 May 2003 12:59:35 -0400 Received: by lion.ninthwonder.com (Postfix, from userid 1021) id EB78D30706; Thu, 29 May 2003 13:01:13 -0400 (EDT) Date: Thu, 29 May 2003 17:00:23 +0000 (UTC) From: wrstuden@wasabisystems.com X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Talpey, Thomas" Cc: John Hufferd , rddp@ietf.org Subject: RE: [rddp] CRC - rough consensus update In-Reply-To: <5.2.1.1.2.20030528172020.00b7a0a8@silver.nane.netapp.com> Message-ID: References: <5.2.1.1.2.20030528172020.00b7a0a8@silver.nane.netapp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , On Wed, 28 May 2003, Talpey, Thomas wrote: > At 02:35 PM 5/28/2003, John Hufferd wrote: > >So, lets propose that based on the perceived fact > >that SW overhead is NOT an issue, we just say that the requirement from the > >iWARP layers is to provide to the ULP protection at least as strong as that > >provided by CRC32c. > ... > >If the above is reasonable, then since we have stated that if either side > >wants it, the CRC must be sent. And if a side can not tell if it has IPSec > >Encryption but the other side can and says that it does not want the CRC, > >then don't generate the CRC. However, if the other side does not explicitly > >say it does not want the CRC, then it should be provided. > > If overhead is not an issue, then what difference does it make whether the > CRC is included or not? In other words, why bother to negotiate leaving it out? > Just calculate it and let the receiver decide whether to pay attention. > Everyone wins. Because overhead is an issue. It will always be an issue. I think everyone here agrees that a CRC32C is well worth its overhead price on top of plain TCP, so that by choosing it we aren't shooting ourselves in the foot. But if we have done something else, say IPsec, that gives us better than CRC32C protection, why not let the CRC32C be skipped for the implementations that can notice the improvement? While calculating the CRC may be easy for a recent CPU, if you are handling thousands or tens of thousands of connections, you want to skip any calculation/step you can. Take care, Bill _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 29 13:20:05 2003 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 NAA10793 for ; Thu, 29 May 2003 13:20:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4THJeX06262 for rddp-archive@odin.ietf.org; Thu, 29 May 2003 13:19:40 -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 h4THJeB06259 for ; Thu, 29 May 2003 13:19:40 -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 NAA10789 for ; Thu, 29 May 2003 13:19:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LR2M-0000oq-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 13:17:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LR2L-0000on-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 13:17:57 -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 h4THJ2B06236; Thu, 29 May 2003 13:19:02 -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 h4THIEB06214 for ; Thu, 29 May 2003 13:18:14 -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 NAA10778 for ; Thu, 29 May 2003 13:18:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LR0y-0000oc-00 for rddp@ietf.org; Thu, 29 May 2003 13:16:32 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19LR0x-0000oY-00 for rddp@ietf.org; Thu, 29 May 2003 13:16:31 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 7D62D2451AC; Thu, 29 May 2003 13:18:06 -0400 (EDT) Date: Thu, 29 May 2003 12:17:38 -0500 From: Caitlin Bestler Subject: RE: [rddp] CRC - rough consensus update To: wrstuden@wasabisystems.com, rddp@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/29/03, wrstuden@wasabisystems.com wrote: >While calculating the CRC may be easy for a recent CPU, if >you are handling thousands or tens of thousands of >connections, you want to skip any calculation/step you can. Actually the number of connections is almost irrelevant. The question is how many packets can be received during a given short time window. It doesn't take that many connections for that number to approach the NIC's peak rate. So either the CPU has to have the capacity to deal with performing the CRC32c calcualtion at wire speeds, or it has to have sufficient system buffering to allow a slower CPU to catch up with a lower sustained rate. External memory access is more likely to be the limiting factor than a calculation that can be performed entirely in system registers and/or cache. So the scenario where these savings would seem to apply is one where the host *can* keep up with the wire speed, but would prefer to reallocate that processing power to other tasks when possible. The most relevant that comes to mind is terminating IPSEC within the same processor. Having consumed general CPU power to terminate IPSEC, the "available processing power" pool is already low. So calculating the CRC32 again would indeed be wasteful. However, I do not think this is a very likely deployment. The "wire speed" out of a software IPSEC stack that uses the general purpose processor for decryption is unlikely to be anything near "wire speed". Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 29 14:17:18 2003 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 OAA12676 for ; Thu, 29 May 2003 14:17:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TIGqn10287 for rddp-archive@odin.ietf.org; Thu, 29 May 2003 14:16:52 -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 h4TIGqB10284 for ; Thu, 29 May 2003 14:16:52 -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 OAA12669 for ; Thu, 29 May 2003 14:16:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LRvh-0001ES-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 14:15:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LRvg-0001EP-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 14:15:08 -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 h4TIG8B10244; Thu, 29 May 2003 14:16:08 -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 h4TIFSB10222 for ; Thu, 29 May 2003 14:15:28 -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 OAA12622 for ; Thu, 29 May 2003 14:15:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LRuL-0001Dr-00 for rddp@ietf.org; Thu, 29 May 2003 14:13:45 -0400 Received: from lion.ninthwonder.com ([151.199.66.147]) by ietf-mx with esmtp (Exim 4.12) id 19LRuK-0001Do-00 for rddp@ietf.org; Thu, 29 May 2003 14:13:44 -0400 Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5F87430706; Thu, 29 May 2003 14:15:23 -0400 (EDT) Date: Thu, 29 May 2003 18:14:32 +0000 (UTC) From: wrstuden@wasabisystems.com X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Caitlin Bestler Cc: rddp@ietf.org Subject: RE: [rddp] CRC - rough consensus update In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , On Thu, 29 May 2003, Caitlin Bestler wrote: > On 5/29/03, wrstuden@wasabisystems.com wrote: > > >While calculating the CRC may be easy for a recent CPU, if > >you are handling thousands or tens of thousands of > >connections, you want to skip any calculation/step you can. > > Actually the number of connections is almost irrelevant. The > question is how many packets can be received during a given > short time window. It doesn't take that many connections for > that number to approach the NIC's peak rate. Very true. > So either the CPU has to have the capacity to deal with > performing the CRC32c calcualtion at wire speeds, or it > has to have sufficient system buffering to allow a slower > CPU to catch up with a lower sustained rate. > > External memory access is more likely to be the limiting > factor than a calculation that can be performed entirely > in system registers and/or cache. So the scenario where > these savings would seem to apply is one where the host > *can* keep up with the wire speed, but would prefer to > reallocate that processing power to other tasks when > possible. Exactly. > The most relevant that comes to mind is terminating IPSEC > within the same processor. Having consumed general CPU > power to terminate IPSEC, the "available processing power" > pool is already low. So calculating the CRC32 again would > indeed be wasteful. > > However, I do not think this is a very likely deployment. > The "wire speed" out of a software IPSEC stack that uses > the general purpose processor for decryption is unlikely to > be anything near "wire speed". Even if it's not CPU power, just saving bus access could be a win. ;-) I know of support chips coming out that will do CRC checking for the CPU, but they will still need to have the packet(s) traverse the system bus. Take care, Bill _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Thu May 29 14:53:49 2003 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 OAA14165 for ; Thu, 29 May 2003 14:53:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TIrOD12613 for rddp-archive@odin.ietf.org; Thu, 29 May 2003 14:53:24 -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 h4TIrOB12610 for ; Thu, 29 May 2003 14:53:24 -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 OAA14110 for ; Thu, 29 May 2003 14:53:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSV2-0001ZC-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 14:51:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LSV1-0001Z6-00 for rddp-web-archive@ietf.org; Thu, 29 May 2003 14:51:39 -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 h4TIq7B12569; Thu, 29 May 2003 14:52:08 -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 h4TIpYB12507 for ; Thu, 29 May 2003 14:51:34 -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 OAA13977 for ; Thu, 29 May 2003 14:51:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSTG-0001Wr-00 for rddp@ietf.org; Thu, 29 May 2003 14:49:50 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 19LSTF-0001Wc-00 for rddp@ietf.org; Thu, 29 May 2003 14:49:49 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 799F6D5E6; Thu, 29 May 2003 11:50:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 516CA1C730; Thu, 29 May 2003 11:50:33 -0700 (PDT) Cc: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 May 2003 11:50:06 -0700 From: "Somesh Gupta" Importance: Normal In-reply-to: Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 10637-60EACDCD; Thu, 29 May 2003 11:49:52 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id BCFA223DA4; Thu, 29 May 2003 11:49:52 -0700 (PDT) Subject: RE: [rddp] CRC - rough consensus update To: , "Caitlin Bestler" X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > wrstuden@wasabisystems.com > Sent: Thursday, May 29, 2003 11:15 AM > To: Caitlin Bestler > Cc: rddp@ietf.org > Subject: RE: [rddp] CRC - rough consensus update > > > On Thu, 29 May 2003, Caitlin Bestler wrote: > > > On 5/29/03, wrstuden@wasabisystems.com wrote: > > > > >While calculating the CRC may be easy for a recent CPU, if > > >you are handling thousands or tens of thousands of > > >connections, you want to skip any calculation/step you can. > > > > Actually the number of connections is almost irrelevant. The > > question is how many packets can be received during a given > > short time window. It doesn't take that many connections for > > that number to approach the NIC's peak rate. > > Very true. > > > So either the CPU has to have the capacity to deal with > > performing the CRC32c calcualtion at wire speeds, or it > > has to have sufficient system buffering to allow a slower > > CPU to catch up with a lower sustained rate. > > > > External memory access is more likely to be the limiting > > factor than a calculation that can be performed entirely > > in system registers and/or cache. So the scenario where > > these savings would seem to apply is one where the host > > *can* keep up with the wire speed, but would prefer to > > reallocate that processing power to other tasks when > > possible. > > Exactly. > > > The most relevant that comes to mind is terminating IPSEC > > within the same processor. Having consumed general CPU > > power to terminate IPSEC, the "available processing power" > > pool is already low. So calculating the CRC32 again would > > indeed be wasteful. > > > > However, I do not think this is a very likely deployment. > > The "wire speed" out of a software IPSEC stack that uses > > the general purpose processor for decryption is unlikely to > > be anything near "wire speed". IPSec will be one of the next things to be offloaded in the NIC. > > Even if it's not CPU power, just saving bus access could be a win. ;-) > > I know of support chips coming out that will do CRC checking for the CPU, > but they will still need to have the packet(s) traverse the system bus. > > Take care, > > Bill > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Sat May 31 11:02:30 2003 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 LAA04026 for ; Sat, 31 May 2003 11:02:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4VF26719297 for rddp-archive@odin.ietf.org; Sat, 31 May 2003 11:02:06 -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 h4VF26B19294 for ; Sat, 31 May 2003 11:02:06 -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 LAA04018 for ; Sat, 31 May 2003 11:02:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M7qF-0007hh-00 for rddp-web-archive@ietf.org; Sat, 31 May 2003 11:00:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19M7qE-0007hd-00 for rddp-web-archive@ietf.org; Sat, 31 May 2003 11:00:18 -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 h4VF1HB19279; Sat, 31 May 2003 11:01:17 -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 h4VF07B19215 for ; Sat, 31 May 2003 11:00:07 -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 LAA03978 for ; Sat, 31 May 2003 11:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M7oJ-0007h9-00 for rddp@ietf.org; Sat, 31 May 2003 10:58:19 -0400 Received: from sandmail.sandburst.com ([216.57.132.42]) by ietf-mx with esmtp (Exim 4.12) id 19M7oI-0007gt-00 for rddp@ietf.org; Sat, 31 May 2003 10:58:18 -0400 To: rddp@ietf.org Subject: Re: [rddp] CRC - rough consensus update In-Reply-To: Message from "Carrier, John" of "Wed, 28 May 2003 17:27:24 PDT." References: Date: Sat, 31 May 2003 10:58:55 -0400 From: Stephen Bailey Message-Id: <20030531145856.C1A7C4EC2@sandmail.sandburst.com> 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , > I am sorry, but I think this discussion is meandering way out of scope: > remember that DDP/RDMAP will be layered over SCTP as well as TCP. There is > no way to disable the CRC in SCTP; therefore, there really should be no way > to disable the CRC for MPA/TCP. The IP tradition seems to suggest you use different transports to get different service. Just because SCTP provides CRC doesn't mean MPA/TCP must also provide CRC. If you turn CRC off in SCTP, you would have no integrity checking at all. If you turn CRC off in MPA, you still have the TCP checksum. I agree (with Bill & Caitlin) that the issue IS software overhead. Software implementations are most likely to be `cleanly layered' which means TCP and MPA (and IPSec) will probably all have different touches of the data. A user mode implementation of RDDP+MPA on a stock TCP socket is a key early implementation approach. Even though we shouldn't plan on aggressively optimized (rototilled) software implementations that reduce the data touching, _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From mailnull@www1.ietf.org Sat May 31 13:15:24 2003 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 NAA06066 for ; Sat, 31 May 2003 13:15:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4VHEwF28147 for rddp-archive@odin.ietf.org; Sat, 31 May 2003 13:14:58 -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 h4VHEwB28144 for ; Sat, 31 May 2003 13:14:58 -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 NAA06063 for ; Sat, 31 May 2003 13:14:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M9uq-0000WV-00 for rddp-web-archive@ietf.org; Sat, 31 May 2003 13:13:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19M9uq-0000WS-00 for rddp-web-archive@ietf.org; Sat, 31 May 2003 13:13:12 -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 h4VHE9B28103; Sat, 31 May 2003 13:14:09 -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 h4VHDXB28068 for ; Sat, 31 May 2003 13:13:33 -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 NAA05996 for ; Sat, 31 May 2003 13:13:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M9tT-0000Vz-00 for rddp@ietf.org; Sat, 31 May 2003 13:11:47 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19M9tT-0000Vw-00 for rddp@ietf.org; Sat, 31 May 2003 13:11:47 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 738922448B2; Sat, 31 May 2003 13:13:26 -0400 (EDT) Date: Sat, 31 May 2003 12:12:57 -0500 From: Caitlin Bestler Subject: Re: [rddp] CRC - rough consensus update To: Stephen Bailey Cc: rddp@ietf.org X-Priority: 3 In-Reply-To: <20030531145856.C1A7C4EC2@sandmail.sandburst.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/31/03, Stephen Bailey wrote: >> I am sorry, but I think this discussion is meandering >> way out of scope: remember that DDP/RDMAP will be >> layered over SCTP as well as TCP. There is no way to >> disable the CRC in SCTP; therefore, there really should >> be no way to disable the CRC for MPA/TCP. > >The IP tradition seems to suggest you use different >transports to get different service. Just because SCTP >provides CRC doesn't mean MPA/TCP must also provide CRC. >If you turn CRC off in SCTP, you would have no integrity >checking at all. If you turn CRC off in MPA, you still >have the TCP checksum. > >I agree (with Bill & Caitlin) that the issue IS software >overhead. Software implementations are most likely to be >`cleanly layered' which means TCP and MPA (and IPSec) will >probably all have different touches of the data. A user >mode implementation of RDDP+MPA on a stock TCP socket is a >key early implementation approach. > >Even though we shouldn't plan on aggressively optimized >(rototilled) software implementations that reduce the data >touching, And if they code it in Java it will be even slower. And while we don't want to forbid Java implementations, I doubt anyone would propose a change to the protocol for the benefit of Java implementations. There are several reality-checks needed here. There will indeed be software stacks that are cleanly layered on top of existing TCP stacks. But they will mostly be used for remote clients at low speeds. An implementation can be cleanly layered if it wants, but the extra memory touches that clean layering causes are its own problem. The protocol works, even with the extra protocols. It also allows a rototilled implementation to optimize to reduce the number of memory touches required. Software implementations of the entire stack are indeed feasible (and frequently what "hardware" solutions are really doing). But whatever the speed limits for such implementations are, the CRC32c is scarcely a factor. The "extra" memory touch is only an artifact of building upon existing pieces, not of the inherent problem. The computation required is trivial. Keep in mind that any platform (software and/or hardware) must have the raw processing power (in software and/or hardware) to handle all MPA/TCP connections with CRCs enabled. The point of the option is allow some implementations to redeploy some of that processing power when L2 protections have provided equivalent end-to-end coverage. The benefit is slight, and only available to some implementations. But under Jim's proposal it has virtually zero impact on the other implementations. From their point of view it "wastes" some bits in the MPA mode frame. For that low of a cost I can see no reason not to allow the handful of implmentations that would benefit from this from doing so. But we have to be very careful to make certain that the costs do not grow. Most importantly, ULP designers must have no doubts that they are guaranteed end-to-end CRC32c protection. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp