From exim@www1.ietf.org Wed Jan 7 01:00:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24183 for ; Wed, 7 Jan 2004 01:00:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae6jU-0005m6-Rl for rddp-archive@odin.ietf.org; Wed, 07 Jan 2004 00:59:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i075xux1022194 for rddp-archive@odin.ietf.org; Wed, 7 Jan 2004 00:59:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae6jU-0005lt-OG for rddp-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 00:59:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24150 for ; Wed, 7 Jan 2004 00:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae6jR-0001Jx-00 for rddp-web-archive@ietf.org; Wed, 07 Jan 2004 00:59:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae6hZ-0001EW-00 for rddp-web-archive@ietf.org; Wed, 07 Jan 2004 00:57:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae6fw-0001BL-00 for rddp-web-archive@ietf.org; Wed, 07 Jan 2004 00:56:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae6fi-0005f6-6z; Wed, 07 Jan 2004 00:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae6fc-0005e9-Ds for rddp@optimus.ietf.org; Wed, 07 Jan 2004 00:55:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23990 for ; Wed, 7 Jan 2004 00:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae6fZ-00017M-00 for rddp@ietf.org; Wed, 07 Jan 2004 00:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae6dg-0000yu-00 for rddp@ietf.org; Wed, 07 Jan 2004 00:53:57 -0500 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1Ae6bt-0000sj-00 for rddp@ietf.org; Wed, 07 Jan 2004 00:52:05 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Tue, 06 Jan 2004 21:51:51 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0740.brcm.ad.broadcom.com ( 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 VAA16840 for ; Tue, 6 Jan 2004 21:51:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jan 2004 21:51:49 -0800 Message-ID: Thread-Topic: TEST...pls ignore Thread-Index: AcPU4h2f+geEoaJfQ12vvyAeoIbsiw== From: "Uri Elzur" To: rddp@ietf.org X-WSS-ID: 13E541FD2L413907-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D4E2.57E95916" Subject: [rddp] TEST...pls ignore 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3D4E2.57E95916 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 =20 Uri ("Oo-ree")=20 =20 =20 ------_=_NextPart_001_01C3D4E2.57E95916 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
 
 

Uri  ("Oo-ree") =

 

 
------_=_NextPart_001_01C3D4E2.57E95916-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Jan 7 10:56:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16247 for ; Wed, 7 Jan 2004 10:56:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeG2X-0001Ty-Kx for rddp-archive@odin.ietf.org; Wed, 07 Jan 2004 10:56:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07FuDl0005694 for rddp-archive@odin.ietf.org; Wed, 7 Jan 2004 10:56:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeG2X-0001Tl-GI for rddp-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 10:56:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16239 for ; Wed, 7 Jan 2004 10:56:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeG2U-0002D3-00 for rddp-web-archive@ietf.org; Wed, 07 Jan 2004 10:56:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeG0d-00028i-00 for rddp-web-archive@ietf.org; Wed, 07 Jan 2004 10:54:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeFzQ-00023y-00 for rddp-web-archive@ietf.org; Wed, 07 Jan 2004 10:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeFzR-0001Or-BM; Wed, 07 Jan 2004 10:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeFyi-0001OD-5h for rddp@optimus.ietf.org; Wed, 07 Jan 2004 10:52:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16137 for ; Wed, 7 Jan 2004 10:52:12 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeFyf-000222-00 for rddp@ietf.org; Wed, 07 Jan 2004 10:52:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeFwn-0001xR-00 for rddp@ietf.org; Wed, 07 Jan 2004 10:50:18 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1AeFvw-0001sT-00 for rddp@ietf.org; Wed, 07 Jan 2004 10:49:24 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jan 2004 10:48:34 -0500 Message-ID: To: rddp@ietf.org Date: Wed, 7 Jan 2004 10:48:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] Email administrivia: "Received:" headers and email management 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Since someone's been bitten by this, I thought I'd explain. IETF mailing list management software does not strip inbound email headers in messages sent to the list, which results in rddp email being delivered with more "Received:" headers (email hops) than one might expect - looking at a couple of recent messages, my copies have 10-12 "Received:" headers. Other people will see different counts depending on how many forwarding hops are involved in delivering their email. Most email delivery software counts "Received:" headers on incoming messages and rejects any inbound message whose count exceeds some threshold in order to break email forwarding loops. If that threshold is set too low, legitimate rddp messages will get rejected. Allowing a 2x safety/fudge factor, the threshold should be set to something like 25. This is *not* in email client software (e.g., Outlook, Eudora, Netscape Mail); it's in email delivery software (e.g., Exchange, sendmail) and can only be set/changed by the postmaster or administrator of that software. The IETF mailing list software counts email rejections - five in a row for any reason generally cause it to temporarily disable email delivery to the email address that generated those rejections. I get notified when this happens - the most common reason is that someone has left somewhere and their email address no longer works. I try to check these notifications and send email when I see something that shouldn't have disabled email. Everyone on the rddp list has an email configuration page at: https://www1.ietf.org/mailman/options/rddp/ Where is obtained by taking the email address that was subscribed to the list and substituting "--at--" for "@", e.g., mine is: https://www1.ietf.org/mailman/options/rddp/black_david--at--emc.com This is where to check to see if your email has been disabled, and to re-enable it. It also contains settings for digest vs. individual messages and a few other things. There's a button on this page to email your list password (needed to unsubscribe or make changes) to you. 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 exim@www1.ietf.org Tue Jan 13 01:28:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15525 for ; Tue, 13 Jan 2004 01:28:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgI2B-0006Sa-Rv for rddp-archive@odin.ietf.org; Tue, 13 Jan 2004 01:28:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0D6SFmF024829 for rddp-archive@odin.ietf.org; Tue, 13 Jan 2004 01:28:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgI2B-0006SO-Lg for rddp-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 01:28:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15513 for ; Tue, 13 Jan 2004 01:28:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgI28-0005BX-00 for rddp-web-archive@ietf.org; Tue, 13 Jan 2004 01:28:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgI0K-00057e-00 for rddp-web-archive@ietf.org; Tue, 13 Jan 2004 01:26:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgHz3-00054N-00 for rddp-web-archive@ietf.org; Tue, 13 Jan 2004 01:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgHz4-0006EU-Sp; Tue, 13 Jan 2004 01:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgHyP-0006D9-WC for rddp@optimus.ietf.org; Tue, 13 Jan 2004 01:24:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15409 for ; Tue, 13 Jan 2004 01:24:20 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgHyM-00052P-00 for rddp@ietf.org; Tue, 13 Jan 2004 01:24:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgHwW-00050A-00 for rddp@ietf.org; Tue, 13 Jan 2004 01:22:25 -0500 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by ietf-mx with esmtp (Exim 4.12) id 1AgHvx-0004xU-00 for rddp@ietf.org; Tue, 13 Jan 2004 01:21:49 -0500 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jan 2004 01:21:20 -0500 Message-ID: To: rddp@ietf.org Date: Tue, 13 Jan 2004 01:21:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] Mock WG Last Call on DDP & RDMAP drafts 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 WG members, During the rest of January, please review the DDP and RDMAP drafts: draft-ietf-rddp-ddp-01.txt draft-ietf-rddp-rdmap-01.txt While I can't do an actual WG Last Call on these drafts until the security draft is close to done, this would be a good time to check everything else about those drafts. Editorial comments can be sent directly to the principal authors, technical comments need to go to the list. The goal is to have versions of the drafts for Seoul that are ready-to-go except for security-related issues. Thanks, --David (rddp WG chair) ---------------------------------------------------- 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 exim@www1.ietf.org Thu Jan 15 16:45:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02515 for ; Thu, 15 Jan 2004 16:45:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFId-0004Au-Qy for rddp-archive@odin.ietf.org; Thu, 15 Jan 2004 16:45:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FLjBUo016042 for rddp-archive@odin.ietf.org; Thu, 15 Jan 2004 16:45:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFId-0004Af-Mw for rddp-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 16:45:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02436 for ; Thu, 15 Jan 2004 16:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFIb-00066F-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 16:45:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFGT-0005ei-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 16:43:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AhFE2-0005Be-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 16:40:26 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AhFDz-00037y-6v for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 16:40:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFDl-0003kJ-Ki; Thu, 15 Jan 2004 16:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFCw-0003hS-RJ for rddp@optimus.ietf.org; Thu, 15 Jan 2004 16:39:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01499 for ; Thu, 15 Jan 2004 16:39:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFCu-0004zb-00 for rddp@ietf.org; Thu, 15 Jan 2004 16:39:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFBi-0004qY-00 for rddp@ietf.org; Thu, 15 Jan 2004 16:38:03 -0500 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AhFAo-0004lv-00 for rddp@ietf.org; Thu, 15 Jan 2004 16:37:06 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.00) id A964A1D00CE; Thu, 15 Jan 2004 16:43:00 -0500 From: "Barry Reinhold" To: "Hemal Shah" Cc: "RDDP" Date: Thu, 15 Jan 2004 16:37:01 -0500 Message-ID: <002701c3dbaf$b6d02580$467fa8c0@i8600> 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, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [rddp] Some questions related to "last segment" of a ddp message 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hemal, I would like to check on a couple of issues: I believe that it is possible to RECEIVE a sequence of DDP segments using the untagged buffer model as follows: Let me know if this is not correct. Segment 1: QN=1, MSN=1, MO=200, L=0 (payload 100) (MO not 0 on first) Segment 2: QN=1, MSN=1, MO=200, L=0 (payload 100) (duplicate) Segment 3: QN=1, MSN=1, MO=100, L=0 (payload 100) (backward) Segment 4: QN=1, MSN=1, MO=000, L=0 (payload 050) (meets 6.3, MO field) Segment 5: QN=1, MSN=1, MO=400, L=1 (payload 000) (meets 6.1 L bit field) In particular, 1. If no packets have been received w/ a given MSN and QN and a packet arrives with a non-zero MO this is not an error. 2. The MO fields in intermediate segments are not constrained to be in order, can have gaps, and can write over buffer space already written to. Or from a test perspective, if a receiver returned an error when receiving the above sequence the receiver would be considered non-conformant. I am also a bit confused by the use of the term "last" in the draft. If the above is considered a valid sequence it is unclear to me how the receiver can meet the requirements of knowing that all DDP Segments of the DDP message have been placed before it "delivers" the DDP message to the ULP. (page 14 under L - Last flag, first bullet) Is there some method other than the L bit that indicates that all segments of a DDP message have been placed? (i.e. do implementations need to keep a scoreboard?) The draft (in clause 7.4, first *, on page 20) references a requirement on the receiver to deliver only when the last bit is set on the "last DDP Segment". How is the last segment defined beyond the L bit? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 15 19:15:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09914 for ; Thu, 15 Jan 2004 19:15:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHdU-00057O-RP for rddp-archive@odin.ietf.org; Thu, 15 Jan 2004 19:14:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G0Eq2I019665 for rddp-archive@odin.ietf.org; Thu, 15 Jan 2004 19:14:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHdU-000576-O5 for rddp-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 19:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09887 for ; Thu, 15 Jan 2004 19:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHdT-0006tu-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 19:14:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHcX-0006qT-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 19:13:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhHbe-0006nD-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 19:12:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHbe-00050y-ME; Thu, 15 Jan 2004 19:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHbW-00050g-VC for rddp@optimus.ietf.org; Thu, 15 Jan 2004 19:12:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09792 for ; Thu, 15 Jan 2004 19:12:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHbV-0006ly-00 for rddp@ietf.org; Thu, 15 Jan 2004 19:12:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHaZ-0006ih-00 for rddp@ietf.org; Thu, 15 Jan 2004 19:11:52 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AhHZl-0006e9-00 for rddp@ietf.org; Thu, 15 Jan 2004 19:11:01 -0500 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 98729245219; Thu, 15 Jan 2004 19:11:30 -0500 (EST) In-Reply-To: <002701c3dbaf$b6d02580$467fa8c0@i8600> References: <002701c3dbaf$b6d02580$467fa8c0@i8600> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63AC317E-47B8-11D8-9C0B-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit Cc: "Hemal Shah" , "RDDP" From: Caitlin Bestler Subject: Re: [rddp] Some questions related to "last segment" of a ddp message Date: Thu, 15 Jan 2004 18:10:27 -0600 To: "Barry Reinhold" X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Jan 15, 2004, at 3:37 PM, Barry Reinhold wrote: > Hemal, > > I would like to check on a couple of issues: > > I believe that it is possible to RECEIVE a sequence of DDP segments > using the untagged buffer model as follows: Let me know if this is not > correct. > > Segment 1: QN=1, MSN=1, MO=200, L=0 (payload 100) (MO not 0 on first) > Segment 2: QN=1, MSN=1, MO=200, L=0 (payload 100) (duplicate) Overlapping (or duplicate) segments strike me as very suspect for the following reasons: a) If there is any overlap in the segments of an untagged message there is no guarantee which placement will occur last. Hence there can be no benefit to sending two segments covering the same bytes within an untagged message. b) It is clear that an untagged message SHOULD be broken into ascending segments, each the maximum size allowed. There may be valid reasons for alternate segmenting schemes, but one that produces no reliable results cannot possibly be a valid justification for overriding a "SHOULD". This does NOT imply that the receiver should be checking for overlaps, merely that there is no reason to take heroic efforts to deal with problems caused by overlaps. > Segment 3: QN=1, MSN=1, MO=100, L=0 (payload 100) (backward) Segments SHOULD be sent in ascending order (a non-requirement that I opposed). As a sender you should only do this if you have a valid reason that optimizes something. As a receiver, of course, you have to presume that the sender had a valid reason. More importantly, if you are optimized to process segments out-of-order you will never even notice that it happened. > Segment 4: QN=1, MSN=1, MO=000, L=0 (payload 050) (meets 6.3, MO field) > Segment 5: QN=1, MSN=1, MO=400, L=1 (payload 000) (meets 6.1 L bit > field) > > In particular, > 1. If no packets have been received w/ a given MSN and QN and a packet > arrives with a non-zero MO this is not an error. > 2. The MO fields in intermediate segments are not constrained to be in > order, can have gaps, and can write over buffer space already written > to. Gaps are not explicitly forbidden. But it is important to understand that the result will be non-determinant bytes in the target buffer, NOT unmodified bytes. For an unordered receiver, this is all irrelevant. The simplest implementation is to simply place all non-terminal segments, set the length from the segment with the L bit set, and assume that the entire message was delivered when the final segment is eligible for delivery. Remember that the receiver is allowed to (perhaps expected to) process segments in the order they arrive, which is not necessarily their order in the LLP stream. Note: as a security issue, implementations SHOULD ensure that "non-determinant" bytes are not actually bytes holding values once held by buffers used in another process. This is only a factor if intermediate buffering is used for reasons relating to optimizing cache flushes. > Or from a test perspective, if a receiver returned an error when > receiving the above sequence the receiver would be considered > non-conformant. Correct. A receiver has no business trying to diagnose this type of behavior in real-time. > > I am also a bit confused by the use of the term "last" in the draft. > The "Last" segment in LLP sequence must have the highest MO. But as your example points out, this can be cheated with a zero length message. > If the above is considered a valid sequence it is unclear to me how the > receiver can meet the requirements of knowing that all DDP Segments of > the DDP message have been placed before it "delivers" the DDP message > to > the ULP. (page 14 under L - Last flag, first bullet) For any DDP segment, the DDP layer is expected to determine whether all prior DDP segments (in LLP stream sequence) have been placed and delivered before it can be delivered. Even if the "last" segment is not yet deliverable, its contents can be placed, and the message length can be noted for later delivery. > > Is there some method other than the L bit that indicates that all > segments of a DDP message have been placed? (i.e. do implementations > need to keep a scoreboard?) The draft (in clause 7.4, first *, on page > 20) references a requirement on the receiver to deliver only when the > last bit is set on the "last DDP Segment". How is the last segment > defined beyond the L bit? > The last segment has three characteristics: 1) L bit set. 2) Highest LLP Sequence 3) Highest MO within the message If all DDP Segments for the LLP Stream have been placed, the receiver may assume that all prior segments for this message have been placed. The fact that the "last" DDP Segment must have the highest sequence in the LLP Stream allows the receiver to make this assumption without keeping a scoreboard. It is NOT something that the receiver should be attempting to enforce. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 15 21:42:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14298 for ; Thu, 15 Jan 2004 21:42:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhJvk-0004Df-OF for rddp-archive@odin.ietf.org; Thu, 15 Jan 2004 21:41:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G2fqhb016213 for rddp-archive@odin.ietf.org; Thu, 15 Jan 2004 21:41:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhJvk-0004DQ-KM for rddp-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 21:41:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14295 for ; Thu, 15 Jan 2004 21:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhJvh-0005GD-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 21:41:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhJuo-0005F7-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 21:40:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhJtz-0005Di-00 for rddp-web-archive@ietf.org; Thu, 15 Jan 2004 21:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhJu0-0004AD-Ag; Thu, 15 Jan 2004 21:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhJts-00048l-6U for rddp@optimus.ietf.org; Thu, 15 Jan 2004 21:39:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14263 for ; Thu, 15 Jan 2004 21:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhJtp-0005CQ-00 for rddp@ietf.org; Thu, 15 Jan 2004 21:39:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhJsu-0005Aq-00 for rddp@ietf.org; Thu, 15 Jan 2004 21:38:57 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AhJsQ-00058P-00 for rddp@ietf.org; Thu, 15 Jan 2004 21:38:26 -0500 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 2D92D244898 for ; Thu, 15 Jan 2004 21:38:58 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] "Last Call" on DDP draft: Error Codes Date: Thu, 15 Jan 2004 20:37:55 -0600 To: RDDP X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have a minor concern on the The DDP Error Codes defined in section 9.2 (and used in the RDMAP terminate message). In general terms, the draft should clarify that a given packet may have error conditions that comply with more than one of the error codes listed, and in that case the implementation may select any of the correct error codes, even if it is not the "best" error code. My specific concern is with the distinction between "Invalid STag" and "STag not associated with DDP Stream". It implies that an STag can be "valid", but just not on the current stream. For many implementations and local interfaces that is indeed a valid distinction. However, it should be made clear that the existence of distinct error codes does not mandate that design. If the STag is not valid on the specific stream for the use attempted, the implementation should be free to simply use the "STag not associated with DDP Stream" error regardless of whether the STag is valid for other uses possibly on other DDP Streams. Indeed, a better description of the error would be "STag is not valid for use attempted." The rationale: 1) Providing any information about other streams is a violation of generally accepted security practices. Differentiating between "Invalid STag" and "STag not valid here" is akin to differentiating between "no such user" and "wrong password". 2) STag validation may be scoped to the DDP Stream and/or Protection Domain. Determining whether or not the STag is valid *anywhere* may require additional work. 3) STag validation may be handled distinctly for RDMA Read Responses, in which case the receiver only knows that the STag supplied is invalid as an RDMA Read Response on this DDP Stream at this moment. Similarly, for untagged buffer errors: if the MSN is out of range an implementation may or may not know -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Jan 16 09:44:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15867 for ; Fri, 16 Jan 2004 09:44:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVCX-0004l2-FG for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 09:43:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GEhv1E018284 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 09:43:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVCX-0004kp-Bi for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 09:43:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15850 for ; Fri, 16 Jan 2004 09:43:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhVCV-00008s-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 09:43:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhVBZ-00001G-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 09:42:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AhVAj-0007hY-01 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 09:42:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AhVAj-0000aN-O0 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 09:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVAe-0004dE-U1; Fri, 16 Jan 2004 09:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVA9-0004bJ-Ib for rddp@optimus.ietf.org; Fri, 16 Jan 2004 09:41:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15746 for ; Fri, 16 Jan 2004 09:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhVA6-0007fm-00 for rddp@ietf.org; Fri, 16 Jan 2004 09:41:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhV9H-0007bk-00 for rddp@ietf.org; Fri, 16 Jan 2004 09:40:35 -0500 Received: from ammasso.com ([66.228.85.228] helo=mail2.ammasso.com) by ietf-mx with esmtp (Exim 4.12) id 1AhV8H-0007Rt-00 for rddp@ietf.org; Fri, 16 Jan 2004 09:39:33 -0500 Received: from fid4.com ([10.0.1.92]) by mail2.ammasso.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jan 2004 09:38:57 -0500 Message-ID: <4007F781.7080709@fid4.com> Date: Fri, 16 Jan 2004 09:38:57 -0500 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: RDDP CC: Barry Reinhold Subject: Re: [rddp] Some questions related to "last segment" of a ddp message References: <002701c3dbaf$b6d02580$467fa8c0@i8600> In-Reply-To: <002701c3dbaf$b6d02580$467fa8c0@i8600> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2004 14:38:57.0651 (UTC) FILETIME=[793B2C30:01C3DC3E] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Barry Reinhold wrote: > Hemal, > > I would like to check on a couple of issues: > > I believe that it is possible to RECEIVE a sequence of DDP segments > using the untagged buffer model as follows: Let me know if this is not > correct. > > Segment 1: QN=1, MSN=1, MO=200, L=0 (payload 100) (MO not 0 on first) > Segment 2: QN=1, MSN=1, MO=200, L=0 (payload 100) (duplicate) > Segment 3: QN=1, MSN=1, MO=100, L=0 (payload 100) (backward) > Segment 4: QN=1, MSN=1, MO=000, L=0 (payload 050) (meets 6.3, MO field) > Segment 5: QN=1, MSN=1, MO=400, L=1 (payload 000) (meets 6.1 L bit > field) > > In particular, > 1. If no packets have been received w/ a given MSN and QN and a packet > arrives with a non-zero MO this is not an error. > 2. The MO fields in intermediate segments are not constrained to be in > order, can have gaps, and can write over buffer space already written > to. My understanding is yes, yes and (re write over buffer space) not convinced. On pg 20 of draft-ietf-rddp-ddp-01.txt, "For an Untagged DDP Message, the combination of the QN and MSN uniquely identifies a DDP Message." Since an MSN doesn't make sense for a DDP _message_, I've read this to mean that QN & MSN uniquely identifies a DDP _segment_. So the way I read the draft, I can't find text that says one cannot send overlapping DDP segments. > Or from a test perspective, if a receiver returned an error when > receiving the above sequence the receiver would be considered > non-conformant. I'd return an error for several reasons. 1) I know of no legal untagged message on QN=1 that has a payload as large as you describe. 2) Where are payload bytes 50-99? 300-399? If I understand the example correctly, segment 4 provides DDP/RDMA message bytes 0-49; segment 3 provides 100-199, segments 1 & 2 provide 200-300 MikeC _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Jan 16 10:37:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18612 for ; Fri, 16 Jan 2004 10:37:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhW2I-0007jY-Je for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 10:37:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GFbQUx029690 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 10:37:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhW2G-0007ie-F8 for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 10:37:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18602 for ; Fri, 16 Jan 2004 10:37:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhW2E-0003Po-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 10:37:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhW1K-0003NJ-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 10:36:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhW0w-0003Kt-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 10:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhW0w-0007Uz-Fc; Fri, 16 Jan 2004 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhW0G-0007Tz-CH for rddp@optimus.ietf.org; Fri, 16 Jan 2004 10:35:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18546 for ; Fri, 16 Jan 2004 10:35:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhW0D-0003Iv-00 for rddp@ietf.org; Fri, 16 Jan 2004 10:35:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhVzJ-0003G9-00 for rddp@ietf.org; Fri, 16 Jan 2004 10:34:22 -0500 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 1AhVyj-0003Ae-00 for rddp@ietf.org; Fri, 16 Jan 2004 10:33:45 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 2A9B0AC76; Fri, 16 Jan 2004 09:33:13 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jan 2004 09:33:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Date: Fri, 16 Jan 2004 09:32:58 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762C981B89@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] Some questions related to "last segment" of a ddp message Thread-Index: AcPcQSaECj4NL/F5RhmcGXvVRiEx0wAAY3LA From: "Culley, Paul" To: "Michael C. Cambria" , "RDDP" Cc: "Barry Reinhold" X-OriginalArrivalTime: 16 Jan 2004 15:33:07.0228 (UTC) FILETIME=[0A2145C0:01C3DC46] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable A couple of points are included below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Michael C. Cambria Sent: Friday, January 16, 2004 8:39 AM To: RDDP Cc: Barry Reinhold Subject: Re: [rddp] Some questions related to "last segment" of a ddp message Barry Reinhold wrote: > Hemal, >=20 > I would like to check on a couple of issues: >=20 > I believe that it is possible to RECEIVE a sequence of DDP segments=20 > using the untagged buffer model as follows: Let me know if this is not > correct. >=20 > Segment 1: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (MO not 0 on = first)=20 > Segment 2: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (duplicate) = Segment=20 > 3: QN=3D1, MSN=3D1, MO=3D100, L=3D0 (payload 100) (backward) Segment = 4: QN=3D1,=20 > MSN=3D1, MO=3D000, L=3D0 (payload 050) (meets 6.3, MO field) Segment = 5:=20 > QN=3D1, MSN=3D1, MO=3D400, L=3D1 (payload 000) (meets 6.1 L bit > field) >=20 > In particular, > 1. If no packets have been received w/ a given MSN and QN and a packet > arrives with a non-zero MO this is not an error. > 2. The MO fields in intermediate segments are not constrained to be in > order, can have gaps, and can write over buffer space already written > to. My understanding is yes, yes and (re write over buffer space) not convinced. On pg 20 of draft-ietf-rddp-ddp-01.txt, "For an Untagged DDP Message,=20 the combination of the QN and MSN uniquely identifies a DDP Message."=20 Since an MSN doesn't make sense for a DDP _message_, I've read this to=20 mean that QN & MSN uniquely identifies a DDP _segment_. [prc] I suspect some misunderstanding here. An MSN (Message Sequence Number) specifically identifies which _message_ on the particular Queue the segment belongs to. Think of a queue with 5 2000 byte buffers, If TCP can manage=20 1500 bytes or so per segment, each buffer can hold two segments. The two segments for the second buffer might be identified by QN=3D1, = MSN=3D2, MO=3D0, L=3D1500 and QN=3D1, MSN=3D2, MO=3D1500, L=3D500. The two = segments have the same MSN, so your statement is not correct. [prc] So the way I read the draft, I can't find text that says one cannot send overlapping DDP segments. > Or from a test perspective, if a receiver returned an error when=20 > receiving the above sequence the receiver would be considered=20 > non-conformant. I'd return an error for several reasons. 1) I know of no legal untagged message on QN=3D1 that has a payload as=20 large as you describe. [prc] for DDP, all QN values are legal, and only the ULP can place limits on their size, what you say is true only if you are using RDMA as the next up ULP. [prc] 2) Where are payload bytes 50-99? 300-399? [prc] The receiver is not expected to check for overlaps, or holes in the data. So this is not a valid reason to report errors and there are no defined errors for this. Perhaps the draft should explicitly say not to report errors for these cases. As long as all the transmitter's data was placed and delivered, the receiver is compliant. In the case of overlaps, the receiver is not even required to make sure that the highest TCP sequence numbered segment was the last placed, so overlaps could lead to unpredictable delivered data. As a consequence of this, the transmitter SHOULD send data with no overlaps or holes, although an application could conceivably be designed to work even if this is not followed (some kind of test suite?). [prc] If I understand the example correctly, segment 4 provides DDP/RDMA=20 message bytes 0-49; segment 3 provides 100-199, segments 1 & 2 provide=20 200-300 [prc] one last comment; segment 5 (with zero length) is legal, and must be delivered. Further, even if no other data for the message arrived, the zero length message does consume an untagged buffer. [prc] MikeC _______________________________________________ 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 exim@www1.ietf.org Fri Jan 16 11:53:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21219 for ; Fri, 16 Jan 2004 11:53:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXDA-0003vu-FA for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 11:52:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GGqiLd015112 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 11:52:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXDA-0003vf-Aj for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 11:52:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21201 for ; Fri, 16 Jan 2004 11:52:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXD4-00008v-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 11:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXAt-00005F-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 11:50:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhXAb-00002w-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 11:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXAZ-0003sA-AE; Fri, 16 Jan 2004 11:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhX9s-0003qC-LK for rddp@optimus.ietf.org; Fri, 16 Jan 2004 11:49:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21126 for ; Fri, 16 Jan 2004 11:49:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhX9r-000011-00 for rddp@ietf.org; Fri, 16 Jan 2004 11:49:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhX8t-0007lq-00 for rddp@ietf.org; Fri, 16 Jan 2004 11:48:20 -0500 Received: from ammasso.com ([66.228.85.228] helo=mail2.ammasso.com) by ietf-mx with esmtp (Exim 4.12) id 1AhX86-0007hz-00 for rddp@ietf.org; Fri, 16 Jan 2004 11:47:31 -0500 Received: from fid4.com ([10.0.1.92]) by mail2.ammasso.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jan 2004 11:46:56 -0500 Message-ID: <40081580.2060806@fid4.com> Date: Fri, 16 Jan 2004 11:46:56 -0500 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Culley, Paul" CC: RDDP , Barry Reinhold Subject: Re: [rddp] Some questions related to "last segment" of a ddp message References: <4D027986353D1341ADA4F2A4F8A170762C981B89@cceexc18.americas.cpqcorp.net> In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762C981B89@cceexc18.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2004 16:46:56.0662 (UTC) FILETIME=[5A474360:01C3DC50] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Culley, Paul wrote: > A couple of points are included below... > > Paul R. Culley > HP Fellow > 281-514-5543 > > > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of > Michael C. Cambria > Sent: Friday, January 16, 2004 8:39 AM > To: RDDP > Cc: Barry Reinhold > Subject: Re: [rddp] Some questions related to "last segment" of a ddp > message > > > > > Barry Reinhold wrote: > > >>Hemal, >> >>I would like to check on a couple of issues: >> >>I believe that it is possible to RECEIVE a sequence of DDP segments >>using the untagged buffer model as follows: Let me know if this is not > > >>correct. >> >>Segment 1: QN=1, MSN=1, MO=200, L=0 (payload 100) (MO not 0 on first) >>Segment 2: QN=1, MSN=1, MO=200, L=0 (payload 100) (duplicate) Segment >>3: QN=1, MSN=1, MO=100, L=0 (payload 100) (backward) Segment 4: QN=1, >>MSN=1, MO=000, L=0 (payload 050) (meets 6.3, MO field) Segment 5: >>QN=1, MSN=1, MO=400, L=1 (payload 000) (meets 6.1 L bit >>field) >> >>In particular, >>1. If no packets have been received w/ a given MSN and QN and a packet >>arrives with a non-zero MO this is not an error. >>2. The MO fields in intermediate segments are not constrained to be in >>order, can have gaps, and can write over buffer space already written >>to. > > > My understanding is yes, yes and (re write over buffer space) not > convinced. > > On pg 20 of draft-ietf-rddp-ddp-01.txt, "For an Untagged DDP Message, > the combination of the QN and MSN uniquely identifies a DDP Message." > Since an MSN doesn't make sense for a DDP _message_, I've read this to > mean that QN & MSN uniquely identifies a DDP _segment_. > [prc] I suspect some misunderstanding here. An MSN (Message Sequence > Number) > specifically identifies which _message_ on the particular Queue the > segment > belongs to. Think of a queue with 5 2000 byte buffers, If TCP can > manage > 1500 bytes or so per segment, each buffer can hold two segments. The > two segments for the second buffer might be identified by QN=1, MSN=2, > MO=0, L=1500 and QN=1, MSN=2, MO=1500, L=500. The two segments have the > same MSN, so your statement is not correct. > [prc] I was confused. I understand what you describe above, but read more into it (e.g. applying to uniquely identify a DDP segment as well). Until know, I didn't think overlaps were possible. Thanks, MikeC > So the way I read the draft, I can't find text that says one cannot send > > overlapping DDP segments. This should have been "the way the draft reads". My reading (which is incorrect) ruled out overlaps. Thanks, MikeC _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Jan 16 12:29:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22255 for ; Fri, 16 Jan 2004 12:29:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXlp-0006Kf-PZ for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 12:28:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GHSX39024335 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 12:28:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXlo-0006KQ-92 for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 12:28:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22252 for ; Fri, 16 Jan 2004 12:28:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXlm-0001vB-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 12:28:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXko-0001rQ-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 12:27:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhXkK-0001oE-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 12:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXkL-0006H5-2a; Fri, 16 Jan 2004 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXjh-0006GJ-Rl for rddp@optimus.ietf.org; Fri, 16 Jan 2004 12:26:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22205 for ; Fri, 16 Jan 2004 12:26:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXjg-0001mS-00 for rddp@ietf.org; Fri, 16 Jan 2004 12:26:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXik-0001j4-00 for rddp@ietf.org; Fri, 16 Jan 2004 12:25:23 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AhXht-0001cT-00 for rddp@ietf.org; Fri, 16 Jan 2004 12:24:29 -0500 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 4410B24547E; Fri, 16 Jan 2004 12:24:59 -0500 (EST) In-Reply-To: <40081580.2060806@fid4.com> References: <4D027986353D1341ADA4F2A4F8A170762C981B89@cceexc18.americas.cpqcorp.net> <40081580.2060806@fid4.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Culley, Paul" , Barry Reinhold , RDDP From: Caitlin Bestler Subject: Re: [rddp] Some questions related to "last segment" of a ddp message Date: Fri, 16 Jan 2004 11:23:56 -0600 To: "Michael C. Cambria" X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Jan 16, 2004, at 10:46 AM, Michael C. Cambria wrote: > > >> So the way I read the draft, I can't find text that says one cannot >> send >> overlapping DDP segments. > > This should have been "the way the draft reads". My reading (which is > incorrect) ruled out overlaps. > To be precise, there are two distinct issues. Can a sender create overlapping segments within a message, and whether the receiver is under any obligation to check for this. From the sender's perspective, the TO SHOULD be in ascending order and segmentation SHOULD be based upon the PMTU. Shifting from the obvious segmentation strategy is legal, but only if the sender has a valid reason for doing so. Given that overlapped messages does not produce a predictable result there can be no valid reason for doing this. On the receiving end, this is something that the receiver SHOULD NOT be checking. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Jan 16 14:20:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25170 for ; Fri, 16 Jan 2004 14:20:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZVX-0005aW-JG for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 14:19:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GJJpNB021474 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 14:19:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZVW-0005aG-2y for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 14:19:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25156 for ; Fri, 16 Jan 2004 14:19:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZVO-0007KS-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 14:19:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZSd-0007AC-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 14:16:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZQ3-00070g-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 14:14:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZPt-0005AT-Sh; Fri, 16 Jan 2004 14:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZPU-00059o-1b for rddp@optimus.ietf.org; Fri, 16 Jan 2004 14:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25015 for ; Fri, 16 Jan 2004 14:13:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZPI-0006xd-00 for rddp@ietf.org; Fri, 16 Jan 2004 14:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZLu-0006pK-00 for rddp@ietf.org; Fri, 16 Jan 2004 14:09:55 -0500 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AhZLI-0006lD-00 for rddp@ietf.org; Fri, 16 Jan 2004 14:09:16 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.00) id A82833D80132; Fri, 16 Jan 2004 14:14:48 -0500 From: "Barry Reinhold" To: "RDDP" Date: Fri, 16 Jan 2004 14:08:49 -0500 Message-ID: <000601c3dc64$2c913520$467fa8c0@i8600> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [rddp] DDP segment sequences for Untagged DDP message 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP 1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid MO 1. QN = 0, MSN = 1, MO = 0, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP 1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 200, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP 1. QN = 0, MSN = 1, MO = 300, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) 1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 000, L = 1, Payload = 0 bytes Result: ULP sent Error type=Untagged Buffer Error, Error Code = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) 1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Jan 16 15:32:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27901 for ; Fri, 16 Jan 2004 15:32:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahacy-00065Z-3W for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 15:31:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GKVa7s023404 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 15:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahacy-00065P-0B for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 15:31:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27895 for ; Fri, 16 Jan 2004 15:31:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahacw-0003Jc-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 15:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahac3-0003Gb-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 15:30:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhabT-0003Cv-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 15:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhabS-0005qa-Ux; Fri, 16 Jan 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahab6-0005lc-Lk for rddp@optimus.ietf.org; Fri, 16 Jan 2004 15:29:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27788 for ; Fri, 16 Jan 2004 15:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahab5-0003CO-00 for rddp@ietf.org; Fri, 16 Jan 2004 15:29:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahaa8-00039E-00 for rddp@ietf.org; Fri, 16 Jan 2004 15:28:40 -0500 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 1AhaZl-00035H-00 for rddp@ietf.org; Fri, 16 Jan 2004 15:28:18 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 563F8C1B3; Fri, 16 Jan 2004 14:27:46 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jan 2004 14:27:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Fri, 16 Jan 2004 14:27:43 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762C981C0A@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPcZTID+wGTmacKQMqT3TmFgCcOAAACMPyg From: "Culley, Paul" To: "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 16 Jan 2004 20:27:46.0193 (UTC) FILETIME=[339D4010:01C3DC6F] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=3D99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. 1. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 200, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). 1. QN =3D 0, MSN =3D 1, MO =3D 300, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 1, Payload =3D 0 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error Code =3D = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP.=20 [prc], yes, but with unknown data values. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Fri Jan 16 16:18:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29524 for ; Fri, 16 Jan 2004 16:18:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhbM6-0002OI-VO for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 16:18:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GLIEp4009184 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 16:18:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhbM6-0002Nz-Qs for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 16:18:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29484 for ; Fri, 16 Jan 2004 16:18:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhbLy-0005L9-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 16:18:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhbIV-0005Cw-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 16:14:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhbHK-00056n-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 16:13:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhbH2-0001rN-VN; Fri, 16 Jan 2004 16:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhbG9-0001aG-HE for rddp@optimus.ietf.org; Fri, 16 Jan 2004 16:12:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29250 for ; Fri, 16 Jan 2004 16:11:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhbFq-00053V-00 for rddp@ietf.org; Fri, 16 Jan 2004 16:11:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhbE3-0004yD-00 for rddp@ietf.org; Fri, 16 Jan 2004 16:09:56 -0500 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AhbBC-0004px-00 for rddp@ietf.org; Fri, 16 Jan 2004 16:06:58 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.00) id A3BF1B9E00D2; Fri, 16 Jan 2004 16:12:31 -0500 From: "Barry Reinhold" To: "RDDP" Subject: FW: [rddp] DDP segment sequences for Untagged DDP message Date: Fri, 16 Jan 2004 16:06:31 -0500 Message-ID: <000c01c3dc74$9ee68390$467fa8c0@i8600> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Oops, forgot to post to reflector... -----Original Message----- From: Barry Reinhold [mailto:bbr@lampreynetworks.com] Sent: Friday, January 16, 2004 3:41 PM To: 'Culley, Paul' Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Paul, How do you understand clause 6.1 under the description of the L bit, which reads... The DDP Segment with the L bit set to 1 MUST be posted to the LLP after all other DDP Segments of the associated DDP Message have been posted to the LLP. For an Untagged DDP Message, the DDP Segment with the L bit set to 1 MUST carry the highest MO. The second segment w/ L=1 arrives, but its MO is not the highest MO. What happens (as in the case below) when this condition is not true? >1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes >2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes >Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid MO >[prc] No, the receiver will place both segments, but inform the ULP that >only 100 bytes was delivered, ending at MO=99. No error should be detected >or reported, unless the receiver's buffer was not large enough to hold the >second 100 bytes. -----Original Message----- From: Culley, Paul [mailto:paul.culley@hp.com] Sent: Friday, January 16, 2004 3:28 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes 1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. 1. QN = 0, MSN = 1, MO = 0, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. 1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 200, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). 1. QN = 0, MSN = 1, MO = 300, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown 1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 000, L = 1, Payload = 0 bytes Result: ULP sent Error type=Untagged Buffer Error, Error Code = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. 1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP. [prc], yes, but with unknown data values. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ 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 exim@www1.ietf.org Fri Jan 16 17:24:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02506 for ; Fri, 16 Jan 2004 17:24:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhcNp-0008NY-K7 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 17:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GMO5tn032204 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 17:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhcNp-0008NL-E6 for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 17:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02497 for ; Fri, 16 Jan 2004 17:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhcNk-0001A7-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 17:24:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhcMM-000142-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 17:22:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhcKE-0000uR-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 17:20:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhcJu-0008CS-86; Fri, 16 Jan 2004 17:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhcJf-0008AT-H7 for rddp@optimus.ietf.org; Fri, 16 Jan 2004 17:19:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02337 for ; Fri, 16 Jan 2004 17:19:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhcJT-0000sW-00 for rddp@ietf.org; Fri, 16 Jan 2004 17:19:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhcFs-0000ff-00 for rddp@ietf.org; Fri, 16 Jan 2004 17:15:54 -0500 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 1AhcBn-0000K6-00 for rddp@ietf.org; Fri, 16 Jan 2004 17:11:39 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 09120BC21; Fri, 16 Jan 2004 16:10:36 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jan 2004 16:09:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Fri, 16 Jan 2004 16:09:56 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762C981C46@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPcdZcvUms5APnlQsGoHGuDlFKQqAABna2g From: "Culley, Paul" To: "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 16 Jan 2004 22:09:59.0307 (UTC) FILETIME=[7B3C2DB0:01C3DC7D] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I stand by my response below; the case described is a technical violation by the transmitter, however the receiver is not required to (and I think should not) detect this case. Because the transmitter violated the spec, the receiver is not required to indicate the full amount of data placed in the buffer. The spec was written this way to avoid making the receiver scoreboard or perform a MAX operation on MO+L to determine the size of the message delivered and that it was filling the buffer without gaps. Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 3:07 PM To: RDDP Subject: FW: [rddp] DDP segment sequences for Untagged DDP message Oops, forgot to post to reflector... -----Original Message----- From: Barry Reinhold [mailto:bbr@lampreynetworks.com]=20 Sent: Friday, January 16, 2004 3:41 PM To: 'Culley, Paul' Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Paul, How do you understand clause 6.1 under the description of the L bit, which reads... The DDP Segment with the L bit set to 1 MUST be posted to the=20 LLP after all other DDP Segments of the associated DDP Message=20 have been posted to the LLP. For an Untagged DDP Message, the=20 DDP Segment with the L bit set to 1 MUST carry the highest MO. The second segment w/ L=3D1 arrives, but its MO is not the highest MO. What happens (as in the case below) when this condition is not true? >1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes >2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes >Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO >[prc] No, the receiver will place both segments, but inform the ULP that >only 100 bytes was delivered, ending at MO=3D99. No error should = be detected >or reported, unless the receiver's buffer was not large enough to hold the >second 100 bytes. -----Original Message----- From: Culley, Paul [mailto:paul.culley@hp.com]=20 Sent: Friday, January 16, 2004 3:28 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=3D99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. 1. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 200, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). 1. QN =3D 0, MSN =3D 1, MO =3D 300, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 1, Payload =3D 0 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error Code =3D = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP.=20 [prc], yes, but with unknown data values. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Fri Jan 16 19:47:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07871 for ; Fri, 16 Jan 2004 19:47:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahebm-0008Mg-0R for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 19:46:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H0kbDF032151 for rddp-archive@odin.ietf.org; Fri, 16 Jan 2004 19:46:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahebl-0008MT-Qv for rddp-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 19:46:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07837 for ; Fri, 16 Jan 2004 19:46:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahebj-0000m2-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 19:46:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aheap-0000ju-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 19:45:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AheaE-0000hX-00 for rddp-web-archive@ietf.org; Fri, 16 Jan 2004 19:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AheaF-0008E2-29; Fri, 16 Jan 2004 19:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AheZq-0008DK-NR for rddp@optimus.ietf.org; Fri, 16 Jan 2004 19:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07800 for ; Fri, 16 Jan 2004 19:44:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AheZo-0000gZ-00 for rddp@ietf.org; Fri, 16 Jan 2004 19:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AheYs-0000eO-00 for rddp@ietf.org; Fri, 16 Jan 2004 19:43:38 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AheYH-0000Zs-00 for rddp@ietf.org; Fri, 16 Jan 2004 19:43:01 -0500 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 433E8245C11; Fri, 16 Jan 2004 19:43:32 -0500 (EST) In-Reply-To: <000601c3dc64$2c913520$467fa8c0@i8600> References: <000601c3dc64$2c913520$467fa8c0@i8600> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <07A2678E-4886-11D8-9C0B-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit Cc: Barry Reinhold From: Caitlin Bestler Subject: Re: [rddp] DDP segment sequences for Untagged DDP message Date: Fri, 16 Jan 2004 18:42:29 -0600 To: RDDP X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Jan 16, 2004, at 1:08 PM, Barry Reinhold wrote: > > So, is there agreement, for the sequences that follow, that the > specified "result" given below is the correct (and desired?) behavior > as > defined by the 01 draft. > > Untagged DDP Segment Sequences: > > 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes > 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes > Result: DDP Message (bytes 0-200) is delivered to ULP > Did you mean to set the 'L' bit on message 1? If so, that is a sender violation, which as explained in Paul's response may or may not be caught by the receiver. If Msg 1 is completed *before* Msg 2 is placed, Msg 2 will be rejected as having an invalid MSN (it would be taken as being 2**32-1 ahead of the current location). In either case a 200 byte receive will be reported to the ULP. The question is whether the Stream is almost immediately thereafter torn down. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon Jan 19 11:54:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27465 for ; Mon, 19 Jan 2004 11:54:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aicew-0004pl-IN for rddp-archive@odin.ietf.org; Mon, 19 Jan 2004 11:53:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JGrsFD018575 for rddp-archive@odin.ietf.org; Mon, 19 Jan 2004 11:53:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aicew-0004pW-DS for rddp-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 11:53:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27354 for ; Mon, 19 Jan 2004 11:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aicev-0004DG-00 for rddp-web-archive@ietf.org; Mon, 19 Jan 2004 11:53:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aicdo-00040K-00 for rddp-web-archive@ietf.org; Mon, 19 Jan 2004 11:52:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiccA-0003ez-00 for rddp-web-archive@ietf.org; Mon, 19 Jan 2004 11:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aicc9-0004iF-3Y; Mon, 19 Jan 2004 11:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AicbS-0004fH-RF for rddp@optimus.ietf.org; Mon, 19 Jan 2004 11:50:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26841 for ; Mon, 19 Jan 2004 11:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AicbR-0003VL-00 for rddp@ietf.org; Mon, 19 Jan 2004 11:50:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AicZe-00038C-00 for rddp@ietf.org; Mon, 19 Jan 2004 11:48:26 -0500 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AicXq-0002iP-00 for rddp@ietf.org; Mon, 19 Jan 2004 11:46:35 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.00) id AB54F0E40136; Mon, 19 Jan 2004 11:52:36 -0500 From: "Barry Reinhold" To: "Hemal Shah" Cc: "RDDP" Date: Mon, 19 Jan 2004 11:46:31 -0500 Message-ID: <000801c3deab$caf67830$467fa8c0@i8600> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [rddp] Tagged vs Untagged wrt providing message length 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hemal (or whomever wishes to post), Clause 7.4 states that: "At the Data Sink, DDP MUST provide the ULP Message Length to the ULP when an Untagged DDP Message is Delivered." Is it thus not required that the length be provided for Tagged DDP messages? I guess I am unclear as to why length is needed for the untagged but not for the tagged. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon Jan 19 14:36:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03967 for ; Mon, 19 Jan 2004 14:36:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifCI-0006sp-T6 for rddp-archive@odin.ietf.org; Mon, 19 Jan 2004 14:36:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JJaU64026455 for rddp-archive@odin.ietf.org; Mon, 19 Jan 2004 14:36:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifCI-0006sc-Pc for rddp-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 14:36:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03948 for ; Mon, 19 Jan 2004 14:36:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AifCB-0006nF-00 for rddp-web-archive@ietf.org; Mon, 19 Jan 2004 14:36:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aif9I-0006Z9-00 for rddp-web-archive@ietf.org; Mon, 19 Jan 2004 14:33:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aif5G-0006Gx-00 for rddp-web-archive@ietf.org; Mon, 19 Jan 2004 14:29:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aif52-0006Ji-LL; Mon, 19 Jan 2004 14:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aif4I-0006IK-FF for rddp@optimus.ietf.org; Mon, 19 Jan 2004 14:28:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03568 for ; Mon, 19 Jan 2004 14:28:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aif45-0006Bb-00 for rddp@ietf.org; Mon, 19 Jan 2004 14:28:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiez7-0005nj-00 for rddp@ietf.org; Mon, 19 Jan 2004 14:22:53 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1Aieuk-0005Jx-00 for rddp@ietf.org; Mon, 19 Jan 2004 14:18:22 -0500 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 161B0244B0B; Mon, 19 Jan 2004 14:18:24 -0500 (EST) In-Reply-To: <000801c3deab$caf67830$467fa8c0@i8600> References: <000801c3deab$caf67830$467fa8c0@i8600> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B34301E-4AB4-11D8-AE8C-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit Cc: Barry Reinhold From: Caitlin Bestler Subject: Re: [rddp] Tagged vs Untagged wrt providing message length Date: Mon, 19 Jan 2004 13:17:21 -0600 To: RDDP X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Jan 19, 2004, at 10:46 AM, Barry Reinhold wrote: > Hemal (or whomever wishes to post), > Clause 7.4 states that: > > "At the Data Sink, DDP MUST provide the ULP Message Length to the ULP > when an Untagged DDP Message is Delivered." > > Is it thus not required that the length be provided for Tagged DDP > messages? > > I guess I am unclear as to why length is needed for the untagged but > not > for the tagged. > > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > Normally DDP provides no notification of tagged placements to the ULP -- except that delivery of an untagged message cannot take place until all *prior* tagged messages have been fully placed. Further, even though the standard does not state that the DDP layer MUST NOT tell the ULP about individual tagged placements, the ULP MUST NOT use the buffers until the trailing untagged message is delivered. So there wouldn't be any point in supplying that information. The benefits of suppressing ULP interactions for tagged messages is covered in the applicability statement. http://www.ietf.org/internet-drafts/draft-ietf-rddp-applicability-01.txt -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Jan 20 10:08:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02621 for ; Tue, 20 Jan 2004 10:08:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixUM-0003ml-PZ for rddp-archive@odin.ietf.org; Tue, 20 Jan 2004 10:08:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KF8LFj014534 for rddp-archive@odin.ietf.org; Tue, 20 Jan 2004 10:08:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixUL-0003mJ-Dw for rddp-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 10:08:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02594 for ; Tue, 20 Jan 2004 10:08:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AixUJ-0004Wh-00 for rddp-web-archive@ietf.org; Tue, 20 Jan 2004 10:08:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AixTL-0004Tw-00 for rddp-web-archive@ietf.org; Tue, 20 Jan 2004 10:07:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AixSQ-0004RV-00 for rddp-web-archive@ietf.org; Tue, 20 Jan 2004 10:06:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixS7-0002mQ-K5; Tue, 20 Jan 2004 10:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixRO-0002dK-Gr for rddp@optimus.ietf.org; Tue, 20 Jan 2004 10:05:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02412; Tue, 20 Jan 2004 10:05:14 -0500 (EST) Message-Id: <200401201505.KAA02412@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rddp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 20 Jan 2004 10:05:14 -0500 Subject: [rddp] I-D ACTION:draft-ietf-rddp-arch-04.txt 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : The Architecture of Direct Data Placement (DDP)And Remote Direct Memory Access (RDMA)On Internet Protocols Author(s) : S. Bailey, T. Talpey Filename : draft-ietf-rddp-arch-04.txt Pages : 20 Date : 2004-1-19 This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g. RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-arch-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-arch-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-arch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-20102736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-arch-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-arch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20102736.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Jan 20 10:08:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02638 for ; Tue, 20 Jan 2004 10:08:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixUO-0003nF-MN for rddp-archive@odin.ietf.org; Tue, 20 Jan 2004 10:08:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KF8O9g014572 for rddp-archive@odin.ietf.org; Tue, 20 Jan 2004 10:08:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixUM-0003mk-N3 for rddp-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 10:08:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02602 for ; Tue, 20 Jan 2004 10:08:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AixUK-0004Ws-00 for rddp-web-archive@ietf.org; Tue, 20 Jan 2004 10:08:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AixTN-0004UC-00 for rddp-web-archive@ietf.org; Tue, 20 Jan 2004 10:07:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AixSR-0004RW-00 for rddp-web-archive@ietf.org; Tue, 20 Jan 2004 10:06:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixS6-0002lo-Qs; Tue, 20 Jan 2004 10:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixRG-0002bP-Qn for rddp@optimus.ietf.org; Tue, 20 Jan 2004 10:05:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02394; Tue, 20 Jan 2004 10:05:07 -0500 (EST) Message-Id: <200401201505.KAA02394@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rddp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 20 Jan 2004 10:05:06 -0500 Subject: [rddp] I-D ACTION:draft-ietf-rddp-problem-statement-03.txt 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : RDMA over IP Problem Statement Author(s) : A. Romanow, J. Mogul, T. Talpey, S. Bailey Filename : draft-ietf-rddp-problem-statement-03.txt Pages : 19 Date : 2004-1-19 This draft addresses an IP-based solution to the problem of high system costs due to network I/O copying in end-hosts at high speeds. The problem is due to the high cost of memory bandwidth, and it can be substantially improved using 'copy avoidance.' The high overhead has limited the use of TCP/IP in interconnection networks especially where high bandwidth, low latency and/or low overhead of end-system data movement are required by the hosted application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-problem-statement-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-problem-statement-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-problem-statement-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-20102726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-problem-statement-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-problem-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20102726.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Jan 21 19:23:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19248 for ; Wed, 21 Jan 2004 19:23:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjScD-0003et-JL for rddp-archive@odin.ietf.org; Wed, 21 Jan 2004 19:22:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M0MX0N014055 for rddp-archive@odin.ietf.org; Wed, 21 Jan 2004 19:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjScD-0003eU-Dh for rddp-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 19:22:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19242 for ; Wed, 21 Jan 2004 19:22:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjScB-0004rR-00 for rddp-web-archive@ietf.org; Wed, 21 Jan 2004 19:22:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjSbG-0004ow-00 for rddp-web-archive@ietf.org; Wed, 21 Jan 2004 19:21:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjSam-0004m3-00 for rddp-web-archive@ietf.org; Wed, 21 Jan 2004 19:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjSaj-0003bP-L9; Wed, 21 Jan 2004 19:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjSaD-0003Zr-Ti for rddp@optimus.ietf.org; Wed, 21 Jan 2004 19:20:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19187 for ; Wed, 21 Jan 2004 19:20:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjSaC-0004kc-00 for rddp@ietf.org; Wed, 21 Jan 2004 19:20:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjSZL-0004iq-00 for rddp@ietf.org; Wed, 21 Jan 2004 19:19:36 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AjSYg-0004fA-00 for rddp@ietf.org; Wed, 21 Jan 2004 19:18:54 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Jan 2004 16:18:03 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 21 Jan 2004 16:18:27 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Jan 2004 16:18:24 -0800 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); Wed, 21 Jan 2004 16:18:25 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Jan 2004 16:18:16 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 21 Jan 2004 16:18:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Wed, 21 Jan 2004 16:18:16 -0800 Message-ID: Thread-Topic: RDMA MIB? Thread-Index: AcPgfTtFeOv6D69kROiL4u9MKJCJzw== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 22 Jan 2004 00:18:23.0452 (UTC) FILETIME=[3F5429C0:01C3E07D] Subject: [rddp] RDMA MIB? 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E07D.405BC69A" ------_=_NextPart_001_01C3E07D.405BC69A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >From Mike Krause's comments on the security draft: =20 > (24) 7.5.3 It is not clear to me that a RDMA MIB is required. One can > understand whether a LLP or a physical interface are making forward > progress through the existing MIBs. Providing additional statistics isn't > really of value as one knows the connections / streams and layer 2 are > making forward progress. After that, one checks to see if the ULP is > making forward progress and therefore we have a complete picture without > requiring yet another MIB to implement / manage. >=20 =20 =20 Anyone else have comments? Here's what's currently in the security draft. I can rewrite it if appropriate. One possibility would be to add an additional example of monitoring the existing transport stream with the enhanced MIBs that allow monitoring a specific flow. Traditional MIBs don't enable monitoring of a specific flow though, so would not necessarily give insight into resource starvation. =20 =20 1.1.1 Resource Consumption by Idle Applications The simplest form of a DOS attack given a fixed amount of resources is for the Remote Peer to create a RDMAP Stream to a Local Peer, request dedicated resources then do no actual work. This allows the Remote Peer to be very light weight (i.e. only negotiate resources, but do no data transfer) and consumes a disproportionate amount of resources in the server. A general countermeasure for this style of attack is to monitor active RDMAP Streams and if resources are getting low, reap the resources from RDMAP Streams that are not transferring data and possibly terminate the connection. This needs to be under administrative control, and demonstrates the need for a MIB for RDMAP so this condition can be detected and acted upon. =20 =20 =20 =20 ------_=_NextPart_001_01C3E07D.405BC69A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From Mike Krause’s comments on the security = draft:

 

> (24) 7.5.3 It is not clear to me that a RDMA MIB is = required.  One can

> understand whether a LLP or a physical interface are making forward

> progress through the existing MIBs.  Providing = additional statistics isn't

> really of value as one knows the connections / streams and = layer 2 are

> making forward progress.  After that, one checks to = see if the ULP is

> making forward progress and therefore we have a complete = picture without

> requiring yet another MIB to implement / = manage.

>

 

 

Anyone else have comments?  Here’s = what’s currently in the security draft. I can rewrite it if appropriate. One possibility would be to add an additional example of monitoring the = existing transport stream with the enhanced MIBs that allow monitoring a specific = flow. Traditional MIBs don’t enable monitoring of a specific flow = though, so would not necessarily give insight into resource = starvation.

 

 

1.1.1         Resource Consumption by Idle = Applications

The simplest form of a DOS attack given a fixed amount of = resources is for the Remote Peer to create a RDMAP Stream to a Local Peer, request = dedicated resources then do no actual work. This allows the Remote Peer to be very = light weight (i.e. only negotiate resources, but do no data transfer) and = consumes a disproportionate amount of resources in the server.

A general = countermeasure for this style of attack is to monitor active RDMAP Streams and if resources = are getting low, reap the resources from RDMAP Streams that are not = transferring data and possibly terminate the connection. This needs to be under administrative control, and demonstrates the need for a MIB for RDMAP so = this condition can be detected and acted upon.

 

 

 

 

------_=_NextPart_001_01C3E07D.405BC69A-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Jan 21 20:01:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20082 for ; Wed, 21 Jan 2004 20:01:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTDt-0005Vw-T4 for rddp-archive@odin.ietf.org; Wed, 21 Jan 2004 20:01:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M11Td1021193 for rddp-archive@odin.ietf.org; Wed, 21 Jan 2004 20:01:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTDt-0005Vk-OT for rddp-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 20:01:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20076 for ; Wed, 21 Jan 2004 20:01:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjTDr-0006Hz-00 for rddp-web-archive@ietf.org; Wed, 21 Jan 2004 20:01:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjTCw-0006GJ-00 for rddp-web-archive@ietf.org; Wed, 21 Jan 2004 20:00:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjTCV-0006EV-00 for rddp-web-archive@ietf.org; Wed, 21 Jan 2004 20:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTCV-0005Sf-Es; Wed, 21 Jan 2004 20:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTBw-0005Re-Es for rddp@optimus.ietf.org; Wed, 21 Jan 2004 19:59:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20028 for ; Wed, 21 Jan 2004 19:59:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjTBr-0006Dd-00 for rddp@ietf.org; Wed, 21 Jan 2004 19:59:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjTAv-0006Ci-00 for rddp@ietf.org; Wed, 21 Jan 2004 19:58:28 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AjTA1-00069z-00 for rddp@ietf.org; Wed, 21 Jan 2004 19:57:29 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 21 Jan 2004 16:57:01 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Jan 2004 16:56:58 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Jan 2004 16:56:59 -0800 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); Wed, 21 Jan 2004 16:56:51 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 21 Jan 2004 16:57:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Wed, 21 Jan 2004 16:56:51 -0800 Message-ID: Thread-Topic: RDDP Security - misc comments, 1-16 Thread-Index: AcPggp77P7pVE3zjSJSQiu5j8qBCQg== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 22 Jan 2004 00:57:18.0463 (UTC) FILETIME=[AF1A90F0:01C3E082] Subject: [rddp] RDDP Security - misc comments, 1-16 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E082.A5F79C12" ------_=_NextPart_001_01C3E082.A5F79C12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike Krause has done a great job reviewing the doc and coming up with questions. Because there are quite a few questions/issues raised, I'm dividing them into multiple emails to help focus the discussion. This email handles questions which don't bring up organizational issues, through question 16. Organizational issues will be in a separate email. =20 > (3) Figure 1. One might consider having a line between the admin and the > privileged application given the resource manager is not required but its > essence may be integrated into the privileged application. For example, a > storage subsystem may already have defined interfaces to administration > services and if it has exclusive control of the RNIC would not require a > separate resource manager. >=20 =20 Will do. =20 > (6) Request proxy interface definition in 4.1 really does not provide much > information. It provides a high-level statement on counter measures but > due to organization, such a statement does not have much in terms of > value. >=20 =20 On re-reading this, I agree that there are unresolved issues. Specifically "Application Control Interface" is not defined. My original intent here was to differentiate between requests for resources, which need to go through the Privileged Resource Manager for the reasons stated, and an interface for the non-privileged application for it to register buffers with the RNIC. After trying to fix this, I think this is overly complex. I'd like to collapse the "Application Control Interface" and the "Request Proxy Interface" into a single "Application Control Interface", where the definition states that for non-privileged application usage the Privileged Resource Manager will verify the request and implement countermeasures. Something like: =20 * Application Control Interface - An application uses this interface to the Privileged Resource Manager to allocate RNIC Engine resources. The Privileged Resource Manager implements countermeasures to ensure that if the Non-Privileged Application launches an attack it can prevent the attack from affecting other applications. =20 =20 > (7) 4.2.4 Is there any need to discuss the 8-bit key portion of the STag > and how an application / ULP can help control the wire-view of the STag? >=20 =20 The 8 bit key is specific to a verbs implementation, not the wire protocols. I personally don't see how this aids security in any way - it's trivial to hack. To me the primary justification for including it was to allow fast lookups and some help in debug (by mixing up the key values a little). Since calling this "security" to me would be highly controversial, I'd prefer to leave it out. =20 > (8) 4.28 There is "Event Queue" and one other line but not really anything > else stated here. This seems almost like a fragment or a TBD area. >=20 =20 Yep - this is a fragment. I'll complete the thought in the next draft. As you're aware, this is non-trivial to finish. =20 > (9) 4.3 Is 4.3 just a place holder? Not clear its relevance to the draft > as many system properties can be attacked but these are outside the scope > of RDMA itself. =20 This was included at the direction of security folks - in general, all of the attacks described in the document fall into the category of system integrity. One thing that is not done in the document is to directly reference which categories the attacks fall into (integrity, stability, confidentiality). Alternatively, if folks don't see a lot of value in this section (i.e. what is being attacked is obvious), I could just delete the section. =20 > (12) Page 15 under NS-RT. There is a note attached but not really > sufficient information provided w.r.t. the key-based authentication per > packet sentence. Either provide more information here or add a pointer to > the appropriate specification or subsequent section where this is > described > further. >=20 =20 I'll add a cross-ref to chapter 8. =20 > (13) 7.1.1. Add "each" to , it is recommend that Protection Domain be > limited to the number.... >=20 Will do. Sentence now reads "it is recommended that Protection Domain be limited to the number of Streams that each share the same Trust Model." =20 > (14) 7.1.2 Second bullet should use the term window or cross reference to > the appropriate specification so that the reader can understand how this > is > somewhat a local issue and that there are tools defined to help provide > this service. >=20 =20 I've intentionally tried to stay away from Verbs-isms in this document. Also, I can't reference the verbs spec if it does not have a path to RFC status (as informational, experimental, standards, whatever). Thus I've tried in general to describe issues in the abstract, without talking about a specific implementation. Or if talking about specific implementations, try to provide a variety of choices, without mandating a choice. I agree that the document could be more detailed in implementation, but I think that also means that we then have to decide as a group on standardizing a host to RNIC interface. Personally, I'd rather not gate RDMAP/DDP/etc on this issue. Clearly they are gated on the security draft. =20 > (15) 7.1.2 fourth bullet, STag needs to be properly capitalized. It > would > also be good to cross reference back to the error description (per > previous > comment) the effects of a STag violation. >=20 =20 I've fixed STag and also done a global replace to fix the other 9 times. Thanks. I've also added text referencing RDMAP and DDP on what happens when an invalid STag is received. (RDMAP requires a teardown, DDP is required to signal the error to the ULP, and commonly this will cause a teardown). =20 > (16) 7.1.5 Need to emphasize that this is an application problem not a > RDMA > or DDP problem. >=20 =20 I don't agree. For example, if an error on a specific stream causes the RNIC to hang, all applications using the adapter are effected, regardless of what the application does. I'll add an example to make this clearer. Something like: =20 For example, an error on a specific RDMAP stream should not cause the RNIC to stop processing incoming packets, or corrupt a receive queue for an unrelated stream.=20 ------_=_NextPart_001_01C3E082.A5F79C12 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike Krause has done a great job reviewing the doc = and coming up with questions. Because there are quite a few questions/issues raised, I’m dividing them into multiple emails to help focus the discussion. This email handles questions which don’t bring up = organizational issues, through question 16. Organizational issues will be in a separate = email.

 

> (3) Figure 1.  One might consider having a line = between the admin and the

> privileged application given the resource manager is not = required but its

> essence may be integrated into the privileged = application.  For example, a

> storage subsystem may already have defined interfaces to administration

> services and if it has exclusive control of the RNIC would = not require a

> separate resource manager.

>

 

Will do.

 

> (6) Request proxy interface definition in 4.1 really does = not provide much

> information.  It provides a high-level statement on = counter measures but

> due to organization, such a statement does not have much in = terms of

> value.

>

 

On re-reading this, I agree that there are unresolved issues. Specifically “Application Control Interface” is not defined. = My original intent here was to differentiate between requests for = resources, which need to go through the Privileged Resource Manager for the reasons = stated, and an interface for the non-privileged application for it to register buffers = with the RNIC. After trying to fix this, I think this is overly complex. = I’d like to collapse the “Application Control Interface” and the = “Request Proxy Interface” into a single “Application Control = Interface”, where the definition states that for non-privileged application usage = the Privileged Resource Manager will verify the request and implement countermeasures. Something like:

 

*           = ;    Application Control Interface – An = application uses this interface to the Privileged Resource Manager to allocate RNIC = Engine resources. The Privileged Resource Manager implements countermeasures to = ensure that if the Non-Privileged Application launches an attack it can prevent = the attack from affecting other applications.

 

 

> (7) 4.2.4 Is there any need to discuss the 8-bit key = portion of the STag

> and how an application / ULP can help control the wire-view = of the STag?

>

 

The 8 bit key is specific to a verbs implementation, = not the wire protocols. I personally don’t see how this aids security in = any way – it’s trivial to hack. To me the primary justification for = including it was to allow fast lookups and some help in debug (by mixing up the key = values a little). Since calling this “security” to me would be highly controversial, I’d prefer to leave it out.

 

> (8) 4.28 There is "Event Queue" and one other = line but not really anything

> else stated here.  This seems almost like a fragment = or a TBD area.

>

 

Yep – this is a fragment. I’ll complete = the thought in the next draft. As you’re aware, this is non-trivial to finish.

 

> (9) 4.3 Is 4.3 just a place holder?  Not clear its = relevance to the draft

> as many system properties can be attacked but these are = outside the scope

> of RDMA itself.

 

This was included at the direction of security folks – in = general, all of the attacks described in the document fall into the category of = system integrity.  One thing that is not done in the document  is to directly reference which categories the attacks fall into (integrity, = stability, confidentiality). Alternatively, if folks don’t see a lot of value = in this section (i.e. what is being attacked is obvious), I could just = delete the section.

 

> (12) Page 15 under NS-RT. There is a note attached but not = really

> sufficient information provided w.r.t. the key-based authentication per

> packet sentence.  Either provide more information here = or add a pointer to

> the appropriate specification or subsequent section where = this is

> described

> further.

>

 

I’ll add a cross-ref to chapter 8.

 

> (13) 7.1.1.   Add "each" to , it is = recommend that Protection Domain be

> limited to the number....

>

Will do. Sentence now reads “it is recommended that = Protection Domain be limited to the number of Streams that each share the same = Trust Model.”

 

> (14) 7.1.2 Second bullet should use the term window or = cross reference to

> the appropriate specification so that the reader can = understand how this

> is

> somewhat a local issue and that there are tools defined to = help provide

> this service.

>

 

I’ve intentionally tried to stay away from = Verbs-isms in this document. Also, I can’t reference the verbs spec if it = does not have a path to RFC status (as informational, experimental, standards, whatever).  Thus I’ve tried in general to describe issues in = the abstract, without talking about a specific implementation. Or if talking = about specific implementations, try to provide a variety of choices, without mandating a choice. I agree that the document could be more detailed in implementation, but I think that also means that we then have to decide = as a group on standardizing a host to RNIC interface. Personally, I’d = rather not gate RDMAP/DDP/etc on this issue. Clearly they are gated on the = security draft.

 

> (15) 7.1.2 fourth bullet,  STag needs to be properly capitalized.  It

> would

> also be good to cross reference back to the error = description (per

> previous

> comment) the effects of a STag violation.

>

 

I’ve fixed STag and also done a global replace = to fix the other 9 times. Thanks. I’ve also added text referencing RDMAP = and DDP on what happens when an invalid STag is received. (RDMAP requires a = teardown, DDP is required to signal the error to the ULP, and commonly this will = cause a teardown).

 

> (16) 7.1.5 Need to emphasize that this is an application = problem not a

> RDMA

> or DDP problem.

>

 

I don’t agree. For example, if an error on a = specific stream causes the RNIC to hang, all applications using the adapter are = effected, regardless of what the application does. I’ll add an example to = make this clearer. Something like:

 

For example, an error on a specific RDMAP stream should not = cause the RNIC to stop processing incoming packets, or corrupt a receive queue for = an unrelated stream.

------_=_NextPart_001_01C3E082.A5F79C12-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 22 00:09:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26272 for ; Thu, 22 Jan 2004 00:09:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjX5C-0004ob-Nf for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 00:08:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M58kvC018505 for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 00:08:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjX5C-0004oO-JV for rddp-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 00:08:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26267 for ; Thu, 22 Jan 2004 00:08:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjX5A-00006O-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 00:08:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjX4F-00003X-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 00:07:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjX3U-0007nn-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 00:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjX3U-0004R3-Pe; Thu, 22 Jan 2004 00:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjX38-0004NG-0d for rddp@optimus.ietf.org; Thu, 22 Jan 2004 00:06:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26186 for ; Thu, 22 Jan 2004 00:06:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjX35-0007m2-00 for rddp@ietf.org; Thu, 22 Jan 2004 00:06:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjX2E-0007ip-00 for rddp@ietf.org; Thu, 22 Jan 2004 00:05:43 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AjX1M-0007cX-00 for rddp@ietf.org; Thu, 22 Jan 2004 00:04:48 -0500 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 78B7C245FD3; Thu, 22 Jan 2004 00:04:56 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <5FDAB99E-4C98-11D8-8807-003065D48EE0@asomi.com> Content-Transfer-Encoding: quoted-printable Cc: From: Caitlin Bestler Subject: Re: [rddp] RDMA MIB? Date: Wed, 21 Jan 2004 23:03:53 -0600 To: "Jim Pinkerton" X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Jan 21, 2004, at 6:18 PM, Jim Pinkerton wrote: > =A0 > > =46rom Mike Krause=92s comments on the security draft: > > =A0 > > > (24) 7.5.3 It is not clear to me that a RDMA MIB is required.=A0 One=20= > can > > > understand whether a LLP or a physical interface are making forward > > > progress through the existing MIBs.=A0 Providing additional = statistics=20 > isn't > > > really of value as one knows the connections / streams and layer 2=20= > are > > > making forward progress.=A0 After that, one checks to see if the ULP = is > > > making forward progress and therefore we have a complete picture=20 > without > > > requiring yet another MIB to implement / manage. > > > > > =A0 > > =A0 > > Anyone else have comments? =A0Here=92s what=92s currently in the = security=20 > draft. I can > rewrite it if appropriate. One possibility would be to add an=20 > additional example > of monitoring the existing transport stream with the enhanced MIBs=20 > that allow > monitoring a specific flow. Traditional MIBs don=92t enable monitoring=20= > of a specific > flow though, so would not necessarily give insight into resource=20 > starvation. > > =A0 There is a need for *some* method of monitoring forward progress, but I=20= agree with Mike that any applicable existing monitors would solve the problem. Forward LLP progress is very correlated with forward RDMAP/DDP progress. However, I don't believe we should imply that LLP statistics SHOULD be gathered on these connections. In many environments it might be easier to monitor forward progress at the DDP layer. We should not mandate that the tracking occur at the lower layer, even though inertia will very heavily favor doing it there. The important thing is that we not require implementations to make MIB tallies at *both* the LLP and iWarp layers. --=20 Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 22 00:15:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26360 for ; Thu, 22 Jan 2004 00:15:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjXAn-0004zP-8J for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 00:14:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M5EXKa019173 for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 00:14:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjXAn-0004zA-52 for rddp-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 00:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26357 for ; Thu, 22 Jan 2004 00:14:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjXAk-0000Cp-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 00:14:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjX9m-0000Ba-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 00:13:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjX9H-0000Au-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 00:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjX9J-0004wD-36; Thu, 22 Jan 2004 00:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjX8s-0004ut-6e for rddp@optimus.ietf.org; Thu, 22 Jan 2004 00:12:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26339 for ; Thu, 22 Jan 2004 00:12:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjX8p-0000Ar-00 for rddp@ietf.org; Thu, 22 Jan 2004 00:12:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjX7s-0000A1-00 for rddp@ietf.org; Thu, 22 Jan 2004 00:11:32 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AjX7l-00008w-00 for rddp@ietf.org; Thu, 22 Jan 2004 00:11:25 -0500 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 58895244ED9; Thu, 22 Jan 2004 00:11:53 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <587C1ADE-4C99-11D8-8807-003065D48EE0@asomi.com> Content-Transfer-Encoding: quoted-printable Cc: From: Caitlin Bestler Subject: Re: [rddp] RDDP Security - misc comments, 1-16 Date: Wed, 21 Jan 2004 23:10:50 -0600 To: "Jim Pinkerton" X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Jan 21, 2004, at 6:56 PM, Jim Pinkerton wrote: > > > (14) 7.1.2 Second bullet should use the term window or cross=20 > reference to > > > the appropriate specification so that the reader can understand how=20= > this > > > is > > > somewhat a local issue and that there are tools defined to help=20 > provide > > > this service. > > > > > =A0 > > I=92ve intentionally tried to stay away from Verbs-isms in this=20 > document. Also, I can=92t > reference the verbs spec if it does not have a path to RFC status (as=20= > informational, > experimental, standards, whatever). =A0Thus I=92ve tried in general to=20= > describe issues > in the abstract, without talking about a specific implementation. Or=20= > if talking about > specific implementations, try to provide a variety of choices, without=20= > mandating a > choice. I agree that the document could be more detailed in=20 > implementation, but I > think that also means that we then have to decide as a group on=20 > standardizing a > host to RNIC interface. Personally, I=92d rather not gate = RDMAP/DDP/etc=20 > on this > issue. Clearly they are gated on the security draft. It may be proper/useful to acknowledge that many local interfaces will have a distinction between relatively expensive registrations=20 ("regions") and a lighter-weight mechanism more suitable for generating disposable STags ("windows"), and that a local interface lacking a mechansism suitable for disposable STags may improperly tempt applications into the dangers of over-exposing their memory. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 22 09:31:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22264 for ; Thu, 22 Jan 2004 09:31:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajfqz-0004Lr-V8 for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 09:30:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MEUfCb016721 for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 09:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajfqy-0004Lb-DR for rddp-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 09:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22243 for ; Thu, 22 Jan 2004 09:30:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajfqh-0004fW-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 09:30:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjfnJ-0004Yd-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 09:26:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajfkp-0004QG-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 09:24:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjfkW-000412-J1; Thu, 22 Jan 2004 09:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajfjb-000404-5e for rddp@optimus.ietf.org; Thu, 22 Jan 2004 09:23:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22030 for ; Thu, 22 Jan 2004 09:22:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjfjP-0004MC-00 for rddp@ietf.org; Thu, 22 Jan 2004 09:22:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajffy-0004Ea-00 for rddp@ietf.org; Thu, 22 Jan 2004 09:19:18 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1Ajfdw-00046U-00 for rddp@ietf.org; Thu, 22 Jan 2004 09:17:12 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id B5A761C009A2 for ; Thu, 22 Jan 2004 06:16:40 -0800 (PST) Received: from mk731915.cup.hp.com ([15.244.169.89]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id i0ME7ga25193 for ; Thu, 22 Jan 2004 06:07:42 -0800 (PST) Message-Id: <5.1.0.14.2.20040122054906.02a132c0@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 22 Jan 2004 05:53:28 -0800 To: rddp@ietf.org From: Michael Krause Subject: Re: [rddp] RDMA MIB? In-Reply-To: <5FDAB99E-4C98-11D8-8807-003065D48EE0@asomi.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 11:03 PM 1/21/2004 -0600, Caitlin Bestler wrote: >On Jan 21, 2004, at 6:18 PM, Jim Pinkerton wrote: > >> >> >> From Mike Krause's comments on the security draft: >> >> >> >> > (24) 7.5.3 It is not clear to me that a RDMA MIB is required. One can >> >> > understand whether a LLP or a physical interface are making forward >> >> > progress through the existing MIBs. Providing additional statistics isn't >> >> > really of value as one knows the connections / streams and layer 2 are >> >> > making forward progress. After that, one checks to see if the ULP is >> >> > making forward progress and therefore we have a complete picture without >> >> > requiring yet another MIB to implement / manage. >> >> > >> >> >> >> >> >>Anyone else have comments? Here's what's currently in the security >>draft. I can >>rewrite it if appropriate. One possibility would be to add an additional >>example >>of monitoring the existing transport stream with the enhanced MIBs that allow >>monitoring a specific flow. Traditional MIBs don't enable monitoring of a >>specific >>flow though, so would not necessarily give insight into resource starvation. >> >> > >There is a need for *some* method of monitoring forward progress, but I agree >with Mike that any applicable existing monitors would solve the problem. >Forward LLP progress is very correlated with forward RDMAP/DDP progress. > >However, I don't believe we should imply that LLP statistics SHOULD be >gathered on these connections. In many environments it might be easier >to monitor forward progress at the DDP layer. We should not mandate that >the tracking occur at the lower layer, even though inertia will very >heavily favor doing it there. I agree that inertia will favor using the existing methods as many iWARP implementations may expose their LLP protocol off-load interface directly thus would prefer a single method be provided to track forward progress. My preference though, remains not spending resources on developing an iWARP MIB unless someone can demonstrate strong value for consumers or that the LLP methods are significantly deficient. I do not believe there is a strong case being driven from a security aspect. >The important thing is that we not require implementations to make MIB >tallies at *both* the LLP and iWarp layers. Strongly agree that this would be impractical due to very low cost / value. Mike >-- >Caitlin Bestler - cait@asomi.com - http://asomi.com/ >http://asomi.com/CaitlinBestlerPublicPgpKey.html > > >_______________________________________________ >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 exim@www1.ietf.org Thu Jan 22 15:14:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07271 for ; Thu, 22 Jan 2004 15:14:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlDV-0003TA-PH for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 15:14:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MKEHD0013333 for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 15:14:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlDV-0003Sy-BF for rddp-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 15:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07249 for ; Thu, 22 Jan 2004 15:14:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjlDO-00050W-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 15:14:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajl9L-0004mh-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 15:10:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajl6l-0003JJ-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 15:07:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajl6T-0000hY-H3; Thu, 22 Jan 2004 15:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajl60-0000PT-U4 for rddp@optimus.ietf.org; Thu, 22 Jan 2004 15:06:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06989 for ; Thu, 22 Jan 2004 15:06:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajl5n-0002B8-00 for rddp@ietf.org; Thu, 22 Jan 2004 15:06:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajl4E-0000Yh-00 for rddp@ietf.org; Thu, 22 Jan 2004 15:04:45 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1Ajl2O-0004Wr-00 for rddp@ietf.org; Thu, 22 Jan 2004 15:02:48 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Jan 2004 12:01:34 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Jan 2004 12:01:52 -0800 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, 22 Jan 2004 12:01:25 -0800 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, 22 Jan 2004 12:01:52 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 22 Jan 2004 12:02:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Thu, 22 Jan 2004 12:01:42 -0800 Message-ID: Thread-Topic: RDDP Security - misc comments 17-29 Thread-Index: AcPhIo4kB8BuQsaKQ6yZrlALzLMnbA== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 22 Jan 2004 20:02:27.0885 (UTC) FILETIME=[A91C55D0:01C3E122] Subject: [rddp] RDDP Security - misc comments 17-29 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E122.8F3DF57C" ------_=_NextPart_001_01C3E122.8F3DF57C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is the second email in a multi-email series to answer the lengthy review that Michael Krause did on the security draft. The questions here are questions 17-29, except those that bring up document organizational questions. Those will be in a separate email. =20 =20 > (17) 7.2 My reaction was "so". Not clear why this section is there given > the limited information provided. >=20 =20 It is actually critical - the whole point is to identify that an entire class of attacks can essentially not be done against RDMAP - thus we don't need to include them in this security draft. =20 > (18) 7.2.1 Need to think about this more but it seems there could be nasty > middle-box attacks which are outside the scope of RDMA and DDP. It would > also be good to separate authentication from integrity protection as the > two provide different protections and the associated protections should be > clearly attributed to each if you are going to list out the various > attacks. >=20 =20 Thanks. I had a typo where I incorrectly in one sentence stated "authentication" when it should have been "integrity protection". The sentence now reads: "If integrity protection is not used, then a man-in-the-middle attack can occur, enabling spoofing, and tampering." =20 > (20) 7.2.2. STag of zero is a local, not remote value and thus should not > be part of the allocation algorithm. >=20 I changed the example to one. I'd prefer not to bring verbs semantics into this document. =20 > (21) 7.3.2 This may be a bit of implementation but it may be possible that > a RNIC could have multiple execution paths such that the invalidate > executes in parallel or serial to other operations thus a subsequent RDMA > operation could access memory prior to the invalidate being > completed. Same applies if the invalidate or access rights changes are > implemented in software which is asynchronous the subsequent hardware > packet processing operations. This might lead to a race condition and > thus > exposure. >=20 > One question: What if the remote stated it would invalidate but does not > do > so? It is clear that remote peers should not be trusted but one may > appear > to be fully compliant with the ULP needs and then simply not invalidate > thus enabling the memory to be read / updated. This can be dealt with via > the implementation - a couple of simple techniques come to mind - but it > may need to be discussed a bit further. >=20 =20 I don't understand the comment. The text specifically addresses what should happen if the remote peer doesn't invalidate? Specifically: =20 "...or by checking to make sure the Remote Peer Invalidated the STag through the RDMAP Invalidate capability, and if it did not, the Local Peer then explicitly revokes the STag remote access rights."=20 =20 Does this not answer the above question? =20 > (22) 7.4.2 Zeroing of a data buffer or providing valid data with all > non-used buffer memory being invalidated / zero should be noted. >=20 =20 The text specifically states: =20 Because of this, it is RECOMMENDED that the Local Peer ensure that no stale data is contained in the buffer when remote read access rights are initially granted (this can be done by zeroing the contents of the memory, for example).=20 Are you reviewing an old version of the spec? This is from the draft-ietf-rddp-security-00. =20 > (23) 7.5.2.2 Note that this is only for a shared CQ in the header though > the subsequent header does make this more specific. >=20 =20 Good catch. I've updated the introduction to be shared completion queue specific. =20 > (25) Not sure if I agree with the note in 7.5.3 that indicates that there > isn't risk for some resources. For example, a ULP may negotiate use of > large receive buffers and potentially large number of receive buffers and > then not make forward progress. These types of consumptions are problems > for both local and remote attacks. >=20 =20 I added your example to the spec. =20 "This could also be caused by ULP negotiation with the Remote Peer, which causes the Local Peer to consume resources which are never consumed by the Remote Peer. " =20 > (26) 7.5.4 One could also see an attack where one purposely transmits out > of order packets or delays the packet retransmission quite often. This > could force some implementations to take the slow path quite often thus > causing a performance degradation attack. This is an > implementation-specific problem that is also applicable to non-RDMA > network > stacks so it isn't necessarily new but might be beneficial to note. >=20 =20 The problem with this is that you can use the exact description above to describe a normal application (ignoring the out-of-order packets since that is a TCP thing, not RDMA/DDP thing). To me the above example is more like what I was trying to describe in the previous section - "Resource Consumption by Idle Applications". You don't necessarily not use them at all - just use them extremely slowly. In any case, it's unclear to me that any new text is needed? =20 > (27) 7.5.5 The last sentence says that the remote peer just can't use the > STag but it can also cause a connection to be shut down on error thus > while > true, there is another potential consequence. >=20 =20 To me this isn't a security issue - if a malicious application can cause his own connection to be torn down by sending bad STags, there are no security holes. =20 > (28) 7.5.6 Should note the high and low-water marks per connection sharing > a receive queue to detect and allow corrective action to take place. >=20 =20 Will do. =20 =20 > (29) 7.6 Not sure if this applies but if the system supports dynamic > patching of a subsystem, then one might replace the executable with a > trojan horse thus enabling one to take over the system / resources. Might > be worthwhile to have a note that such patching solutions should have all > RDMA / DDP resources released so that the LLP establishment process is > required thereby providing some level of new authentication to occur to > the > previous remote peers. >=20 This seems extremely OS specific to me. It's a slipperly slope to start talking about all the local OS specific issues. In general, when you tear out a dynamicly linked library you have to make sure all resources allocated by the library have been freed first.=20 =20 =20 =20 =20 Jim =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C3E122.8F3DF57C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is the second email in a multi-email series to = answer the lengthy review that Michael Krause did on the security draft. The = questions here are questions 17-29, except those that bring up document = organizational questions. Those will be in a separate email.

 

 

> (17) 7.2  My reaction was "so".  Not = clear why this section is there given

> the limited information provided.

>

 

It is actually critical – the whole point is to identify that an entire class of attacks can essentially not be done = against RDMAP – thus we don’t need to include them in this security = draft.

 

> (18) 7.2.1 Need to think about this more but it seems there = could be nasty

> middle-box attacks which are outside the scope of RDMA and DDP.  It would

> also be good to separate authentication from integrity = protection as the

> two provide different protections and the associated = protections should be

> clearly attributed to each if you are going to list out the various

> attacks.

>

 

Thanks. I had a typo where I incorrectly in one sentence stated = “authentication” when it should have been “integrity protection”.  The = sentence now reads: “If integrity protection is not used, then a = man-in-the-middle attack can occur, enabling spoofing, and = tampering.”

 

> (20) 7.2.2. STag of zero is a local, not remote value and = thus should not

> be part of the allocation algorithm.

>

I changed the example to one. I’d prefer not to = bring verbs semantics into this document.

         =             &= nbsp;           &n= bsp;           &nb= sp;          =

> (21) 7.3.2 This may be a bit of implementation but it may = be possible that

> a RNIC could have multiple execution paths such that the invalidate

> executes in parallel or serial to other operations thus a subsequent RDMA

> operation could access memory prior to the invalidate = being

> completed.  Same applies if the invalidate or access = rights changes are

> implemented in software which is asynchronous the = subsequent hardware

> packet processing operations.  This might lead to a = race condition and

> thus

> exposure.

>

> One question: What if the remote stated it would invalidate = but does not

> do

> so?  It is clear that remote peers should not be = trusted but one may

> appear

> to be fully compliant with the ULP needs and then simply = not invalidate

> thus enabling the memory to be read / updated.  This = can be dealt with via

> the implementation - a couple of simple techniques come to = mind - but it

> may need to be discussed a bit further.

>

 

I don’t understand the comment. The text = specifically addresses what should happen if the remote peer doesn’t = invalidate? Specifically:

 

“…or by checking to make sure the Remote Peer = Invalidated the STag through the RDMAP Invalidate capability, and if it did not, the = Local Peer then explicitly revokes the STag remote access rights.” =

 

Does this not answer the above question?

 

> (22) 7.4.2 Zeroing of a data buffer or providing valid data = with all

> non-used buffer memory being invalidated / zero should be = noted.

>

 

The text specifically states:

 

Because of this, it is RECOMMENDED that the Local Peer ensure = that no stale data is contained in the buffer when remote read access rights are = initially granted (this can be done by zeroing the contents of the memory, for = example).

Are you reviewing an old version of the spec? This is = from the draft-ietf-rddp-security-00.

 

> (23) 7.5.2.2 Note that this is only for a shared CQ in the = header though

> the subsequent header does make this more = specific.

>

 

Good catch. I’ve updated the introduction to be = shared completion queue specific.

 

> (25) Not sure if I agree with the note in 7.5.3 that = indicates that there

> isn't risk for some resources.  For example, a ULP may negotiate use of

> large receive buffers and potentially large number of = receive buffers and

> then not make forward progress.  These types of = consumptions are problems

> for both local and remote attacks.

>

 

I added your example to the spec.

 

“This could also be caused by ULP negotiation with the Remote Peer, which causes the Local Peer to consume resources which are never consumed by the Remote Peer. “

 

> (26) 7.5.4 One could also see an attack where one purposely transmits out

> of order packets or delays the  packet retransmission = quite often. This

> could force some implementations to take the slow path = quite often thus

> causing a performance degradation attack.  This is = an

> implementation-specific problem that is also applicable to non-RDMA

> network

> stacks so it isn't necessarily new but might be beneficial = to note.

>

 

The problem with this is that you can use the exact description = above to describe a normal application (ignoring the out-of-order packets = since that is a TCP thing, not RDMA/DDP thing). To me the above example is more like = what I was trying to describe in the previous section – “Resource Consumption by Idle Applications”. You don’t necessarily not = use them at all – just use them extremely slowly. In any case, = it’s unclear to me that any new text is needed?

 

> (27) 7.5.5 The last sentence says that the remote peer just = can't use the

> STag but it can also cause a connection to be shut down on = error thus

> while

> true, there is another potential = consequence.

>

 

To me this isn’t a security issue – if a malicious application can cause his own connection to be torn down by = sending bad STags, there are no security holes.

 

> (28) 7.5.6 Should note the high and low-water marks per = connection sharing

> a receive queue to detect and allow corrective action to = take place.

>

 

Will do.

 

 

> (29) 7.6 Not sure if this applies but if the system = supports dynamic

> patching of a subsystem, then one might replace the = executable with a

> trojan horse thus enabling one to take over the system / resources.  Might

> be worthwhile to have a note that such patching solutions = should have all

> RDMA / DDP resources released so that the LLP establishment process is

> required thereby providing some level of new authentication = to occur to

> the

> previous remote peers.

>

This seems extremely OS specific to me. It’s a slipperly slope to start talking about all the local OS specific issues. = In general, when you tear out a dynamicly linked library you have to make = sure all resources allocated by the library have been freed first. =

 

 

 

 

Jim

 

 

 

 

 

 

 

 

 

 

 

 

 

------_=_NextPart_001_01C3E122.8F3DF57C-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 22 22:17:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26489 for ; Thu, 22 Jan 2004 22:17:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjroM-00017N-1E for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 22:16:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N3GkPD004293 for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 22:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjroL-00017A-U6 for rddp-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 22:16:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26469 for ; Thu, 22 Jan 2004 22:16:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajro8-0006t9-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 22:16:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajrlb-0006oe-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 22:13:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajrj5-0006jv-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 22:11:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajrim-0000sd-HD; Thu, 22 Jan 2004 22:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajrhp-0000qu-DQ for rddp@optimus.ietf.org; Thu, 22 Jan 2004 22:10:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26293 for ; Thu, 22 Jan 2004 22:09:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajrhc-0006i4-00 for rddp@ietf.org; Thu, 22 Jan 2004 22:09:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajrf4-0006f1-00 for rddp@ietf.org; Thu, 22 Jan 2004 22:07:11 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AjrdW-0006ad-00 for rddp@ietf.org; Thu, 22 Jan 2004 22:05:34 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Jan 2004 19:04:39 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Jan 2004 19:04:39 -0800 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, 22 Jan 2004 19:04:40 -0800 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, 22 Jan 2004 19:04:44 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 22 Jan 2004 19:05:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Thu, 22 Jan 2004 19:04:33 -0800 Message-ID: Thread-Topic: MPA security issues - minutes from last IETF Thread-Index: AcPhXaBn/bLT3cLvSF6U0mwmhcSpwg== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 23 Jan 2004 03:05:17.0767 (UTC) FILETIME=[BABD1D70:01C3E15D] Subject: [rddp] MPA security issues - minutes from last IETF 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E15D.9F135FFE" ------_=_NextPart_001_01C3E15D.9F135FFE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >From David's minutes from the last IETF meeting, he states: =20 --> Action Item: The "dual stack" architecture that came up in the MPA draft discussion has security implications, as the point of "stack switch" is an obvious place for an attacker to try something (e.g., louse up the stack switch so that the connection has to be abandoned). MPA draft authors to look into this and post results of this investigation to list. =20 Can the MPA authors comment on where we are at in terms of this action item? =20 =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C3E15D.9F135FFE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From David’s minutes from the last IETF = meeting, he states:

 

--> Action Item: = The "dual stack" architecture that came up in the = MPA

draft discussion = has security implications, as the point of "stack = switch"

is an obvious place = for an attacker to try something (e.g., louse up the stack switch so that the connection has to be abandoned).  MPA draft authors to look into = this and post results of this investigation to list.

 

Can the MPA authors comment on where we are at in = terms of this action item?

 

 

 

Jim

 

 

 

------_=_NextPart_001_01C3E15D.9F135FFE-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 22 22:34:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27060 for ; Thu, 22 Jan 2004 22:34:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajs4x-0001ze-Bu for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 22:33:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N3XtsN007656 for rddp-archive@odin.ietf.org; Thu, 22 Jan 2004 22:33:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajs4x-0001zP-5u for rddp-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 22:33:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27017 for ; Thu, 22 Jan 2004 22:33:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajs4t-0007ij-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 22:33:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajs3z-0007b0-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 22:32:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajs3C-0007RC-00 for rddp-web-archive@ietf.org; Thu, 22 Jan 2004 22:32:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajs36-0001ph-KR; Thu, 22 Jan 2004 22:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajs2G-0001oq-2B for rddp@optimus.ietf.org; Thu, 22 Jan 2004 22:31:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26840 for ; Thu, 22 Jan 2004 22:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajs27-0007OK-00 for rddp@ietf.org; Thu, 22 Jan 2004 22:30:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajryx-0007Ft-00 for rddp@ietf.org; Thu, 22 Jan 2004 22:27:43 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1Ajrvw-00077Q-00 for rddp@ietf.org; Thu, 22 Jan 2004 22:24:37 -0500 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 44A88244AD6; Thu, 22 Jan 2004 22:24:43 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <889C4DA9-4D53-11D8-BA9E-003065D48EE0@asomi.com> Content-Transfer-Encoding: quoted-printable Cc: From: Caitlin Bestler Subject: Re: [rddp] MPA security issues - minutes from last IETF Date: Thu, 22 Jan 2004 21:23:37 -0600 To: "Jim Pinkerton" X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Jan 22, 2004, at 9:04 PM, Jim Pinkerton wrote: > =A0 > > =46rom David=92s minutes from the last IETF meeting, he states: > > =A0 > > --> Action Item: The "dual stack" architecture that came up in the MPA > > draft discussion has security implications, as the point of "stack=20 > switch" > > is an obvious place for an attacker to try something (e.g., louse up=20= > the > stack switch so that the connection has to be abandoned).=A0 MPA draft=20= > authors > to look into this and post results of this investigation to list. > > =A0 > > Can the MPA authors comment on where we are at in terms of this action=20= > item? > > =A0 > Sending a partial MPA Request or Reply Frame can result in holding a TCP connection open during a portion of connection establishment that is not typically visible to the application. APIs, such as DAT and IT-API, that attempt to make connection=20 establishment transport neutral should be aware that the iWarp "Communication Manager" needs to protect itself against this type of attack. But otherwise I don't see a vulnerability. You either exchange MPA Start Frames properly, and enable an iWarp connection, or you fail to do so and the TCP connection is terminated. The only vulnerability is that TCP resources may be tied up if whatever component is handling the MPA Start Frame exchange fails to diagnose failures promptly. But that is true of *any* TCP application. --=20 Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Jan 23 15:32:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20517 for ; Fri, 23 Jan 2004 15:32:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7y7-0007cM-Ic for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 15:31:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NKVtPF029282 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 15:31:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7y7-0007cC-DV for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 15:31:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20493 for ; Fri, 23 Jan 2004 15:31:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7y6-0002bb-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:31:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak7xC-0002ZV-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:30:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak7wJ-0002XC-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7wJ-0007K3-Mi; Fri, 23 Jan 2004 15:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7wB-0007IY-P6 for rddp@optimus.ietf.org; Fri, 23 Jan 2004 15:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20386 for ; Fri, 23 Jan 2004 15:29:52 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7w9-0002WK-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:29:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak7vF-0002Ub-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:28:58 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak7uq-0002Sq-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:28:32 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 939B9738D; Fri, 23 Jan 2004 13:28:31 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 758CC9E; Fri, 23 Jan 2004 13:28:31 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 13:28:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Date: Fri, 23 Jan 2004 13:28:30 -0700 Message-ID: Thread-Topic: [rddp] Some questions related to "last segment" of a ddp message Thread-Index: AcPcQSaECj4NL/F5RhmcGXvVRiEx0wAAY3LAAWqzywA= To: , , Cc: X-OriginalArrivalTime: 23 Jan 2004 20:28:31.0231 (UTC) FILETIME=[7759C0F0:01C3E1EF] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Paul, RE: 2) Where are payload bytes 50-99? 300-399? [prc] The receiver is not expected to check for overlaps, or holes in the data. So this is not a valid reason to report errors and there are no defined errors for this. Perhaps the draft should explicitly say not to report errors for these cases. As long as all the transmitter's data was placed and delivered, the receiver is compliant. In the case of overlaps, the receiver is not even required to make sure that the highest TCP sequence numbered segment was the last placed, so overlaps could lead to unpredictable delivered data. As a consequence of this, the transmitter SHOULD send data with no overlaps or holes, although an application could conceivably be designed to work even if this is not followed (some kind of test suite?). [prc] The receiver is not required to check for overlaps and holes but there = isn't anyplace that disallows it doing so. I believe that this was our = intent when we wrote it and it is consistant with the text in the draft = - 7.2 says at the end that the Data Sink is not required to verify that = the entire message has been received. It doesn't prohibit checking.=20 So it would be valid behavior to detect an error because of the missing = bytes. It would also be valid behavior to not detect that error. Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Culley, Paul Sent: Friday, January 16, 2004 7:33 AM To: Michael C. Cambria; RDDP Cc: Barry Reinhold Subject: RE: [rddp] Some questions related to "last segment" of a ddp message A couple of points are included below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Michael C. Cambria Sent: Friday, January 16, 2004 8:39 AM To: RDDP Cc: Barry Reinhold Subject: Re: [rddp] Some questions related to "last segment" of a ddp message Barry Reinhold wrote: > Hemal, >=20 > I would like to check on a couple of issues: >=20 > I believe that it is possible to RECEIVE a sequence of DDP segments=20 > using the untagged buffer model as follows: Let me know if this is not > correct. >=20 > Segment 1: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (MO not 0 on = first)=20 > Segment 2: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (duplicate) = Segment=20 > 3: QN=3D1, MSN=3D1, MO=3D100, L=3D0 (payload 100) (backward) Segment = 4: QN=3D1,=20 > MSN=3D1, MO=3D000, L=3D0 (payload 050) (meets 6.3, MO field) Segment = 5:=20 > QN=3D1, MSN=3D1, MO=3D400, L=3D1 (payload 000) (meets 6.1 L bit > field) >=20 > In particular, > 1. If no packets have been received w/ a given MSN and QN and a packet > arrives with a non-zero MO this is not an error. > 2. The MO fields in intermediate segments are not constrained to be in > order, can have gaps, and can write over buffer space already written > to. My understanding is yes, yes and (re write over buffer space) not convinced. On pg 20 of draft-ietf-rddp-ddp-01.txt, "For an Untagged DDP Message,=20 the combination of the QN and MSN uniquely identifies a DDP Message."=20 Since an MSN doesn't make sense for a DDP _message_, I've read this to=20 mean that QN & MSN uniquely identifies a DDP _segment_. [prc] I suspect some misunderstanding here. An MSN (Message Sequence Number) specifically identifies which _message_ on the particular Queue the segment belongs to. Think of a queue with 5 2000 byte buffers, If TCP can manage=20 1500 bytes or so per segment, each buffer can hold two segments. The two segments for the second buffer might be identified by QN=3D1, = MSN=3D2, MO=3D0, L=3D1500 and QN=3D1, MSN=3D2, MO=3D1500, L=3D500. The two = segments have the same MSN, so your statement is not correct. [prc] So the way I read the draft, I can't find text that says one cannot send overlapping DDP segments. > Or from a test perspective, if a receiver returned an error when=20 > receiving the above sequence the receiver would be considered=20 > non-conformant. I'd return an error for several reasons. 1) I know of no legal untagged message on QN=3D1 that has a payload as=20 large as you describe. [prc] for DDP, all QN values are legal, and only the ULP can place limits on their size, what you say is true only if you are using RDMA as the next up ULP. [prc] 2) Where are payload bytes 50-99? 300-399? [prc] The receiver is not expected to check for overlaps, or holes in the data. So this is not a valid reason to report errors and there are no defined errors for this. Perhaps the draft should explicitly say not to report errors for these cases. As long as all the transmitter's data was placed and delivered, the receiver is compliant. In the case of overlaps, the receiver is not even required to make sure that the highest TCP sequence numbered segment was the last placed, so overlaps could lead to unpredictable delivered data. As a consequence of this, the transmitter SHOULD send data with no overlaps or holes, although an application could conceivably be designed to work even if this is not followed (some kind of test suite?). [prc] If I understand the example correctly, segment 4 provides DDP/RDMA=20 message bytes 0-49; segment 3 provides 100-199, segments 1 & 2 provide=20 200-300 [prc] one last comment; segment 5 (with zero length) is legal, and must be delivered. Further, even if no other data for the message arrived, the zero length message does consume an untagged buffer. [prc] MikeC _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 15:50:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21346 for ; Fri, 23 Jan 2004 15:50:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8Fy-0001pY-OO for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 15:50:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NKoMrt007035 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 15:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8Fy-0001pO-H8 for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 15:50:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21320 for ; Fri, 23 Jan 2004 15:50:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8Fm-0003Ao-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:50:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8DI-00036C-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:47:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak8Ap-00030s-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:45:03 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak8AR-0001fa-4L for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak89p-0001aC-K9; Fri, 23 Jan 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak899-0001Zh-Nj for rddp@optimus.ietf.org; Fri, 23 Jan 2004 15:43:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21194 for ; Fri, 23 Jan 2004 15:43:17 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak893-0002xn-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:43:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak86x-0002uO-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:41:04 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1Ak85P-0002ql-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:39:27 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 3D2182507C; Fri, 23 Jan 2004 13:39:02 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 232CFB2; Fri, 23 Jan 2004 13:39:02 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 13:39:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Date: Fri, 23 Jan 2004 13:39:01 -0700 Message-ID: Thread-Topic: [rddp] Some questions related to "last segment" of a ddp message Thread-Index: AcPbsD5eyHlUP7w+Sb2Jdy1X9me0YQGP0ktQ To: , Cc: X-OriginalArrivalTime: 23 Jan 2004 20:39:01.0988 (UTC) FILETIME=[EF4FA240:01C3E1F0] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry I believe the only ordering constraint we have in the draft is that the = segment with the L bit set must have the highest message offset. We did = that because we didn't want the require the receiver to scoreboard and = it is therefore necessary for correct operation. It allows the receiver = to determine total message length to report based on the information in = the last segment. We have no provisions in the untagged message passing for messages with = holes. So, the message sequence you presented would be an incorrect = sequence because of the gaps. If you added segments or changed offsets = and lengths to fill the gaps, it would be a valid sequence. As it is, = the gaps may be detected as an error by some receivers. It is possible that the draft could use a clearer statement that there = should be no holes in a message. Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Barry Reinhold Sent: Thursday, January 15, 2004 1:37 PM To: Hemal Shah Cc: RDDP Subject: [rddp] Some questions related to "last segment" of a ddp message Hemal, I would like to check on a couple of issues: I believe that it is possible to RECEIVE a sequence of DDP segments using the untagged buffer model as follows: Let me know if this is not correct. Segment 1: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (MO not 0 on = first) Segment 2: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (duplicate) Segment 3: QN=3D1, MSN=3D1, MO=3D100, L=3D0 (payload 100) (backward) Segment 4: QN=3D1, MSN=3D1, MO=3D000, L=3D0 (payload 050) (meets 6.3, MO = field) Segment 5: QN=3D1, MSN=3D1, MO=3D400, L=3D1 (payload 000) (meets 6.1 L = bit field) In particular,=20 1. If no packets have been received w/ a given MSN and QN and a packet arrives with a non-zero MO this is not an error. 2. The MO fields in intermediate segments are not constrained to be in order, can have gaps, and can write over buffer space already written to. Or from a test perspective, if a receiver returned an error when receiving the above sequence the receiver would be considered non-conformant. I am also a bit confused by the use of the term "last" in the draft. If the above is considered a valid sequence it is unclear to me how the receiver can meet the requirements of knowing that all DDP Segments of the DDP message have been placed before it "delivers" the DDP message to the ULP. (page 14 under L - Last flag, first bullet) Is there some method other than the L bit that indicates that all segments of a DDP message have been placed? (i.e. do implementations need to keep a scoreboard?) The draft (in clause 7.4, first *, on page 20) references a requirement on the receiver to deliver only when the last bit is set on the "last DDP Segment". How is the last segment defined beyond the L bit? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 15:57:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21725 for ; Fri, 23 Jan 2004 15:57:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8MI-0002DQ-CK for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 15:56:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NKusRt008510 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 15:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8MI-0002DB-8q for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 15:56:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21706 for ; Fri, 23 Jan 2004 15:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8MG-0003XV-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:56:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8LK-0003Ve-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:55:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak8KW-0003UN-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:55:04 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak8KX-0002Vo-4p for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 15:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8KU-00028Y-0K; Fri, 23 Jan 2004 15:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8KM-00027E-Nd for rddp@optimus.ietf.org; Fri, 23 Jan 2004 15:54:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21647 for ; Fri, 23 Jan 2004 15:54:52 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8KL-0003TA-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:54:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8Ja-0003Re-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:54:07 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8Ik-0003Of-00 for rddp@ietf.org; Fri, 23 Jan 2004 15:53:14 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 89FD625F94; Fri, 23 Jan 2004 13:53:14 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 73820A5; Fri, 23 Jan 2004 13:53:14 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 13:53:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Date: Fri, 23 Jan 2004 13:53:13 -0700 Message-ID: Thread-Topic: [rddp] Some questions related to "last segment" of a ddp message Thread-Index: AcPbsD5eyHlUP7w+Sb2Jdy1X9me0YQGQTGiQ To: , Cc: X-OriginalArrivalTime: 23 Jan 2004 20:53:13.0774 (UTC) FILETIME=[EB03DCE0:01C3E1F2] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry, The last segment is defined by the L bit and the segment with the L bit = must be the actual last segment in the stream sent to the transport. See = the definition of the L bit in 6.2 which says=20 The DDP Segment with the L bit set to 1 MUST be posted to the=20 LLP after all other DDP Segments of the associated DDP Message=20 have been posted to the LLP. For an Untagged DDP Message, the=20 DDP Segment with the L bit set to 1 MUST carry the highest MO.=20 The requirements on the transport include that it must allow DDP to = determine that all prior segments have been received (see requirement 5 = in section 5). The ordering rules in 7.4 require that all preceding DDP = messages MUST have been placed before a message may be delivered. So, = segments 1 through 4 in your example MUST be placed before the = completion in from segment 5 is delivered. The receiver doesn't have to scoreboard data placement. It only has to = know that the prior data stream has no gaps and that all placements for = that prior data stream have been completed. Regards, Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Barry Reinhold Sent: Thursday, January 15, 2004 1:37 PM To: Hemal Shah Cc: RDDP Subject: [rddp] Some questions related to "last segment" of a ddp message Hemal, I would like to check on a couple of issues: I believe that it is possible to RECEIVE a sequence of DDP segments using the untagged buffer model as follows: Let me know if this is not correct. Segment 1: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (MO not 0 on = first) Segment 2: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (duplicate) Segment 3: QN=3D1, MSN=3D1, MO=3D100, L=3D0 (payload 100) (backward) Segment 4: QN=3D1, MSN=3D1, MO=3D000, L=3D0 (payload 050) (meets 6.3, MO = field) Segment 5: QN=3D1, MSN=3D1, MO=3D400, L=3D1 (payload 000) (meets 6.1 L = bit field) In particular,=20 1. If no packets have been received w/ a given MSN and QN and a packet arrives with a non-zero MO this is not an error. 2. The MO fields in intermediate segments are not constrained to be in order, can have gaps, and can write over buffer space already written to. Or from a test perspective, if a receiver returned an error when receiving the above sequence the receiver would be considered non-conformant. I am also a bit confused by the use of the term "last" in the draft. If the above is considered a valid sequence it is unclear to me how the receiver can meet the requirements of knowing that all DDP Segments of the DDP message have been placed before it "delivers" the DDP message to the ULP. (page 14 under L - Last flag, first bullet) Is there some method other than the L bit that indicates that all segments of a DDP message have been placed? (i.e. do implementations need to keep a scoreboard?) The draft (in clause 7.4, first *, on page 20) references a requirement on the receiver to deliver only when the last bit is set on the "last DDP Segment". How is the last segment defined beyond the L bit? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 16:11:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23172 for ; Fri, 23 Jan 2004 16:11:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8Zt-0003Hm-OJ for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 16:10:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NLAvBO012624 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 16:10:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8Zt-0003HX-K8 for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 16:10:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23039 for ; Fri, 23 Jan 2004 16:10:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8Zn-00048p-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:10:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8Yq-00046g-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:09:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak8Y1-00045k-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8Y2-0003ER-2f; Fri, 23 Jan 2004 16:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8Xw-0003Db-O6 for rddp@optimus.ietf.org; Fri, 23 Jan 2004 16:08:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22978 for ; Fri, 23 Jan 2004 16:08:53 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8Xv-00044s-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:08:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8Wy-00043e-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:07:57 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8WZ-000422-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:07:31 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 460E423BAF; Fri, 23 Jan 2004 14:07:31 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 295961A7; Fri, 23 Jan 2004 14:07:31 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 14:07:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Date: Fri, 23 Jan 2004 14:07:30 -0700 Message-ID: Thread-Topic: [rddp] Some questions related to "last segment" of a ddp message Thread-Index: AcPbxYbW/O9O4711QleNFdMU8vtQQAGLY4jQ To: , Cc: , X-OriginalArrivalTime: 23 Jan 2004 21:07:30.0949 (UTC) FILETIME=[E9EE6350:01C3E1F4] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Caitlin, I don't see any "SHOULD" in the draft regarding sending the segments = into ascending order. Are you suggesting that there should be a SHOULD = or is there a SHOULD I am missing? I'm also not sure there is a technical reason that justifies such a = SHOULD. It would make scoreboarding (for a receiver that wants to add = extra error checking) during in-order delivery easier but that doesn't = seem to be a strong enough reason for a SHOULD especially since the = receiver would have to deal with cases where the transmitter wasn't = following the SHOULD. On overlapping - as long as the overlapped data is the same in both = segments, placement order of overlapping segments doesn't matter. = Message content had better not be changing while the message is being = transmitted anyway because that could cause problems even if there was = no overlapping. I can't see where overlapping gains anything and it is = wasteful of bandwidth so I don't have much problem with a SHOULD NOT or = MUST NOT, but I don't see much benefit to them either.=20 Regards, Pat -----Original Message----- From: Caitlin Bestler [mailto:cait@asomi.com] Sent: Thursday, January 15, 2004 4:10 PM To: Barry Reinhold Cc: Hemal Shah; RDDP Subject: Re: [rddp] Some questions related to "last segment" of a ddp message On Jan 15, 2004, at 3:37 PM, Barry Reinhold wrote: > Hemal, > > I would like to check on a couple of issues: > > I believe that it is possible to RECEIVE a sequence of DDP segments > using the untagged buffer model as follows: Let me know if this is not > correct. > > Segment 1: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (MO not 0 on = first) > Segment 2: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (duplicate) Overlapping (or duplicate) segments strike me as very suspect for the following reasons: a) If there is any overlap in the segments of an untagged message there is no guarantee which placement will occur last. Hence there can be no benefit to sending two segments covering the same bytes within an untagged message. b) It is clear that an untagged message SHOULD be broken into ascending segments, each the maximum size allowed. There may be valid reasons for alternate segmenting schemes, but one that produces no reliable results cannot possibly be a valid justification for overriding a "SHOULD". This does NOT imply that the receiver should be checking for overlaps, merely that there is no reason to take heroic efforts to deal with problems caused by overlaps. > Segment 3: QN=3D1, MSN=3D1, MO=3D100, L=3D0 (payload 100) (backward) Segments SHOULD be sent in ascending order (a non-requirement that I opposed). As a sender you should only do this if you have a valid reason that optimizes something. As a receiver, of course, you have to presume that the sender had a valid reason. More importantly, if you are optimized to process segments out-of-order you will never even notice that it happened. > Segment 4: QN=3D1, MSN=3D1, MO=3D000, L=3D0 (payload 050) (meets 6.3, = MO field) > Segment 5: QN=3D1, MSN=3D1, MO=3D400, L=3D1 (payload 000) (meets 6.1 L = bit > field) > > In particular, > 1. If no packets have been received w/ a given MSN and QN and a packet > arrives with a non-zero MO this is not an error. > 2. The MO fields in intermediate segments are not constrained to be in > order, can have gaps, and can write over buffer space already written > to. Gaps are not explicitly forbidden. But it is important to understand that the result will be non-determinant bytes in the target buffer, NOT unmodified bytes. For an unordered receiver, this is all irrelevant. The simplest implementation is to simply place all non-terminal segments, set the length from the segment with the L bit set, and assume that the entire message was delivered when the final segment is eligible for delivery. Remember that the receiver is allowed to (perhaps expected to) process segments in the order they arrive, which is not necessarily their order in the LLP stream. Note: as a security issue, implementations SHOULD ensure that "non-determinant" bytes are not actually bytes holding values once held by buffers used in another process. This is only a factor if intermediate buffering is used for reasons relating to optimizing cache flushes. > Or from a test perspective, if a receiver returned an error when > receiving the above sequence the receiver would be considered > non-conformant. Correct. A receiver has no business trying to diagnose this type of behavior in real-time. > > I am also a bit confused by the use of the term "last" in the draft. > The "Last" segment in LLP sequence must have the highest MO. But as your example points out, this can be cheated with a zero length message. > If the above is considered a valid sequence it is unclear to me how = the > receiver can meet the requirements of knowing that all DDP Segments of > the DDP message have been placed before it "delivers" the DDP message=20 > to > the ULP. (page 14 under L - Last flag, first bullet) For any DDP segment, the DDP layer is expected to determine whether all prior DDP segments (in LLP stream sequence) have been placed and delivered before it can be delivered. Even if the "last" segment is not yet deliverable, its contents can be placed, and the message length can be noted for later delivery. > > Is there some method other than the L bit that indicates that all > segments of a DDP message have been placed? (i.e. do implementations > need to keep a scoreboard?) The draft (in clause 7.4, first *, on page > 20) references a requirement on the receiver to deliver only when the > last bit is set on the "last DDP Segment". How is the last segment > defined beyond the L bit? > The last segment has three characteristics: 1) L bit set. 2) Highest LLP Sequence 3) Highest MO within the message If all DDP Segments for the LLP Stream have been placed, the receiver may assume that all prior segments for this message have been placed. The fact that the "last" DDP Segment must have the highest sequence in the LLP Stream allows the receiver to make this assumption without keeping a scoreboard. It is NOT something that the receiver should be attempting to enforce. --=20 Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 16:22:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24749 for ; Fri, 23 Jan 2004 16:22:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8ky-0003q3-Gq for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 16:22:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NLMOsW014749 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 16:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8ky-0003po-D2 for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 16:22:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24678 for ; Fri, 23 Jan 2004 16:22:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8kw-0005ur-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:22:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8js-0005lZ-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:21:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak8ij-0005Yu-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:20:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8ii-0003en-CO; Fri, 23 Jan 2004 16:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8ho-0003da-IU for rddp@optimus.ietf.org; Fri, 23 Jan 2004 16:19:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24156 for ; Fri, 23 Jan 2004 16:19:05 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8hm-0005OU-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:19:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8gW-0005As-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:17:49 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak8f3-0004vq-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:16:17 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 3B5D86FA4; Fri, 23 Jan 2004 14:16:16 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 1B25C1B9; Fri, 23 Jan 2004 14:16:16 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 14:16:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Fri, 23 Jan 2004 14:16:14 -0700 Message-ID: Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPcdY45SlJxbEkXQWimh0UH+QZZCQFf9xrg To: , X-OriginalArrivalTime: 23 Jan 2004 21:16:15.0283 (UTC) FILETIME=[22756830:01C3E1F6] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry, How I understand clause 6.1: The transmitter committed an error. The = receiver is not required to be checking the incoming data stream for = that error. As a matter of fact the reason for requireing the last = segment to carry the highest MO was to allow the receiver to not = scoreboard and to determine message length solely from the segment with = the L bit set. If we wanted to require the receiver to scoreboard, then we could remove = the requirement on highest MO. Therefore, the receiver has two valid options for reacting to the = sequence:=20 the one you proposed where it detects the error and reports it and=20 the one Paul proposed where it delivers the message reporting a message = length of 100 bytes. Regards, Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:07 PM To: RDDP Subject: FW: [rddp] DDP segment sequences for Untagged DDP message Oops, forgot to post to reflector... -----Original Message----- From: Barry Reinhold [mailto:bbr@lampreynetworks.com]=20 Sent: Friday, January 16, 2004 3:41 PM To: 'Culley, Paul' Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Paul, How do you understand clause 6.1 under the description of the L bit, which reads... The DDP Segment with the L bit set to 1 MUST be posted to the=20 LLP after all other DDP Segments of the associated DDP Message=20 have been posted to the LLP. For an Untagged DDP Message, the=20 DDP Segment with the L bit set to 1 MUST carry the highest MO. The second segment w/ L=3D1 arrives, but its MO is not the highest MO. What happens (as in the case below) when this condition is not true? >1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes >2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes >Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO >[prc] No, the receiver will place both segments, but inform the ULP that >only 100 bytes was delivered, ending at MO=3D99. No error should = be detected >or reported, unless the receiver's buffer was not large enough to hold the >second 100 bytes. -----Original Message----- From: Culley, Paul [mailto:paul.culley@hp.com]=20 Sent: Friday, January 16, 2004 3:28 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=3D99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. 1. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 200, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). 1. QN =3D 0, MSN =3D 1, MO =3D 300, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 1, Payload =3D 0 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error Code =3D = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP.=20 [prc], yes, but with unknown data values. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 16:27:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25348 for ; Fri, 23 Jan 2004 16:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8pS-00041e-A8 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 16:27:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NLR2xn015468 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 16:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8pS-00041P-5y for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 16:27:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25309 for ; Fri, 23 Jan 2004 16:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8pQ-0006TQ-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:27:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8oS-0006My-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:26:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak8nW-0006Dt-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8nW-0003vX-DB; Fri, 23 Jan 2004 16:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8mj-0003s2-ND for rddp@optimus.ietf.org; Fri, 23 Jan 2004 16:24:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24995 for ; Fri, 23 Jan 2004 16:24:10 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8mh-00067T-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:24:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8lg-000615-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:23:09 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak8ko-0005te-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:22:14 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 145296814; Fri, 23 Jan 2004 14:22:14 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id EF1847D; Fri, 23 Jan 2004 14:22:13 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 14:22:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Fri, 23 Jan 2004 14:22:13 -0700 Message-ID: Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPcky1bdZ6iRlmLRSucaz4tx2AHjQFYzqkQ To: , Cc: X-OriginalArrivalTime: 23 Jan 2004 21:22:13.0817 (UTC) FILETIME=[F8295A90:01C3E1F6] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This should be shown as: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: Error is reported Invalid MSN - MSN range is not valid This is a fatal error so there will be a teardown. =20 Pat -----Original Message----- From: Caitlin Bestler [mailto:cait@asomi.com] Sent: Friday, January 16, 2004 4:42 PM To: RDDP Cc: Barry Reinhold Subject: Re: [rddp] DDP segment sequences for Untagged DDP message On Jan 16, 2004, at 1:08 PM, Barry Reinhold wrote: > > So, is there agreement, for the sequences that follow, that the > specified "result" given below is the correct (and desired?) behavior=20 > as > defined by the 01 draft. > > Untagged DDP Segment Sequences: > > 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes > 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes > Result: DDP Message (bytes 0-200) is delivered to ULP > Did you mean to set the 'L' bit on message 1? If so, that is a sender violation, which as explained in Paul's response may or may not be caught by the receiver. If Msg 1 is completed *before* Msg 2 is placed, Msg 2 will be rejected as having an invalid MSN (it would be taken as being 2**32-1 ahead of the current location). In either case a 200 byte receive will be reported to the ULP. The question is whether the Stream is almost immediately thereafter torn down. --=20 Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 16:58:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28381 for ; Fri, 23 Jan 2004 16:58:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9Iz-0005VV-C7 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 16:57:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NLvXEr021163 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 16:57:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9Iz-0005VG-7f for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 16:57:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28270 for ; Fri, 23 Jan 2004 16:57:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak9Ix-0001rn-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:57:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak9Ho-0001f7-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:56:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak9FX-0001AR-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 16:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9FY-0005NK-AO; Fri, 23 Jan 2004 16:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9Ex-0005Iv-5K for rddp@optimus.ietf.org; Fri, 23 Jan 2004 16:53:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27315 for ; Fri, 23 Jan 2004 16:53:19 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak9Eu-00012C-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:53:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak97B-0000IU-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:45:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak92a-0007Qe-00 for rddp@ietf.org; Fri, 23 Jan 2004 16:40:37 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak921-00069t-Lr for rddp@ietf.org; Fri, 23 Jan 2004 16:40:01 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id C2C5E623C; Fri, 23 Jan 2004 14:39:36 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos1.cos.agilent.com (Postfix) with ESMTP id A8AE163; Fri, 23 Jan 2004 14:39:36 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 14:39:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Tagged vs Untagged wrt providing message length Date: Fri, 23 Jan 2004 14:39:36 -0700 Message-ID: Thread-Topic: [rddp] Tagged vs Untagged wrt providing message length Thread-Index: AcPerIaFwrhw7KnVRPy+sweGpw3P9gDSp9WQ To: , Cc: X-OriginalArrivalTime: 23 Jan 2004 21:39:36.0465 (UTC) FILETIME=[65A0D010:01C3E1F9] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry, Length would not mean anything for tagged messages. It means something = for untagged messages because they are required to always start at zero = so that the MO plus length of the segment with the L bit set are the = length of the message.=20 For tagged messages it is the responsibility of the ULP to transfer any = necessary information on what data was transfered in the tagged = messages. For example, in iSER when the target iSER layer sends the = Status message (an untagged message) after doing the tagged messages to = move the data associated with the command the status message contents = indicate what data was transfered. Another example is that in RDMAP the = untagged message RDMA read response indicates that the tagged transfers = required for the RDMA read have been completed. Regards, Pat -----Original Message----- From: Barry Reinhold [mailto:bbr@lampreynetworks.com] Sent: Monday, January 19, 2004 8:47 AM To: Hemal Shah Cc: RDDP Subject: [rddp] Tagged vs Untagged wrt providing message length Hemal (or whomever wishes to post), Clause 7.4 states that: "At the Data Sink, DDP MUST provide the ULP Message Length to the ULP=20 when an Untagged DDP Message is Delivered." Is it thus not required that the length be provided for Tagged DDP messages?=20 I guess I am unclear as to why length is needed for the untagged but not for the tagged. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 17:07:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29179 for ; Fri, 23 Jan 2004 17:07:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9S3-00067F-AO for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 17:06:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NM6tbU023503 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 17:06:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9S3-000670-73 for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 17:06:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29168 for ; Fri, 23 Jan 2004 17:06:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak9S1-0002cR-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:06:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak9R7-0002aO-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:05:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak9QE-0002Xz-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9QF-0005xe-Dn; Fri, 23 Jan 2004 17:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9PF-0005r9-NF for rddp@optimus.ietf.org; Fri, 23 Jan 2004 17:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29059 for ; Fri, 23 Jan 2004 17:03:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak9PD-0002Va-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:03:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak9Om-0002SV-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:03:33 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak9Nl-0002Dp-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:02:29 -0500 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 EF9CD244B04; Fri, 23 Jan 2004 17:03:01 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Pat Thaler From: Caitlin Bestler Subject: Re: [rddp] Some questions related to "last segment" of a ddp message Date: Fri, 23 Jan 2004 16:01:56 -0600 To: RDDP X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Jan 23, 2004, at 3:07 PM, wrote: > Caitlin, > > I don't see any "SHOULD" in the draft regarding sending the segments > into > ascending order. Are you suggesting that there should be a SHOULD or is > there a SHOULD I am missing? DDP section 7.3 ("Ordering Among DDP Messages") specifies: At the Data Source, DDP: * MUST transmit DDP Messages in the order they were submitted to the DDP layer, * SHOULD transmit DDP Segments within a DDP Message in increasing MO order for Untagged DDP Messages and in increasing TO order for Tagged DDP Messages. > > I'm also not sure there is a technical reason that justifies such a > SHOULD. > It would make scoreboarding (for a receiver that wants to add extra > error > checking) during in-order delivery easier but that doesn't seem to be a > strong enough reason for a SHOULD especially since the receiver would > have > to deal with cases where the transmitter wasn't following the SHOULD. More it importantly, it MAY deal with out-of-order delivery. You could even argue that it SHOULD NOT insist of processing segments in order if doing so increases the utilization of host memory (that is, processing in order SHOULD only be done if the re-ordering is done without extra usage of host memory). If you scan the archives you'll find a prolonged discussion on this point. I believe the alleged justification was essentially that it would optimize handling of complex scatter-gather-lists. That never struck me as a valid argument, and further making it a SHOULD negated any benefit that there might have been and only acted to discourage known valid optimizations. A "SHOULD" that has *common* valid reasons for being overridden is essentially a "nop". My opinion remains that the "SHOULD" clause ought to be removed, but it really doesn't have any negative impact. > > On overlapping - as long as the overlapped data is the same in both > segments, > placement order of overlapping segments doesn't matter. Message > content had > better not be changing while the message is being transmitted anyway > because > that could cause problems even if there was no overlapping. I can't > see where > overlapping gains anything and it is wasteful of bandwidth so I don't > have > much problem with a SHOULD NOT or MUST NOT, but I don't see much > benefit to > them either. > Agreed. The key here is that segmentation of untagged messages is not supposed to be under ULP control, and there is absolutely no way to justify a bandwidth-wasting algorithm at the DDP layer. From the point of view of the receiver, I agree that they are completely unworthy of run-time testing no matter how close to zero the cost is. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Jan 23 17:25:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29728 for ; Fri, 23 Jan 2004 17:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9jV-0007IT-1J for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 17:24:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NMOvCe028043 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 17:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9jU-0007IE-UF for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 17:24:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29711 for ; Fri, 23 Jan 2004 17:24:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak9jS-0003FZ-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:24:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak9iV-0003Ds-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:23:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak9hc-0003CD-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9hd-0007Eq-GB; Fri, 23 Jan 2004 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak9hV-0007EO-Lk for rddp@optimus.ietf.org; Fri, 23 Jan 2004 17:22:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29653 for ; Fri, 23 Jan 2004 17:22:49 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak9hT-0003BK-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:22:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak9gU-00038v-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:21:51 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak9fX-00036b-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:20:51 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 440D0729A; Fri, 23 Jan 2004 15:20:51 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 2982B300; Fri, 23 Jan 2004 15:20:51 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 15:20:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Tagged vs Untagged wrt providing message length Date: Fri, 23 Jan 2004 15:20:50 -0700 Message-ID: Thread-Topic: [rddp] Tagged vs Untagged wrt providing message length Thread-Index: AcPewoKbDX8YS3RsSda63w6bhe+K2gDOsqKQ To: , Cc: X-OriginalArrivalTime: 23 Jan 2004 22:20:50.0793 (UTC) FILETIME=[28714D90:01C3E1FF] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Caitlin, DDP doesn't provide notification of any placements - tagged or untagged = but it does provide notification of completion of a tagged message. A = tagged message has a header including a RsvdULP field that MUST be = passed to the ULP on completion and delivery of the message. For = instance, the RDMA Read Response is a tagged message. RDMAP needs to = receive the notice of that completion to know that the data for the RDMA = Read Request has been placed. (In an earlier email, I erred when I said = the response was an untagged message.) It is RDMAP that doesn't bother its ULP with delivery of some events = such as RDMA writes. Length isn't provided for tagged messages because the ULP is responsible = for exchanging that information if needed and because DDP doesn't know = the length. It would have to scoreboard to get the starting and ending = offsets for a Tagged message and it isn't required to do that. Regards, Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Caitlin Bestler Sent: Monday, January 19, 2004 11:17 AM To: RDDP Cc: Barry Reinhold Subject: Re: [rddp] Tagged vs Untagged wrt providing message length On Jan 19, 2004, at 10:46 AM, Barry Reinhold wrote: > Hemal (or whomever wishes to post), > Clause 7.4 states that: > > "At the Data Sink, DDP MUST provide the ULP Message Length to the ULP > when an Untagged DDP Message is Delivered." > > Is it thus not required that the length be provided for Tagged DDP > messages? > > I guess I am unclear as to why length is needed for the untagged but=20 > not > for the tagged. > > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > Normally DDP provides no notification of tagged placements to the ULP -- except that delivery of an untagged message cannot take place until all *prior* tagged messages have been fully placed. Further, even though the standard does not state that the DDP layer MUST NOT tell the ULP about individual tagged placements, the ULP MUST NOT use the buffers until the trailing untagged message is delivered. So there wouldn't be any point in supplying that information. The benefits of suppressing ULP interactions for tagged messages is covered in the applicability statement. http://www.ietf.org/internet-drafts/draft-ietf-rddp-applicability-01.txt --=20 Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 17:52:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00194 for ; Fri, 23 Jan 2004 17:52:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkA9i-0008Qj-W8 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 17:52:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NMq2qG032402 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 17:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkA9i-0008QX-Pe for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 17:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00170 for ; Fri, 23 Jan 2004 17:51:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkA9g-0003qx-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:52:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkA95-0003oY-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:51:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkA85-0003mQ-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:50:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkA7n-0008IJ-6P; Fri, 23 Jan 2004 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkA6m-0008HN-T0 for rddp@optimus.ietf.org; Fri, 23 Jan 2004 17:49:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00126 for ; Fri, 23 Jan 2004 17:48:56 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkA6f-0003kx-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:48:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkA4i-0003j4-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:46:53 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1AkA3P-0003hI-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:45:31 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 582A12287A; Fri, 23 Jan 2004 15:45:04 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 07989164; Fri, 23 Jan 2004 15:45:04 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 15:45:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Fri, 23 Jan 2004 15:45:03 -0700 Message-ID: Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPcb48HD/qiTTOeT3mP7IcqsaDR5wFj6fbg To: , , X-OriginalArrivalTime: 23 Jan 2004 22:45:03.0782 (UTC) FILETIME=[8A7DD460:01C3E202] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable My responses are marked pat -----Original Message----- From: Culley, Paul [mailto:paul.culley@hp.com] Sent: Friday, January 16, 2004 12:28 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes [pat]DDP message (bytes 0-200) occurs after 1. 2 will cause an invalid MSN error 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=3D99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. [pat] Checking for the error of last segment not containing highest MO = is optional. Both behaviors above would be valid responses. 1. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. [pat] agree.=20 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 200, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). [pat] There are two valid behaviors. The receiver may deliver the = message as above or it may be checking and report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 300, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown [pat] Again the receiver is allowed to deliver or to report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 1, Payload =3D 0 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error Code =3D = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. [pat] The ambiguity you point out is probably an error. The MUST on = checking Untagged DDP segments required that they be validated before = placement. A zero length segment isn't placed so the MUST didn't apply = to it. There probably should be a statement about checking the fields = before delivery of zero length untagged messages or zero length segments = with the L bit set. Also even if that statement is added, this is = another case where the receiver is allowed to deliver or report an = error. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes [pat] yes. Note that this is another case where there should be a = requirement that the zero length segment header values be checked before = delivery. 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP.=20 [prc], yes, but with unknown data values. [pat] May deliver the message or may scoreboard and report an error. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Fri Jan 23 17:59:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00564 for ; Fri, 23 Jan 2004 17:59:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkAGY-0000Nd-7t for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 17:59:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NMx66e001455 for rddp-archive@odin.ietf.org; Fri, 23 Jan 2004 17:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkAGY-0000NO-4K for rddp-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 17:59:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00545 for ; Fri, 23 Jan 2004 17:59:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkAGV-0004E4-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:59:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkAFX-0004BR-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:58:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkAEa-00048O-00 for rddp-web-archive@ietf.org; Fri, 23 Jan 2004 17:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkAEY-0000Bf-8K; Fri, 23 Jan 2004 17:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkAEU-0000As-1M for rddp@optimus.ietf.org; Fri, 23 Jan 2004 17:56:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00421 for ; Fri, 23 Jan 2004 17:56:53 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkAER-00047B-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:56:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkADY-00043j-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:56:01 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1AkACb-0003z7-00 for rddp@ietf.org; Fri, 23 Jan 2004 17:55:02 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id D7B0E7370; Fri, 23 Jan 2004 15:54:56 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos2.cos.agilent.com (Postfix) with ESMTP id BA99C177; Fri, 23 Jan 2004 15:54:56 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 15:54:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Fri, 23 Jan 2004 15:54:56 -0700 Message-ID: Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPiA0Y262TFAs+eR6+W7dytnbE1sQAACsTA To: , , , X-OriginalArrivalTime: 23 Jan 2004 22:54:56.0563 (UTC) FILETIME=[EBD10830:01C3E203] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable As MikeC pointed out to me, in the examples below the message end is off = by one byte. For example,=20 Untagged DDP Segment Sequences: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP ^^^ should be 199 [prc] yes [pat]DDP message (bytes 0-200) occurs after 1. ^^^ 199 2 will cause an invalid MSN error The first byte in the message was 100 and there were 100 bytes so the = last byte was 199. Pat -----Original Message----- From: pat_thaler@agilent.com=20 Sent: Friday, January 23, 2004 2:45 PM To: paul.culley@hp.com; bbr@lampreynetworks.com; rddp@ietf.org Subject: RE: [rddp] DDP segment sequences for Untagged DDP message My responses are marked pat -----Original Message----- From: Culley, Paul [mailto:paul.culley@hp.com] Sent: Friday, January 16, 2004 12:28 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes [pat]DDP message (bytes 0-200) occurs after 1. 2 will cause an invalid MSN error 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=3D99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. [pat] Checking for the error of last segment not containing highest MO = is optional. Both behaviors above would be valid responses. 1. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. [pat] agree.=20 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 200, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). [pat] There are two valid behaviors. The receiver may deliver the = message as above or it may be checking and report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 300, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown [pat] Again the receiver is allowed to deliver or to report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 1, Payload =3D 0 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error Code =3D = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. [pat] The ambiguity you point out is probably an error. The MUST on = checking Untagged DDP segments required that they be validated before = placement. A zero length segment isn't placed so the MUST didn't apply = to it. There probably should be a statement about checking the fields = before delivery of zero length untagged messages or zero length segments = with the L bit set. Also even if that statement is added, this is = another case where the receiver is allowed to deliver or report an = error. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes [pat] yes. Note that this is another case where there should be a = requirement that the zero length segment header values be checked before = delivery. 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP.=20 [prc], yes, but with unknown data values. [pat] May deliver the message or may scoreboard and report an error. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Sat Jan 24 14:40:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20959 for ; Sat, 24 Jan 2004 14:40:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkTdG-0007xH-60 for rddp-archive@odin.ietf.org; Sat, 24 Jan 2004 14:39:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OJdofX030575 for rddp-archive@odin.ietf.org; Sat, 24 Jan 2004 14:39:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkTdG-0007x4-1a for rddp-web-archive@optimus.ietf.org; Sat, 24 Jan 2004 14:39:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20918 for ; Sat, 24 Jan 2004 14:39:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkTdD-0000I8-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 14:39:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkTcH-0000E8-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 14:38:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkTbV-0000AW-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 14:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkTbX-0007t1-1g; Sat, 24 Jan 2004 14:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkTbI-0007n7-Ut for rddp@optimus.ietf.org; Sat, 24 Jan 2004 14:37:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20758 for ; Sat, 24 Jan 2004 14:37:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkTbG-000086-00 for rddp@ietf.org; Sat, 24 Jan 2004 14:37:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkTaI-0007mw-00 for rddp@ietf.org; Sat, 24 Jan 2004 14:36:49 -0500 Received: from mail3.ttlc.net ([66.94.32.26] helo=mail.communicom.net) by ietf-mx with esmtp (Exim 4.12) id 1AkTYL-0007I4-00 for rddp@ietf.org; Sat, 24 Jan 2004 14:34:45 -0500 Received: from lampreynetworks.com [66.94.32.4] by mail.communicom.net with ESMTP (SMTPD32-7.07) id AA40104000CA; Sat, 24 Jan 2004 14:40:48 -0500 Received: from i8600 [24.61.195.169] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id AA3E17EC0140; Sat, 24 Jan 2004 14:40:46 -0500 From: "Barry Reinhold" To: , , Cc: Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Date: Sat, 24 Jan 2004 14:34:38 -0500 Message-ID: <000901c3e2b1$1b27ae60$c282a8c0@i8600> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, Although I don't consider myself a conservative, the interpretation of the specification here is starting to get too liberal for my taste. (Sorry, it's primary time here in New Hampshire...) I do think there is an issue here in terms of what we are expecting when the sender "SHOULD" send a message in a particular format. If the sender SHOULD send the message using format A, this implies that the receiver MUST accept format A and B (assuming a choice between A and B). Thus the receiver MUST NOT return an error if the message arrives using format "B". This is important for interoperability. If a specification allows a behavior (SHOULD implies allowing a behavior that is not the "desired" behavior) then the receiver has got to support it, otherwise some pairs of devices just won't work. I do not have a strong opinion as to what is the proper choice in terms of behavior with overlaps/gaps. However, I do think it is important that the specification be written in a way that the behavior is clear. As currently written I believe that the draft: 1. Requires that all data of a DDP message must be sent (Clause 7.2 - "At the Data Source, the DDP layer MUST send all the data contained in the ULP message.") 2. States that the sender is not required to send DDP segments in order (Clause 7.3 - "At the Data Source, DDP: * MUST transmit DDP Messages in the order they were submitted to the DDP layer, [Note that this is messages, not segments] * SHOULD transmit DDP Segments within a DDP Message in increasing MO order for Untagged DDP Messages and in increasing TO order for Tagged DDP Messages.") The above statements, I believe, imply that the receiving DDP layer MUST NOT send an error for duplicated data or out of order data. One could argue that a gap is impossible based on point 1, but it would be a weak, or indirect, argument. I would propose that we identify what is desired (do we allow duplicates/gaps?) and write the document so that the behavior of the receiver is clear. -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, January 23, 2004 3:29 PM To: paul.culley@hp.com; mcc@fid4.com; rddp@ietf.org Cc: bbr@lampreynetworks.com Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Paul, RE: 2) Where are payload bytes 50-99? 300-399? [prc] The receiver is not expected to check for overlaps, or holes in the data. So this is not a valid reason to report errors and there are no defined errors for this. Perhaps the draft should explicitly say not to report errors for these cases. As long as all the transmitter's data was placed and delivered, the receiver is compliant. In the case of overlaps, the receiver is not even required to make sure that the highest TCP sequence numbered segment was the last placed, so overlaps could lead to unpredictable delivered data. As a consequence of this, the transmitter SHOULD send data with no overlaps or holes, although an application could conceivably be designed to work even if this is not followed (some kind of test suite?). [prc] The receiver is not required to check for overlaps and holes but there isn't anyplace that disallows it doing so. I believe that this was our intent when we wrote it and it is consistant with the text in the draft - 7.2 says at the end that the Data Sink is not required to verify that the entire message has been received. It doesn't prohibit checking. So it would be valid behavior to detect an error because of the missing bytes. It would also be valid behavior to not detect that error. Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Culley, Paul Sent: Friday, January 16, 2004 7:33 AM To: Michael C. Cambria; RDDP Cc: Barry Reinhold Subject: RE: [rddp] Some questions related to "last segment" of a ddp message A couple of points are included below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Michael C. Cambria Sent: Friday, January 16, 2004 8:39 AM To: RDDP Cc: Barry Reinhold Subject: Re: [rddp] Some questions related to "last segment" of a ddp message Barry Reinhold wrote: > Hemal, > > I would like to check on a couple of issues: > > I believe that it is possible to RECEIVE a sequence of DDP segments > using the untagged buffer model as follows: Let me know if this is not > correct. > > Segment 1: QN=1, MSN=1, MO=200, L=0 (payload 100) (MO not 0 on first) > Segment 2: QN=1, MSN=1, MO=200, L=0 (payload 100) (duplicate) Segment > 3: QN=1, MSN=1, MO=100, L=0 (payload 100) (backward) Segment 4: QN=1, > MSN=1, MO=000, L=0 (payload 050) (meets 6.3, MO field) Segment 5: > QN=1, MSN=1, MO=400, L=1 (payload 000) (meets 6.1 L bit > field) > > In particular, > 1. If no packets have been received w/ a given MSN and QN and a packet > arrives with a non-zero MO this is not an error. > 2. The MO fields in intermediate segments are not constrained to be in > order, can have gaps, and can write over buffer space already written > to. My understanding is yes, yes and (re write over buffer space) not convinced. On pg 20 of draft-ietf-rddp-ddp-01.txt, "For an Untagged DDP Message, the combination of the QN and MSN uniquely identifies a DDP Message." Since an MSN doesn't make sense for a DDP _message_, I've read this to mean that QN & MSN uniquely identifies a DDP _segment_. [prc] I suspect some misunderstanding here. An MSN (Message Sequence Number) specifically identifies which _message_ on the particular Queue the segment belongs to. Think of a queue with 5 2000 byte buffers, If TCP can manage 1500 bytes or so per segment, each buffer can hold two segments. The two segments for the second buffer might be identified by QN=1, MSN=2, MO=0, L=1500 and QN=1, MSN=2, MO=1500, L=500. The two segments have the same MSN, so your statement is not correct. [prc] So the way I read the draft, I can't find text that says one cannot send overlapping DDP segments. > Or from a test perspective, if a receiver returned an error when > receiving the above sequence the receiver would be considered > non-conformant. I'd return an error for several reasons. 1) I know of no legal untagged message on QN=1 that has a payload as large as you describe. [prc] for DDP, all QN values are legal, and only the ULP can place limits on their size, what you say is true only if you are using RDMA as the next up ULP. [prc] 2) Where are payload bytes 50-99? 300-399? [prc] The receiver is not expected to check for overlaps, or holes in the data. So this is not a valid reason to report errors and there are no defined errors for this. Perhaps the draft should explicitly say not to report errors for these cases. As long as all the transmitter's data was placed and delivered, the receiver is compliant. In the case of overlaps, the receiver is not even required to make sure that the highest TCP sequence numbered segment was the last placed, so overlaps could lead to unpredictable delivered data. As a consequence of this, the transmitter SHOULD send data with no overlaps or holes, although an application could conceivably be designed to work even if this is not followed (some kind of test suite?). [prc] If I understand the example correctly, segment 4 provides DDP/RDMA message bytes 0-49; segment 3 provides 100-199, segments 1 & 2 provide 200-300 [prc] one last comment; segment 5 (with zero length) is legal, and must be delivered. Further, even if no other data for the message arrived, the zero length message does consume an untagged buffer. [prc] MikeC _______________________________________________ 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 exim@www1.ietf.org Sat Jan 24 15:10:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22422 for ; Sat, 24 Jan 2004 15:10:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkU69-0007fX-Es for rddp-archive@odin.ietf.org; Sat, 24 Jan 2004 15:09:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OK9fRe029473 for rddp-archive@odin.ietf.org; Sat, 24 Jan 2004 15:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkU69-0007fI-A5 for rddp-web-archive@optimus.ietf.org; Sat, 24 Jan 2004 15:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22397 for ; Sat, 24 Jan 2004 15:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkU66-0001ad-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 15:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkU5C-0001Z6-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 15:08:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkU4U-0001Xe-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 15:07:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkU4W-000702-Ea; Sat, 24 Jan 2004 15:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkU4B-0006mU-L7 for rddp@optimus.ietf.org; Sat, 24 Jan 2004 15:07:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22224 for ; Sat, 24 Jan 2004 15:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkU48-0001XE-00 for rddp@ietf.org; Sat, 24 Jan 2004 15:07:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkU3B-0001WC-00 for rddp@ietf.org; Sat, 24 Jan 2004 15:06:39 -0500 Received: from mail3.ttlc.net ([66.94.32.26] helo=mail.communicom.net) by ietf-mx with esmtp (Exim 4.12) id 1AkU35-0001Ur-00 for rddp@ietf.org; Sat, 24 Jan 2004 15:06:31 -0500 Received: from lampreynetworks.com [66.94.32.4] by mail.communicom.net with ESMTP (SMTPD32-7.07) id A1BB250E00CC; Sat, 24 Jan 2004 15:12:43 -0500 Received: from i8600 [24.61.195.169] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A1BA10D50104; Sat, 24 Jan 2004 15:12:42 -0500 From: "Barry Reinhold" To: , Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Sat, 24 Jan 2004 15:06:33 -0500 Message-ID: <000b01c3e2b5$90c3e0e0$c282a8c0@i8600> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, I can see what you are saying. But I'm not sure the option of doing both things is what we would want from the perspective of interoperability. It's a bit of a corner case but having one system deliver data and the other return an error is not what I would like to see in terms of spec. development. -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, January 23, 2004 4:16 PM To: bbr@lampreynetworks.com; rddp@ietf.org Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Barry, How I understand clause 6.1: The transmitter committed an error. The receiver is not required to be checking the incoming data stream for that error. As a matter of fact the reason for requireing the last segment to carry the highest MO was to allow the receiver to not scoreboard and to determine message length solely from the segment with the L bit set. If we wanted to require the receiver to scoreboard, then we could remove the requirement on highest MO. Therefore, the receiver has two valid options for reacting to the sequence: the one you proposed where it detects the error and reports it and the one Paul proposed where it delivers the message reporting a message length of 100 bytes. Regards, Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:07 PM To: RDDP Subject: FW: [rddp] DDP segment sequences for Untagged DDP message Oops, forgot to post to reflector... -----Original Message----- From: Barry Reinhold [mailto:bbr@lampreynetworks.com] Sent: Friday, January 16, 2004 3:41 PM To: 'Culley, Paul' Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Paul, How do you understand clause 6.1 under the description of the L bit, which reads... The DDP Segment with the L bit set to 1 MUST be posted to the LLP after all other DDP Segments of the associated DDP Message have been posted to the LLP. For an Untagged DDP Message, the DDP Segment with the L bit set to 1 MUST carry the highest MO. The second segment w/ L=1 arrives, but its MO is not the highest MO. What happens (as in the case below) when this condition is not true? >1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes >2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes >Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid MO >[prc] No, the receiver will place both segments, but inform the ULP that >only 100 bytes was delivered, ending at MO=99. No error should be detected >or reported, unless the receiver's buffer was not large enough to hold the >second 100 bytes. -----Original Message----- From: Culley, Paul [mailto:paul.culley@hp.com] Sent: Friday, January 16, 2004 3:28 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes 1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. 1. QN = 0, MSN = 1, MO = 0, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. 1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 200, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). 1. QN = 0, MSN = 1, MO = 300, L = 1, Payload = 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown 1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 000, L = 1, Payload = 0 bytes Result: ULP sent Error type=Untagged Buffer Error, Error Code = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. 1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes 2. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP. [prc], yes, but with unknown data values. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ 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 exim@www1.ietf.org Sat Jan 24 15:51:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23816 for ; Sat, 24 Jan 2004 15:51:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkUjl-0002x5-KV for rddp-archive@odin.ietf.org; Sat, 24 Jan 2004 15:50:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OKob06011341 for rddp-archive@odin.ietf.org; Sat, 24 Jan 2004 15:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkUjl-0002wq-HK for rddp-web-archive@optimus.ietf.org; Sat, 24 Jan 2004 15:50:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23808 for ; Sat, 24 Jan 2004 15:50:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkUjj-00036w-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 15:50:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkUio-000351-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 15:49:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkUiD-00033T-00 for rddp-web-archive@ietf.org; Sat, 24 Jan 2004 15:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkUiD-0002sv-5k; Sat, 24 Jan 2004 15:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkUhp-0002rg-Ai for rddp@optimus.ietf.org; Sat, 24 Jan 2004 15:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23794 for ; Sat, 24 Jan 2004 15:48:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkUhn-00032J-00 for rddp@ietf.org; Sat, 24 Jan 2004 15:48:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkUgt-00030e-00 for rddp@ietf.org; Sat, 24 Jan 2004 15:47:40 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AkUgJ-0002wg-00 for rddp@ietf.org; Sat, 24 Jan 2004 15:47:03 -0500 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 9C0422458E8; Sat, 24 Jan 2004 15:47:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <000901c3e2b1$1b27ae60$c282a8c0@i8600> References: <000901c3e2b1$1b27ae60$c282a8c0@i8600> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63C784DD-4EAE-11D8-8B3E-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] Some questions related to "last segment" of a ddp message Date: Sat, 24 Jan 2004 14:46:31 -0600 To: Barry Reinhold , RDDP X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Jan 24, 2004, at 1:34 PM, Barry Reinhold wrote: > Pat, > Although I don't consider myself a conservative, the > interpretation of the specification here is starting to get too liberal > for my taste. (Sorry, it's primary time here in New Hampshire...) > > I do think there is an issue here in terms of what we are expecting > when > the sender "SHOULD" send a message in a particular format. If the > sender > SHOULD send the message using format A, this implies that the receiver > MUST accept format A and B (assuming a choice between A and B). Thus > the > receiver MUST NOT return an error if the message arrives using format > "B". > > This is important for interoperability. If a specification allows a > behavior (SHOULD implies allowing a behavior that is not the "desired" > behavior) then the receiver has got to support it, otherwise some pairs > of devices just won't work. > > I believe that the specification is already clear. The Receiver MAY/SHOULD assume that each segment it receives is part of a message, and that messages have been properly broken down into segments. But ultimately, the receiver only needs to track the LLP sequence (to determine if all prior placements have completed) and the 'L' bit. In the spirit of "be conservative in what you send and liberal in what you accept" the receiver SHOULD NOT perform additional error checking. But for it to be *incorrect* for the receiver to reject a set of segments there must be some way that they can be a valid translation of a message. Given that all bytes within a message have a known value, there is no way to translate it into a set of segments that have holes. It is equally arguable that while overlapping segments is a waste of network bandwidth that cannot be justified over a reliable transport, that it might be incorrect for the receiver to enforce network bandwidth preservation. But this is all very abstract because everyone agrees that there is no need for the receiver to perform these checks. Is anyone's receiver *looking* for more work to do? _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sun Jan 25 19:16:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24543 for ; Sun, 25 Jan 2004 19:16:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkuPf-0006On-Sd for rddp-archive@odin.ietf.org; Sun, 25 Jan 2004 19:15:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0Q0FZAM024591 for rddp-archive@odin.ietf.org; Sun, 25 Jan 2004 19:15:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkuPf-0006OY-PT for rddp-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 19:15:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24537 for ; Sun, 25 Jan 2004 19:15:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkuPe-0002RL-00 for rddp-web-archive@ietf.org; Sun, 25 Jan 2004 19:15:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkuOe-0002OD-00 for rddp-web-archive@ietf.org; Sun, 25 Jan 2004 19:14:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkuO9-0002MJ-00 for rddp-web-archive@ietf.org; Sun, 25 Jan 2004 19:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkuO8-0006HO-QC; Sun, 25 Jan 2004 19:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkuNd-0006Gx-Hu for rddp@optimus.ietf.org; Sun, 25 Jan 2004 19:13:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24474 for ; Sun, 25 Jan 2004 19:13:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkuNb-0002LC-00 for rddp@ietf.org; Sun, 25 Jan 2004 19:13:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkuMf-0002Hf-00 for rddp@ietf.org; Sun, 25 Jan 2004 19:12:29 -0500 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 1AkuLo-0002An-00 for rddp@ietf.org; Sun, 25 Jan 2004 19:11:37 -0500 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.35]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 22F66EB7F for ; Sun, 25 Jan 2004 18:11:02 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 25 Jan 2004 18:11:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Jan 2004 18:10:56 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762CC6975B@cceexc18.americas.cpqcorp.net> Thread-Topic: I-D ACTION:draft-culley-mpa-issueresponses-00.txt Thread-Index: AcPiu4iW/xjhVLTESDSGV9ComGKgFwA5Q1fw From: "Culley, Paul" To: "RDDP" X-OriginalArrivalTime: 26 Jan 2004 00:11:01.0975 (UTC) FILETIME=[E1D71E70:01C3E3A0] Content-Transfer-Encoding: quoted-printable Subject: [rddp] I-D ACTION:draft-culley-mpa-issueresponses-00.txt 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The following should be of interest to this group... Paul R. Culley HP Fellow 281-514-5543 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Comment responses for Marker PDU Aligned Framing for TCP Specification Author(s) : P. Culley Filename : draft-culley-mpa-issueresponses-00.txt Pages : 0 Date : 2004-1-23 =09 This draft is a response to comments about draft-ietf-rddp-mpa-00 received on the RDDP reflector, the response is long enough to warrant a draft. Comments on connection startup sequence, rejecting a connection, and allowing 'Active/Active' connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-culley-mpa-issueresponses-00.t xt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-culley-mpa-issueresponses-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-culley-mpa-issueresponses-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Jan 27 09:06:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05411 for ; Tue, 27 Jan 2004 09:06:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTqa-0000vd-9R for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 09:05:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RE5ifr003565 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 09:05:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTqa-0000vQ-5x for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 09:05:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05405 for ; Tue, 27 Jan 2004 09:05:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTqY-0003YQ-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 09:05:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTpf-0003WA-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 09:04:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlTov-0003Ti-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 09:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTou-0000rT-M0; Tue, 27 Jan 2004 09:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlToh-0000qg-0k for rddp@optimus.ietf.org; Tue, 27 Jan 2004 09:03:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05353 for ; Tue, 27 Jan 2004 09:03:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTof-0003SX-00 for rddp@ietf.org; Tue, 27 Jan 2004 09:03:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTnr-0003Py-00 for rddp@ietf.org; Tue, 27 Jan 2004 09:02:56 -0500 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 1AlTnF-0003I7-00 for rddp@ietf.org; Tue, 27 Jan 2004 09:02:18 -0500 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.35]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 966A3B04C; Tue, 27 Jan 2004 08:01:36 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 27 Jan 2004 08:01:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Tue, 27 Jan 2004 08:01:34 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762CC698C7@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPcb48HD/qiTTOeT3mP7IcqsaDR5wFj6fbgAIXw9SA= From: "Culley, Paul" To: , , X-OriginalArrivalTime: 27 Jan 2004 14:01:35.0804 (UTC) FILETIME=[1387B7C0:01C3E4DE] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Note: this is the second sending, it did not show after the first time within 24 hours... OK, I realize that I missed a small point; in the first case below=20 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes [pat]DDP message (bytes 0-200) occurs after 1. 2 will cause an invalid MSN error I was thinking of TCP segments as they arrive at the receiver, not as sent at the transmitter. If the example was sent in this order, I agree that an invalid MSN error is the correct answer, if they were merely received in this order (they got flipped in route and were received out of order, but sent in order), then the result would be a normal delivery. I am not certain I agree with Pat on the "optional" nature of checking for errors that are not even mentioned in the specification. I think that if we have to list all of the checks that we DO NOT perform in the specifications, then we have quite a bit of writing left to do. That said, we should perhaps be a bit more clear about the rules on Sending overlapped segments, or Sending Gaps. I am definitely not in favor of requiring the receiver to check for either case. If we were to add text to DDP for this I think it would say something like: When sending an Untagged Message, the Sender MUST send data to each offset within the target buffer only one time. When sending an Untagged Message, the Sender MUST send a contiguous stream of bytes to the destination buffer, starting at offset 0. In my mind, we should allow the receiver to check for these conditions only if these rules are made on the sender. Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]=20 Sent: Friday, January 23, 2004 4:45 PM To: Culley, Paul; bbr@lampreynetworks.com; rddp@ietf.org Subject: RE: [rddp] DDP segment sequences for Untagged DDP message My responses are marked pat -----Original Message----- From: Culley, Paul [mailto:paul.culley@hp.com] Sent: Friday, January 16, 2004 12:28 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes [pat]DDP message (bytes 0-200) occurs after 1. 2 will cause an invalid MSN error 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=3D99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. [pat] Checking for the error of last segment not containing highest MO is optional. Both behaviors above would be valid responses. 1. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. [pat] agree.=20 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 200, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). [pat] There are two valid behaviors. The receiver may deliver the message as above or it may be checking and report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 300, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown [pat] Again the receiver is allowed to deliver or to report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 1, Payload =3D 0 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error Code =3D = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. [pat] The ambiguity you point out is probably an error. The MUST on checking Untagged DDP segments required that they be validated before placement. A zero length segment isn't placed so the MUST didn't apply to it. There probably should be a statement about checking the fields before delivery of zero length untagged messages or zero length segments with the L bit set. Also even if that statement is added, this is another case where the receiver is allowed to deliver or report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes [pat] yes. Note that this is another case where there should be a requirement that the zero length segment header values be checked before delivery. 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP.=20 [prc], yes, but with unknown data values. [pat] May deliver the message or may scoreboard and report an error. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Tue Jan 27 10:04:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07698 for ; Tue, 27 Jan 2004 10:04:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlUkx-0007c5-BY for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 10:03:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RF3xcq029259 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 10:03:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlUkx-0007bq-8W for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 10:03:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07634 for ; Tue, 27 Jan 2004 10:03:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlUkv-0007Ds-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 10:03:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlUjy-00079y-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 10:02:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlUj3-00074V-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 10:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlUj3-0006L5-R0; Tue, 27 Jan 2004 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlUix-0006Hh-Az for rddp@optimus.ietf.org; Tue, 27 Jan 2004 10:01:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07441 for ; Tue, 27 Jan 2004 10:01:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlUiv-00073T-00 for rddp@ietf.org; Tue, 27 Jan 2004 10:01:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlUi0-0006xK-00 for rddp@ietf.org; Tue, 27 Jan 2004 10:00:56 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AlUh1-0006pj-00 for rddp@ietf.org; Tue, 27 Jan 2004 09:59:55 -0500 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 85876244B92; Tue, 27 Jan 2004 10:00:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762CC698C7@cceexc18.americas.cpqcorp.net> References: <4D027986353D1341ADA4F2A4F8A170762CC698C7@cceexc18.americas.cpqcorp.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63E720DE-50D9-11D8-A942-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] DDP segment sequences for Untagged DDP message Date: Tue, 27 Jan 2004 08:59:22 -0600 To: Paul Culley , RDDP X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Jan 27, 2004, at 8:01 AM, Culley, Paul wrote: > OK, I realize that I missed a small point; in the first case below > > 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes > 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes > Result: DDP Message (bytes 0-200) is delivered to ULP > [prc] yes > [pat]DDP message (bytes 0-200) occurs after 1. > 2 will cause an invalid MSN error > > I was thinking of TCP segments as they arrive at the receiver, not as > sent at the transmitter. If the example was sent in this order, I > agree > that an invalid MSN error is the correct answer, The MSN is invalid, but the receiver is not obligated to catch it. If DDP-Segment 2 is placed *before* DDP-Segment 1 is completed, then no error will be detected. Both the MO and MSN are in range. The 100 bytes will be placed. This obviously can occur if DDP-Segment 2 arrives before DDP-Segment 1. But it can also occur if they arrive in order and the receiver pipelines processing of DDP-Segments. Remember that all implications of out-of-order processing hold no matter what the reason for the out-of-order processing is. The packets do not have to have been in the "wrong order" on the wire for out-of-order processing to occur. Similarly, the fact that MSN 17 invalidated STag 504 does not guarantee that use of STag 504 in a tagged message that is latter in the LLP stream will be flagged as an error. Invalidation is only guaranteed by the time it is reported to the Data Sink ULP. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Jan 27 12:31:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15403 for ; Tue, 27 Jan 2004 12:31:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlX3Q-0004II-D3 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 12:31:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RHVCpW016500 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 12:31:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlX3Q-0004I3-7X for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 12:31:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15307 for ; Tue, 27 Jan 2004 12:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlX3O-0001ot-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 12:31:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlX1l-0001WL-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 12:29:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AlX0P-0001FB-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 12:28:05 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AlX0P-00020Y-Kl for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 12:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlX0L-0003jP-M6; Tue, 27 Jan 2004 12:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWzY-0003g4-Hh for rddp@optimus.ietf.org; Tue, 27 Jan 2004 12:27:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14781 for ; Tue, 27 Jan 2004 12:27:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWzW-00014T-00 for rddp@ietf.org; Tue, 27 Jan 2004 12:27:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWxo-0000li-00 for rddp@ietf.org; Tue, 27 Jan 2004 12:25:25 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AlWwe-0000a2-00 for rddp@ietf.org; Tue, 27 Jan 2004 12:24:12 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel12.hp.com (Postfix) with ESMTP id 2AD341C02342 for ; Tue, 27 Jan 2004 09:24:12 -0800 (PST) Received: from mk731915.cup.hp.com ([15.8.80.111]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id i0RHF8a02152 for ; Tue, 27 Jan 2004 09:15:08 -0800 (PST) Message-Id: <5.1.0.14.2.20040127063419.02b47788@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 Jan 2004 06:37:52 -0800 To: From: Michael Krause Subject: RE: [rddp] DDP segment sequences for Untagged DDP message In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762CC698C7@cceexc18.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 08:01 AM 1/27/2004 -0600, Culley, Paul wrote: >Note: this is the second sending, it did not show after the first time >within 24 hours... > >OK, I realize that I missed a small point; in the first case below > > 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes > 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes > Result: DDP Message (bytes 0-200) is delivered to ULP > [prc] yes > [pat]DDP message (bytes 0-200) occurs after 1. > 2 will cause an invalid MSN error > >I was thinking of TCP segments as they arrive at the receiver, not as >sent at the transmitter. If the example was sent in this order, I agree >that an invalid MSN error is the correct answer, if they were merely >received in this order (they got flipped in route and were received out >of order, but sent in order), then the result would be a normal >delivery. > >I am not certain I agree with Pat on the "optional" nature of checking >for errors that are not even mentioned in the specification. I think >that if we have to list all of the checks that we DO NOT perform in the >specifications, then we have quite a bit of writing left to do. It would be both impractical to document all that should not be done and a pain / low ROI to test for compliance. >That said, we should perhaps be a bit more clear about the rules on >Sending overlapped segments, or Sending Gaps. I am definitely not in >favor of requiring the receiver to check for either case. Concur. >If we were to add text to DDP for this I think it would say something like: > >When sending an Untagged Message, the Sender MUST send data to each >offset within the target buffer only one time. > >When sending an Untagged Message, the Sender MUST send a contiguous >stream of bytes to the destination buffer, starting at offset 0. > >In my mind, we should allow the receiver to check for these conditions >only if these rules are made on the sender. I don't think we need to add these. Mike >Paul R. Culley >HP Fellow >281-514-5543 > > >-----Original Message----- >From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] >Sent: Friday, January 23, 2004 4:45 PM >To: Culley, Paul; bbr@lampreynetworks.com; rddp@ietf.org >Subject: RE: [rddp] DDP segment sequences for Untagged DDP message > > >My responses are marked pat > >-----Original Message----- >From: Culley, Paul [mailto:paul.culley@hp.com] >Sent: Friday, January 16, 2004 12:28 PM >To: Barry Reinhold; RDDP >Subject: RE: [rddp] DDP segment sequences for Untagged DDP message > > >Below... > >Paul R. Culley >HP Fellow >281-514-5543 > > >-----Original Message----- >From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of >Barry Reinhold >Sent: Friday, January 16, 2004 1:09 PM >To: RDDP >Subject: [rddp] DDP segment sequences for Untagged DDP message > > > >So, is there agreement, for the sequences that follow, that the >specified "result" given below is the correct (and desired?) behavior as >defined by the 01 draft. > >Untagged DDP Segment Sequences: > >1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes >2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes >Result: DDP Message (bytes 0-200) is delivered to ULP >[prc] yes >[pat]DDP message (bytes 0-200) occurs after 1. > 2 will cause an invalid MSN error > >1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes >2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes >Result: ULP sent Error type=Untagged Buffer Error, Error Code=Invalid MO >[prc] No, the receiver will place both segments, but inform the ULP that >only 100 bytes was delivered, ending at MO=99. No error should be >detected or reported, unless the receiver's buffer was not large enough >to hold the second 100 bytes. [pat] Checking for the error of last >segment not containing highest MO is optional. Both behaviors above >would be valid responses. > >1. QN = 0, MSN = 1, MO = 0, L = 0, Payload = 100 bytes >2. QN = 0, MSN = 1, MO = 0, L = 1, Payload = 100 bytes >Result: DDP Message (bytes 0-100) is delivered to ULP >[prc] yes, but it is not certain which segment ends up in the buffer, it >won't matter unless the two payloads are different. [pat] agree. > >1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes >2. QN = 0, MSN = 1, MO = 200, L = 1, Payload = 100 bytes >Result: DDP Message (bytes 0-300) is delivered to ULP >[prc] yes, but the middle 100 will contain unknown values (probably what >they had before the buffer went through DDP). [pat] There are two valid >behaviors. The receiver may deliver the message as above or it may be >checking and report an error. > >1. QN = 0, MSN = 1, MO = 300, L = 1, Payload = 100 bytes >Result: DDP Message (bytes 0-400) is delivered to ULP >(This is based on wording in 6.3, MO field. Note that the second >sentence simply says that the MO "that references the first octet MUST >be set to zero", not that a segment having a zero MO is required) [prc] >yes, but first 300 is unknown [pat] Again the receiver is allowed to >deliver or to report an error. > >1. QN = 0, MSN = 1, MO = 100, L = 0, Payload = 100 bytes >2. QN = 0, MSN = 1, MO = 000, L = 1, Payload = 0 bytes >Result: ULP sent Error type=Untagged Buffer Error, Error Code = Invalid >MO (There is ambiguity between 6.1 L bit field description ( Segment w/ >L bit set must have highest MO), and 9.1 (implies that for non-zero >length segments the header fields are not validated.) [prc] no, at least >not because of a protocol error. There is only an error if the buffer >limits as defined by the ULP is exceeded. You should get an indication >that a zero length message was delivered. [pat] The ambiguity you point >out is probably an error. The MUST on checking Untagged DDP segments >required that they be validated before placement. A zero length segment >isn't placed so the MUST didn't apply to it. There probably should be a >statement about checking the fields before delivery of zero length >untagged messages or zero length segments with the L bit set. Also even >if that statement is added, this is another case where the receiver is >allowed to deliver or report an error. > >1. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100 bytes >2. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes >Result: DDP Message (bytes 0 - 100) is delivered to ULP >[prc] yes >[pat] yes. Note that this is another case where there should be a >requirement that the zero length segment header values be checked before >delivery. > >1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 0 bytes >Result: DDP Message (bytes 0 - 100) id delivered to ULP. >[prc], yes, but with unknown data values. >[pat] May deliver the message or may scoreboard and report an error. > >Barry Reinhold >Lamprey Networks >bbr@lampreynetworks.com >(603) 868-8411 > > > > >_______________________________________________ >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 exim@www1.ietf.org Tue Jan 27 12:42:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15991 for ; Tue, 27 Jan 2004 12:42:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXDo-0005Bb-NP for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 12:41:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RHfuWb019929 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 12:41:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXDo-0005BM-Jf for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 12:41:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15981 for ; Tue, 27 Jan 2004 12:41:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlXDm-0002j2-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 12:41:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlXCt-0002fk-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 12:41:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AlXC2-0002cH-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 12:40:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AlXC3-0002kP-NZ for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 12:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXC0-0004yl-Ky; Tue, 27 Jan 2004 12:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXBo-0004xD-Ix for rddp@optimus.ietf.org; Tue, 27 Jan 2004 12:39:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15917 for ; Tue, 27 Jan 2004 12:39:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlXBn-0002ae-00 for rddp@ietf.org; Tue, 27 Jan 2004 12:39:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlXAr-0002XG-00 for rddp@ietf.org; Tue, 27 Jan 2004 12:38:54 -0500 Received: from mail3.ttlc.net ([66.94.32.26] helo=mail.communicom.net) by ietf-mx with esmtp (Exim 4.12) id 1AlXA5-0002TY-00 for rddp@ietf.org; Tue, 27 Jan 2004 12:38:05 -0500 Received: from lampreynetworks.com [66.94.32.4] by mail.communicom.net with ESMTP (SMTPD32-7.07) id A2A014BE00AE; Tue, 27 Jan 2004 12:40:48 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A29E507029C; Tue, 27 Jan 2004 12:40:46 -0500 From: "Barry Reinhold" To: "'Caitlin Bestler'" , "'Paul Culley'" , "'RDDP'" Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Tue, 27 Jan 2004 12:34:30 -0500 Message-ID: <000601c3e4fb$d2555dc0$467fa8c0@i8600> 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, Build 10.0.2627 In-Reply-To: <63E720DE-50D9-11D8-A942-003065D48EE0@asomi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, Caitlin, Paul, I think several different issues have come up, as I formulated my initial post somewhat poorly. I would like to clarify it a bit to see if we have agreement. Definition of terms: QN - Queue Number in the header of the untagged DDP message MSN - Message Sequence number in the header of the untagged DDP message L - L bit in the header of the untagged DDP message Payload - The number of bytes in the payload of the DDP segment LLPSeqNumTag - Assume this to be the LLP Sequence number associated with the last octet of the DDP Segment received. LLPSegNumCompleted - Assume this to be an LLP maintained value that indicates that all octets in the LLP stream up to the value indicated have been placed. I recognize that LLPSegNumTag and LLPSegNumCompleted do not exist in the draft, but I don't see how to clearly specify the problem with terms currently defined in the draft. Also note that, for simplicity reasons, the LLP sequence numbers just follow DDP payload data, they are not real LLP sequence numbers. (The only condition that needs to be testable is if the LLPSeqNumCompleted matches the LLPSegNumTag of the segment with the L bit set to 1.) Case 1 DDP segments as seen in time order at the receiver: 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted = 500, LLPSeqNumTag = 600 2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSeqNumCompleted = 600, LLPSegNumTag = 500 Is the ONLY correct behavior to deliver 200 bytes of data to the ULP upon reception of the second (item 2.) DDP segment? Case 2 DDP segments as seen in time order at the receiver: 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted = 600, LLPSegNumTag = 600 2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSegNumCompleted = 500, LLPSegNumTag = 500 (In this case the transmitter has violated 6.1 which states: The DDP Segment with the L bit set to 1 MUST be posted to the LLP after all other DDP Segments of the associated DDP Message have been posted to the LLP. ) Agree/disagree (by part) There are two "allowed" behaviors after reception of item 1. 1. sending the ULP 200 bytes of data 2. sending the ULP an error message (not currently defined) The ONLY correct behavior on reception of item 2 is to send the ULP the error (0x03 - invalid MSN - MSN range is not valid) -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Caitlin Bestler Sent: Tuesday, January 27, 2004 9:59 AM To: Paul Culley; RDDP Subject: Re: [rddp] DDP segment sequences for Untagged DDP message On Jan 27, 2004, at 8:01 AM, Culley, Paul wrote: > OK, I realize that I missed a small point; in the first case below > > 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes > 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes > Result: DDP Message (bytes 0-200) is delivered to ULP > [prc] yes > [pat]DDP message (bytes 0-200) occurs after 1. > 2 will cause an invalid MSN error > > I was thinking of TCP segments as they arrive at the receiver, not as > sent at the transmitter. If the example was sent in this order, I > agree > that an invalid MSN error is the correct answer, The MSN is invalid, but the receiver is not obligated to catch it. If DDP-Segment 2 is placed *before* DDP-Segment 1 is completed, then no error will be detected. Both the MO and MSN are in range. The 100 bytes will be placed. This obviously can occur if DDP-Segment 2 arrives before DDP-Segment 1. But it can also occur if they arrive in order and the receiver pipelines processing of DDP-Segments. Remember that all implications of out-of-order processing hold no matter what the reason for the out-of-order processing is. The packets do not have to have been in the "wrong order" on the wire for out-of-order processing to occur. Similarly, the fact that MSN 17 invalidated STag 504 does not guarantee that use of STag 504 in a tagged message that is latter in the LLP stream will be flagged as an error. Invalidation is only guaranteed by the time it is reported to the Data Sink ULP. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ 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 exim@www1.ietf.org Tue Jan 27 17:45:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27918 for ; Tue, 27 Jan 2004 17:45:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbxC-00014j-6h for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 17:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RMj69b004129 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 17:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbxC-00014W-1j for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 17:45:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27897 for ; Tue, 27 Jan 2004 17:45:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Albx9-0007OM-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 17:45:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Albw8-0007Jk-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 17:44:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlbvA-0007Ev-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 17:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbvB-0000yQ-EF; Tue, 27 Jan 2004 17:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbuU-0000xy-5F for rddp@optimus.ietf.org; Tue, 27 Jan 2004 17:42:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27795 for ; Tue, 27 Jan 2004 17:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlbuR-0007Av-00 for rddp@ietf.org; Tue, 27 Jan 2004 17:42:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlbtX-00075z-00 for rddp@ietf.org; Tue, 27 Jan 2004 17:41:20 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1Albsn-0006wd-00 for rddp@ietf.org; Tue, 27 Jan 2004 17:40:33 -0500 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 DE4D52450BA; Tue, 27 Jan 2004 14:29:58 -0500 (EST) In-Reply-To: <000601c3e4fb$d2555dc0$467fa8c0@i8600> References: <000601c3e4fb$d2555dc0$467fa8c0@i8600> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <092A2886-50FF-11D8-805E-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit Cc: "'Paul Culley'" From: Caitlin Bestler Subject: Re: [rddp] DDP segment sequences for Untagged DDP message Date: Tue, 27 Jan 2004 13:28:50 -0600 To: "'RDDP'" , Barry Reinhold X-Mailer: Apple Mail (2.612) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Jan 27, 2004, at 11:34 AM, Barry Reinhold wrote: > - L bit in the header of the untagged DDP message > > Payload - The number of bytes in the payload of the DDP segment > > LLPSeqNumTag - Assume this to be the LLP Sequence number associated > with > the last octet of the DDP Segment received. That is true, but understand that the only requirement is that the LLP has *some* sequencing mechanism. DDP does not know what that sequencing mechanism is, it only knows the original per-stream order of DDP Segments. Hence, for MPA/TCP the sequence number is a TCP stream position (the offset of the last byte) but for SCTP it is a packet sequence number (which for technical reasons is *not* the Stream Sequence Number, but a number that behaves exactly as a Stream Sequence Number *would* have had one been associated with an unordered chunk). If you were to map DDP onto a different reliable transport you might come up with a totally different method of sequencing packets, but in actuality you probably never would and even if you did it would match either byte numbering or packet numbering. > LLPSegNumCompleted - Assume this to be an LLP maintained value that > indicates that all octets in the LLP stream up to the value indicated > have been placed. That information could be derived for SCTP, but in fact the function described is handled by the TSN and TSN Ackpoint. That is because SCTP manages acks for all streams in an association, and does not ack them separately. It would be more accurate to state that there is a point in a stream where a packet and all prior packets have been completed. Even if represented as a byte offset, as far as DDP is concerned a DDP Segment was either completed or it was not. There is no such thing as "half a segment" as far as it is concerned. > > I recognize that LLPSegNumTag and LLPSegNumCompleted do not exist in > the > draft, but I don't see how to clearly specify the problem with terms > currently defined in the draft. As pointed out above, stating these behaviors with proper abstraction would probably cause more confusion than enlightenment. The draft authors did a fine job of focusing on the services that the LLP provides to DDP, and then trying to know as little about the LLP as possible. > Case 1 > > DDP segments as seen in time order at the receiver: > 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted > = > 500, LLPSeqNumTag = 600 > 2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSeqNumCompleted > = > 600, LLPSegNumTag = 500 > > Is the ONLY correct behavior to deliver 200 bytes of data to the ULP > upon reception of the second (item 2.) DDP segment? > Correct. Although it might be more accurate to state that the delivery is of a notice that a 200 byte untagged message has been received. The bytes are not included in the notice. > Case 2 > DDP segments as seen in time order at the receiver: > 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted > = > 600, LLPSegNumTag = 600 > 2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSegNumCompleted > = > 500, LLPSegNumTag = 500 > > (In this case the transmitter has violated 6.1 which states: > The DDP Segment with the L bit set to 1 MUST be posted to the > LLP after all other DDP Segments of the associated DDP Message > have been posted to the LLP. ) > > Agree/disagree (by part) > > There are two "allowed" behaviors after reception of item 1. > 1. sending the ULP 200 bytes of data > 2. sending the ULP an error message (not currently defined) > The receive completion for a 200 byte message *will* be received. Depending on when Segment-2 is processed versus when the processing of Segment-1 is done, you may/should get an invalid MSN error which will terminate the connection. > The ONLY correct behavior on reception of item 2 is to send the ULP the > error (0x03 - invalid MSN - MSN range is not valid) If item 2 is received *before* item 1 has been completely processed there will be no basis on which to reject the packet. The receiver is not obligated to delay processing of item 2 because item 1 MIGHT invalidate it. A properly designed ULP will ensure that the meaning of each DDP Segment is valid for placement no matter what subset of in-flight messages have been placed before it -- that includes those sent afterwards. While neither end will error check for dangerous buffer practices, having the same byte targeted by multiple in-flight messages is inherently non-determinstic. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Jan 27 18:40:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00239 for ; Tue, 27 Jan 2004 18:40:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlcoO-00049p-UE for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 18:40:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RNe4FL015975 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 18:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlcoN-00049E-H1 for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 18:40:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00219 for ; Tue, 27 Jan 2004 18:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlcoK-0002Uf-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 18:40:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlcnM-0002RG-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 18:39:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlcmO-0002OC-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 18:38:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlcmP-00043C-D8; Tue, 27 Jan 2004 18:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlclX-0003ns-Vn for rddp@optimus.ietf.org; Tue, 27 Jan 2004 18:37:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00151 for ; Tue, 27 Jan 2004 18:37:03 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlclU-0002L7-00 for rddp@ietf.org; Tue, 27 Jan 2004 18:37:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlckY-0002Hx-00 for rddp@ietf.org; Tue, 27 Jan 2004 18:36:08 -0500 Received: from msgbas2x.cos.agilent.com ([192.25.240.37]) by ietf-mx with esmtp (Exim 4.12) id 1Alck8-0002Ek-00 for rddp@ietf.org; Tue, 27 Jan 2004 18:35:40 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 3484B54DE; Tue, 27 Jan 2004 16:35:35 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 13AA14D6; Tue, 27 Jan 2004 16:35:35 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Jan 2004 16:35:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Date: Tue, 27 Jan 2004 16:35:34 -0700 Message-ID: Thread-Topic: [rddp] Some questions related to "last segment" of a ddp message Thread-Index: AcPisR+5twI/E7waTgqlXcwPpikHkwCbIrtQ To: , , Cc: X-OriginalArrivalTime: 27 Jan 2004 23:35:34.0799 (UTC) FILETIME=[42C551F0:01C3E52E] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry, I don't think I wrote anything that conflicts with your statements at 1 = and 2 below. I agree that the sender is allowed to send out of order and = that the receiver therefore has to tolerate out of order arrival. The = only thing the receiver can count on is that the highest MO will come in = the last message.=20 I'm not clear what you think was excessively liberal in my message. The transmitter is required to send the whole message. Where I believe = the receiver has some freedom is it can: Trust the transmitter to send the whole message and report message = completion based on MO sent in the last segment, or Scoreboard the message and report an error if there are gaps or if the = transmitter sent higher MOs in the segments before the last.=20 There aren't any words that prohibit transmitting overlaps so they = should probably be treated as not an error. Regards, Pat -----Original Message----- From: Barry Reinhold [mailto:bbr@lampreynetworks.com] Sent: Saturday, January 24, 2004 11:35 AM To: THALER,PAT (A-Roseville,ex1); paul.culley@hp.com; mcc@fid4.com Cc: rddp@ietf.org Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Pat, Although I don't consider myself a conservative, the interpretation of the specification here is starting to get too liberal for my taste. (Sorry, it's primary time here in New Hampshire...) I do think there is an issue here in terms of what we are expecting when the sender "SHOULD" send a message in a particular format. If the sender SHOULD send the message using format A, this implies that the receiver MUST accept format A and B (assuming a choice between A and B). Thus the receiver MUST NOT return an error if the message arrives using format "B". This is important for interoperability. If a specification allows a behavior (SHOULD implies allowing a behavior that is not the "desired" behavior) then the receiver has got to support it, otherwise some pairs of devices just won't work. I do not have a strong opinion as to what is the proper choice in terms of behavior with overlaps/gaps. However, I do think it is important that the specification be written in a way that the behavior is clear. As currently written I believe that the draft: 1. Requires that all data of a DDP message must be sent (Clause 7.2 - "At the Data Source, the DDP layer MUST send all=20 the data contained in the ULP message.") 2. States that the sender is not required to send DDP segments in order (Clause 7.3 - "At the Data Source, DDP:=20 * MUST transmit DDP Messages in the order they were submitted to=20 the DDP layer, [Note that this is messages, not segments] * SHOULD transmit DDP Segments within a DDP Message in increasing=20 MO order for Untagged DDP Messages and in increasing TO order=20 for Tagged DDP Messages.") The above statements, I believe, imply that the receiving DDP layer MUST NOT send an error for duplicated data or out of order data. One could argue that a gap is impossible based on point 1, but it would be a weak, or indirect, argument. I would propose that we identify what is desired (do we allow duplicates/gaps?) and write the document so that the behavior of the receiver is clear.=20 -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]=20 Sent: Friday, January 23, 2004 3:29 PM To: paul.culley@hp.com; mcc@fid4.com; rddp@ietf.org Cc: bbr@lampreynetworks.com Subject: RE: [rddp] Some questions related to "last segment" of a ddp message Paul, RE: 2) Where are payload bytes 50-99? 300-399? [prc] The receiver is not expected to check for overlaps, or holes in the data. So this is not a valid reason to report errors and there are no defined errors for this. Perhaps the draft should explicitly say not to report errors for these cases. As long as all the transmitter's data was placed and delivered, the receiver is compliant. In the case of overlaps, the receiver is not even required to make sure that the highest TCP sequence numbered segment was the last placed, so overlaps could lead to unpredictable delivered data. As a consequence of this, the transmitter SHOULD send data with no overlaps or holes, although an application could conceivably be designed to work even if this is not followed (some kind of test suite?). [prc] The receiver is not required to check for overlaps and holes but there isn't anyplace that disallows it doing so. I believe that this was our intent when we wrote it and it is consistant with the text in the draft - 7.2 says at the end that the Data Sink is not required to verify that the entire message has been received. It doesn't prohibit checking.=20 So it would be valid behavior to detect an error because of the missing bytes. It would also be valid behavior to not detect that error. Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Culley, Paul Sent: Friday, January 16, 2004 7:33 AM To: Michael C. Cambria; RDDP Cc: Barry Reinhold Subject: RE: [rddp] Some questions related to "last segment" of a ddp message A couple of points are included below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Michael C. Cambria Sent: Friday, January 16, 2004 8:39 AM To: RDDP Cc: Barry Reinhold Subject: Re: [rddp] Some questions related to "last segment" of a ddp message Barry Reinhold wrote: > Hemal, >=20 > I would like to check on a couple of issues: >=20 > I believe that it is possible to RECEIVE a sequence of DDP segments=20 > using the untagged buffer model as follows: Let me know if this is not > correct. >=20 > Segment 1: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (MO not 0 on = first)=20 > Segment 2: QN=3D1, MSN=3D1, MO=3D200, L=3D0 (payload 100) (duplicate) = Segment=20 > 3: QN=3D1, MSN=3D1, MO=3D100, L=3D0 (payload 100) (backward) Segment = 4: QN=3D1,=20 > MSN=3D1, MO=3D000, L=3D0 (payload 050) (meets 6.3, MO field) Segment = 5:=20 > QN=3D1, MSN=3D1, MO=3D400, L=3D1 (payload 000) (meets 6.1 L bit > field) >=20 > In particular, > 1. If no packets have been received w/ a given MSN and QN and a packet > arrives with a non-zero MO this is not an error. > 2. The MO fields in intermediate segments are not constrained to be in > order, can have gaps, and can write over buffer space already written > to. My understanding is yes, yes and (re write over buffer space) not convinced. On pg 20 of draft-ietf-rddp-ddp-01.txt, "For an Untagged DDP Message,=20 the combination of the QN and MSN uniquely identifies a DDP Message."=20 Since an MSN doesn't make sense for a DDP _message_, I've read this to=20 mean that QN & MSN uniquely identifies a DDP _segment_. [prc] I suspect some misunderstanding here. An MSN (Message Sequence Number) specifically identifies which _message_ on the particular Queue the segment belongs to. Think of a queue with 5 2000 byte buffers, If TCP can manage=20 1500 bytes or so per segment, each buffer can hold two segments. The two segments for the second buffer might be identified by QN=3D1, = MSN=3D2, MO=3D0, L=3D1500 and QN=3D1, MSN=3D2, MO=3D1500, L=3D500. The two = segments have the same MSN, so your statement is not correct. [prc] So the way I read the draft, I can't find text that says one cannot send overlapping DDP segments. > Or from a test perspective, if a receiver returned an error when=20 > receiving the above sequence the receiver would be considered=20 > non-conformant. I'd return an error for several reasons. 1) I know of no legal untagged message on QN=3D1 that has a payload as=20 large as you describe. [prc] for DDP, all QN values are legal, and only the ULP can place limits on their size, what you say is true only if you are using RDMA as the next up ULP. [prc] 2) Where are payload bytes 50-99? 300-399? [prc] The receiver is not expected to check for overlaps, or holes in the data. So this is not a valid reason to report errors and there are no defined errors for this. Perhaps the draft should explicitly say not to report errors for these cases. As long as all the transmitter's data was placed and delivered, the receiver is compliant. In the case of overlaps, the receiver is not even required to make sure that the highest TCP sequence numbered segment was the last placed, so overlaps could lead to unpredictable delivered data. As a consequence of this, the transmitter SHOULD send data with no overlaps or holes, although an application could conceivably be designed to work even if this is not followed (some kind of test suite?). [prc] If I understand the example correctly, segment 4 provides DDP/RDMA=20 message bytes 0-49; segment 3 provides 100-199, segments 1 & 2 provide=20 200-300 [prc] one last comment; segment 5 (with zero length) is legal, and must be delivered. Further, even if no other data for the message arrived, the zero length message does consume an untagged buffer. [prc] MikeC _______________________________________________ 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 exim@www1.ietf.org Tue Jan 27 19:18:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03691 for ; Tue, 27 Jan 2004 19:18:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldPU-0004j5-3H for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 19:18:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0IOsl018166 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 19:18:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldPT-0004it-W9 for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:18:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03570 for ; Tue, 27 Jan 2004 19:18:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldPS-0007A4-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:18:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldNG-0006du-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:16:09 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AldKk-0005tK-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:13:30 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ald4u-00045J-PF for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 18:57:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald4u-0005BP-KQ; Tue, 27 Jan 2004 18:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al7w5-0006Wk-Sn for rddp@optimus.ietf.org; Mon, 26 Jan 2004 09:41:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07201 for ; Mon, 26 Jan 2004 09:41:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al7w3-0000wu-00 for rddp@ietf.org; Mon, 26 Jan 2004 09:41:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al7vA-0000vT-00 for rddp@ietf.org; Mon, 26 Jan 2004 09:41:01 -0500 Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx with esmtp (Exim 4.12) id 1Al7uk-0000s5-00 for rddp@ietf.org; Mon, 26 Jan 2004 09:40:34 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.33]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 4E4DCCCD2; Mon, 26 Jan 2004 08:40:03 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 08:40:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Mon, 26 Jan 2004 08:39:59 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762CC6978A@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPcb48HD/qiTTOeT3mP7IcqsaDR5wFj6fbgAIXw9SA= From: "Culley, Paul" To: , , X-OriginalArrivalTime: 26 Jan 2004 14:40:01.0931 (UTC) FILETIME=[47AD05B0:01C3E41A] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable OK, I realize that I missed a small point; in the first case below=20 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes [pat]DDP message (bytes 0-200) occurs after 1. 2 will cause an invalid MSN error I was thinking of TCP segments as they arrive at the receiver, not as sent at the transmitter. If the example was sent in this order, I agree that an invalid MSN error is the correct answer, if they were merely received in this order (they got flipped in route and were received out of order, but sent in order), then the result would be a normal delivery. I am not certain I agree with Pat on the "optional" nature of checking for errors that are not even mentioned in the specification. I think that if we have to list all of the checks that we DO NOT perform in the specifications, then we have quite a bit of writing left to do. That said, we should perhaps be a bit more clear about the rules on Sending overlapped segments, or Sending Gaps. I am definitely not in favor of requiring the receiver to check for either case. If we were to add text to DDP for this I think it would say something like: When sending an Untagged Message, the Sender MUST send data to each offset within the target buffer only one time. When sending an Untagged Message, the Sender MUST send a contiguous stream of bytes to the destination buffer, starting at offset 0. In my mind, we should allow the receiver to check for these conditions only if these rules are made on the sender. Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]=20 Sent: Friday, January 23, 2004 4:45 PM To: Culley, Paul; bbr@lampreynetworks.com; rddp@ietf.org Subject: RE: [rddp] DDP segment sequences for Untagged DDP message My responses are marked pat -----Original Message----- From: Culley, Paul [mailto:paul.culley@hp.com] Sent: Friday, January 16, 2004 12:28 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Below... Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, January 16, 2004 1:09 PM To: RDDP Subject: [rddp] DDP segment sequences for Untagged DDP message So, is there agreement, for the sequences that follow, that the specified "result" given below is the correct (and desired?) behavior as defined by the 01 draft. Untagged DDP Segment Sequences: 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP [prc] yes [pat]DDP message (bytes 0-200) occurs after 1. 2 will cause an invalid MSN error 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error = Code=3DInvalid MO [prc] No, the receiver will place both segments, but inform the ULP that only 100 bytes was delivered, ending at MO=3D99. No error should be detected or reported, unless the receiver's buffer was not large enough to hold the second 100 bytes. [pat] Checking for the error of last segment not containing highest MO is optional. Both behaviors above would be valid responses. 1. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 0, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-100) is delivered to ULP [prc] yes, but it is not certain which segment ends up in the buffer, it won't matter unless the two payloads are different. [pat] agree.=20 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 200, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-300) is delivered to ULP [prc] yes, but the middle 100 will contain unknown values (probably what they had before the buffer went through DDP). [pat] There are two valid behaviors. The receiver may deliver the message as above or it may be checking and report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 300, L =3D 1, Payload =3D 100 bytes Result: DDP Message (bytes 0-400) is delivered to ULP (This is based on wording in 6.3, MO field. Note that the second sentence simply says that the MO "that references the first octet MUST be set to zero", not that a segment having a zero MO is required) [prc] yes, but first 300 is unknown [pat] Again the receiver is allowed to deliver or to report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 1, Payload =3D 0 bytes Result: ULP sent Error type=3DUntagged Buffer Error, Error Code =3D = Invalid MO (There is ambiguity between 6.1 L bit field description ( Segment w/ L bit set must have highest MO), and 9.1 (implies that for non-zero length segments the header fields are not validated.) [prc] no, at least not because of a protocol error. There is only an error if the buffer limits as defined by the ULP is exceeded. You should get an indication that a zero length message was delivered. [pat] The ambiguity you point out is probably an error. The MUST on checking Untagged DDP segments required that they be validated before placement. A zero length segment isn't placed so the MUST didn't apply to it. There probably should be a statement about checking the fields before delivery of zero length untagged messages or zero length segments with the L bit set. Also even if that statement is added, this is another case where the receiver is allowed to deliver or report an error. 1. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100 bytes 2. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) is delivered to ULP [prc] yes [pat] yes. Note that this is another case where there should be a requirement that the zero length segment header values be checked before delivery. 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 0 bytes Result: DDP Message (bytes 0 - 100) id delivered to ULP.=20 [prc], yes, but with unknown data values. [pat] May deliver the message or may scoreboard and report an error. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 _______________________________________________ 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 exim@www1.ietf.org Tue Jan 27 19:34:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04960 for ; Tue, 27 Jan 2004 19:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alded-0006Y4-M7 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 19:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0Y3el025166 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 19:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alded-0006Xp-Ik for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:34:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04915 for ; Tue, 27 Jan 2004 19:33:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aldeb-0001Wl-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:34:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aldcz-00019h-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:32:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AldcO-00011O-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:31:45 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRr-00065H-8G for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldD9-0008My-HZ; Tue, 27 Jan 2004 19:05:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlBei-0000Xu-4w for rddp@optimus.ietf.org; Mon, 26 Jan 2004 13:40:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15463 for ; Mon, 26 Jan 2004 13:40:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlBeg-0005GL-00 for rddp@ietf.org; Mon, 26 Jan 2004 13:40:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlBdn-0005Bq-00 for rddp@ietf.org; Mon, 26 Jan 2004 13:39:22 -0500 Received: from mail3.ttlc.net ([66.94.32.26] helo=mail.communicom.net) by ietf-mx with esmtp (Exim 4.12) id 1AlBbE-000524-00 for rddp@ietf.org; Mon, 26 Jan 2004 13:36:41 -0500 Received: from lampreynetworks.com [66.94.32.4] by mail.communicom.net with ESMTP (SMTPD32-7.07) id AF9136EB00DE; Mon, 26 Jan 2004 13:42:25 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id AF9048B8011A; Mon, 26 Jan 2004 13:42:24 -0500 From: "Barry Reinhold" To: , , Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Mon, 26 Jan 2004 13:36:09 -0500 Message-ID: <000501c3e43b$44b8f000$467fa8c0@i8600> 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, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, Given clause 7.4, which states... At the Data Sink, DDP MUST Deliver a DDP Message if and only if all of the following are true: * the last DDP Segment of the DDP Message had its Last flag set, * all of the DDP Segments of the DDP Message have been Placed, * all preceding DDP Messages have been Placed, and * each preceding DDP Message has been Delivered to the ULP. I assumed that DDP could not deliver the "DDP message" until the second segment of the message arrived (this would have violated item 2 above). I am also assuming that item 2 exists to ensure that an LLP error, which has caused a DDP segment to arrive out of order, does not cause a DDP message to be delivered prematurely. (This is distinct from the DDP transmitter sending requirements for the L bit.) What I "think I hear you saying..." is that item 2 does not have to be checked before delivery of the message. If this is what you are saying, how is premature delivery avoided? Would the following be acceptable wording? At the Data Sink, DDP MUST NOT Deliver a DDP Message until all of the following conditions are true: * a DDP segment with the L bit set has been placed for this DDP message * all octets, based on LLP sequence information, have been placed for this DDP message. * all preceding DDP Message have been Delivered to the ULP. The wording above removes the word "last" from the first item of the original requirement, which I believe is ambiguous, but allows implementations to track LLP sequence information to avoid score boarding, and addresses the premature delivery issue. If the above wording is used then the behavior of the DDP layer, in the case below, would be to wait for the second DDP segment to arrive before the DDP message is delivered to the ULP. The ULP would see a message of 200 bytes with no gaps. If, for some reason that I have overlooked, it is not possible to get an out of order DDP segment due to LLP error recovery, then I agree with Pat and the second item of the original requirement for delivery of a DDP message is not necessary. -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, January 23, 2004 4:22 PM To: cait@asomi.com; rddp@ietf.org Cc: bbr@lampreynetworks.com Subject: RE: [rddp] DDP segment sequences for Untagged DDP message This should be shown as: 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes Result: DDP Message (bytes 0-200) is delivered to ULP 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes Result: Error is reported Invalid MSN - MSN range is not valid This is a fatal error so there will be a teardown. Pat -----Original Message----- From: Caitlin Bestler [mailto:cait@asomi.com] Sent: Friday, January 16, 2004 4:42 PM To: RDDP Cc: Barry Reinhold Subject: Re: [rddp] DDP segment sequences for Untagged DDP message On Jan 16, 2004, at 1:08 PM, Barry Reinhold wrote: > > So, is there agreement, for the sequences that follow, that the > specified "result" given below is the correct (and desired?) behavior > as > defined by the 01 draft. > > Untagged DDP Segment Sequences: > > 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes > 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes > Result: DDP Message (bytes 0-200) is delivered to ULP > Did you mean to set the 'L' bit on message 1? If so, that is a sender violation, which as explained in Paul's response may or may not be caught by the receiver. If Msg 1 is completed *before* Msg 2 is placed, Msg 2 will be rejected as having an invalid MSN (it would be taken as being 2**32-1 ahead of the current location). In either case a 200 byte receive will be reported to the ULP. The question is whether the Stream is almost immediately thereafter torn down. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ 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 exim@www1.ietf.org Tue Jan 27 19:53:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06865 for ; Tue, 27 Jan 2004 19:53:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldxL-0008Ne-AN for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 19:53:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0rNBr032213 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 19:53:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldxL-0008NU-64 for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:53:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06862 for ; Tue, 27 Jan 2004 19:53:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldxJ-0003zt-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:53:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldwX-0003vB-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:52:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aldvz-0003pb-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 19:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldw0-0008Hp-S5; Tue, 27 Jan 2004 19:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldv6-0008Bx-P1 for rddp@optimus.ietf.org; Tue, 27 Jan 2004 19:51:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06709 for ; Tue, 27 Jan 2004 19:51:02 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aldv4-0003md-00 for rddp@ietf.org; Tue, 27 Jan 2004 19:51:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aldu7-0003in-00 for rddp@ietf.org; Tue, 27 Jan 2004 19:50:04 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1AldtB-0003fJ-00 for rddp@ietf.org; Tue, 27 Jan 2004 19:49:05 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 883CF6817; Tue, 27 Jan 2004 17:49:05 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 69F1A1BC; Tue, 27 Jan 2004 17:49:05 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Jan 2004 17:49:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Tue, 27 Jan 2004 17:49:04 -0700 Message-ID: Thread-Topic: [rddp] DDP segment sequences for Untagged DDP message Thread-Index: AcPk/J3u1X/ZAlRcQ0CuDWddJ7EMiAAM/6XQ To: , , , X-OriginalArrivalTime: 28 Jan 2004 00:49:05.0221 (UTC) FILETIME=[87964F50:01C3E538] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry, In case 1, the transmitter sent the segments to the LLP in the correct = order and they got misordered on the way to the receiver. As you stated, = no errors occurred and the correct behavior is to deliver the message = with a length of 200 octets. By the way, I think you meant that LLPSeqNumCompleted indicates that all = octets in the LLP stream up to that point have been transfered to DDP. = The LLP doesn't do placement - DDP does placement. Therefore, the LLP = can't maintain a value indicating which octets in the stream have been = placed. I also am assuming that when you mention your new terms, = Seq=3DSeg. I don't understand your case 2. If I understand LLPSeqNumCompleted, it = indicates how much of the LLP data stream has been completely received = (that is, the point to which there are no gaps due to out of order = arrival). Therefore, it should increase with time - it can never = decrease. In case 2 below it decreases so either I don't understand = LLPSeqNumCompleted or there is a typo in the example. Also note that = item 11 in section 5 Reliable Deliver LLP Requirements is that the LLP = MUST NOT pass a duplicate DDP segment to DDP after it has passed all = previous segments to DDP. This requirement means that LLPSeqNumTag MUST = always be greater then the previous value of LLPSeqNumCompleted. You said that this was the case where the transmitter violated sending = the last segment last. In that case, the segment in 2 would have a = higher sequence number than the segment in 1 so perhaps you meant: Case 2b DDP segments as seen in time order at the receiver: 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 100, = LLPSegNumCompleted =3D 600, LLPSegNumTag =3D 600 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100, = LLPSegNumCompleted =3D 700, LLPSegNumTag =3D 700 In that case I agree that: There are two "allowed" behaviors after reception of item 1.=20 1. sending the ULP 200 bytes of data 2. sending the ULP an error message (not currently defined) I almost agree with your next statement: The ONLY correct behavior on reception of item 2 is to send the ULP the error (0x03 - invalid MSN - MSN range is not valid) There is the issue that Caitlin pointed out. It is possible that there = is a window in a DDP implementation where it has received segment 1 and = is still munching on it (hasn't advanced the MSN range yet) while = segment 2 comes in and gets placed. In that case, segment 2 could come = in and get placed without an error being detected. This would be similar = to the behavior that could occur if segment 2 arrived out of order = before segment 1.=20 The ambiguous window should be over before the Untagged Message is = delivered to the ULP because DDP should ensure that it doesn't touch the = buffer once it has delivered it. So, if MSN 1 was delivered before 2 = arrived, then 2 should cause the invalid MSN error. Regards, Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Barry Reinhold Sent: Tuesday, January 27, 2004 9:35 AM To: 'Caitlin Bestler'; 'Paul Culley'; 'RDDP' Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Pat, Caitlin, Paul, I think several different issues have come up, as I formulated my initial post somewhat poorly. I would like to clarify it a bit to see if we have agreement. Definition of terms: QN - Queue Number in the header of the untagged DDP message MSN - Message Sequence number in the header of the untagged DDP message L - L bit in the header of the untagged DDP message Payload - The number of bytes in the payload of the DDP segment LLPSeqNumTag - Assume this to be the LLP Sequence number associated with the last octet of the DDP Segment received. LLPSegNumCompleted - Assume this to be an LLP maintained value that indicates that all octets in the LLP stream up to the value indicated have been placed.=20 I recognize that LLPSegNumTag and LLPSegNumCompleted do not exist in the draft, but I don't see how to clearly specify the problem with terms currently defined in the draft.=20 Also note that, for simplicity reasons, the LLP sequence numbers just follow DDP payload data, they are not real LLP sequence numbers. (The only condition that needs to be testable is if the LLPSeqNumCompleted matches the LLPSegNumTag of the segment with the L bit set to 1.) Case 1 DDP segments as seen in time order at the receiver:=20 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 100, = LLPSegNumCompleted =3D 500, LLPSeqNumTag =3D 600 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100, = LLPSeqNumCompleted =3D 600, LLPSegNumTag =3D 500 Is the ONLY correct behavior to deliver 200 bytes of data to the ULP upon reception of the second (item 2.) DDP segment? Case 2 DDP segments as seen in time order at the receiver: 1. QN =3D 0, MSN =3D 1, MO =3D 100, L =3D 1, Payload =3D 100, = LLPSegNumCompleted =3D 600, LLPSegNumTag =3D 600 2. QN =3D 0, MSN =3D 1, MO =3D 000, L =3D 0, Payload =3D 100, = LLPSegNumCompleted =3D 500, LLPSegNumTag =3D 500 (In this case the transmitter has violated 6.1 which states: The DDP Segment with the L bit set to 1 MUST be posted to the=20 LLP after all other DDP Segments of the associated DDP Message=20 have been posted to the LLP. ) Agree/disagree (by part) There are two "allowed" behaviors after reception of item 1.=20 1. sending the ULP 200 bytes of data 2. sending the ULP an error message (not currently defined) The ONLY correct behavior on reception of item 2 is to send the ULP the error (0x03 - invalid MSN - MSN range is not valid) -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Caitlin Bestler Sent: Tuesday, January 27, 2004 9:59 AM To: Paul Culley; RDDP Subject: Re: [rddp] DDP segment sequences for Untagged DDP message On Jan 27, 2004, at 8:01 AM, Culley, Paul wrote: > OK, I realize that I missed a small point; in the first case below > > 1. QN =3D 0, MSN =3D 1, MO =3D 100 L =3D 1 Payload =3D 100 bytes > 2. QN =3D 0, MSN =3D 1, MO =3D 0 L =3D 0 Payload =3D 100 bytes > Result: DDP Message (bytes 0-200) is delivered to ULP > [prc] yes > [pat]DDP message (bytes 0-200) occurs after 1. > 2 will cause an invalid MSN error > > I was thinking of TCP segments as they arrive at the receiver, not as > sent at the transmitter. If the example was sent in this order, I=20 > agree > that an invalid MSN error is the correct answer, The MSN is invalid, but the receiver is not obligated to catch it. If DDP-Segment 2 is placed *before* DDP-Segment 1 is completed, then no error will be detected. Both the MO and MSN are in range. The 100 bytes will be placed. This obviously can occur if DDP-Segment 2 arrives before DDP-Segment 1. But it can also occur if they arrive in order and the receiver pipelines processing of DDP-Segments. Remember that all implications of out-of-order processing hold no matter what the reason for the out-of-order processing is. The packets do not have to have been in the "wrong order" on the wire for out-of-order processing to occur. Similarly, the fact that MSN 17 invalidated STag 504 does not guarantee that use of STag 504 in a tagged message that is latter in the LLP stream will be flagged as an error. Invalidation is only guaranteed by the time it is reported to the Data Sink ULP. --=20 Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ 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 exim@www1.ietf.org Tue Jan 27 20:38:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09183 for ; Tue, 27 Jan 2004 20:38:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aleef-0002F7-Q6 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 20:38:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S1c9Pm008615 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 20:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aleef-0002Es-MX for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09177 for ; Tue, 27 Jan 2004 20:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aleed-0007Xj-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 20:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aledf-0007UQ-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 20:37:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AledE-0007Rk-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 20:36:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldHj-0001c0-BM; Tue, 27 Jan 2004 19:10:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlDVW-0007SG-Go for rddp@optimus.ietf.org; Mon, 26 Jan 2004 15:38:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19593 for ; Mon, 26 Jan 2004 15:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlDVV-0002vz-00 for rddp@ietf.org; Mon, 26 Jan 2004 15:38:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlDUh-0002of-00 for rddp@ietf.org; Mon, 26 Jan 2004 15:38:04 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AlDTG-0002ZV-00 for rddp@ietf.org; Mon, 26 Jan 2004 15:36:34 -0500 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 25AE624A251; Mon, 26 Jan 2004 14:46:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <000501c3e43b$44b8f000$467fa8c0@i8600> References: <000501c3e43b$44b8f000$467fa8c0@i8600> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2239CBCD-5038-11D8-8B3E-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] DDP segment sequences for Untagged DDP message Date: Mon, 26 Jan 2004 13:45:03 -0600 To: Barry Reinhold , RDDP X-Mailer: Apple Mail (2.609) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > Would the following be acceptable wording? > > At the Data Sink, DDP MUST NOT Deliver a DDP Message until all of the > following conditions are true: > > * a DDP segment with the L bit set has been placed for this DDP > message > > * all octets, based on LLP sequence information, have been placed > for this DDP message. > > * all preceding DDP Message have been Delivered to the ULP. > Well yes, the essential requirement is "everything prior placed" and "prior messages completed". But I do not think this wording is any clearer than the original, and the second clause is almost misleading in its use of "all octets" and "for this DDP message". The DDP Layer does not know truly understand what inbound messages are. All that it knows is that all portions of the message are in or earlier than (in LLP sequence) than the segment with the L bit (and that the segment with the L bit has the highest MO if untagged). So the DDP Layer only knows when all octets for this LLP Sequence has been placed because it knows when all octets for all prior packets (based on LLP Sequence) have been placed -- but it has no recollection about which of those bytes were for any given message. The intent here is to 'scoreboard' the LLP stream, not messages. This is especially valuable because the LLP is doing so already. The second clause also implies that LLP sequence information is somehow byte related. When the transport is SCTP this is not the case. Indeed the "LLP Sequence" might not even match the actual transmit order because the sending stack is allowed to re-order Data Chunks to optimize chunk bundling. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Jan 27 20:40:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09279 for ; Tue, 27 Jan 2004 20:40:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlegZ-0002Iz-0w for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 20:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S1e697008855 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 20:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlegY-0002Ia-BN for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09255 for ; Tue, 27 Jan 2004 20:40:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlegV-0007fM-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 20:40:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alefb-0007by-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 20:39:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aleeg-0007YT-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 20:38:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldHv-0001jY-PP; Tue, 27 Jan 2004 19:10:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlDwr-0000Gp-AU for rddp@optimus.ietf.org; Mon, 26 Jan 2004 16:07:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20336 for ; Mon, 26 Jan 2004 16:07:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlDwp-0004AB-00 for rddp@ietf.org; Mon, 26 Jan 2004 16:07:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlDvr-000462-00 for rddp@ietf.org; Mon, 26 Jan 2004 16:06:08 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AlDuv-00042V-00 for rddp@ietf.org; Mon, 26 Jan 2004 16:05:10 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 13:04:36 -0800 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jan 2004 13:04:37 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 13:04:35 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Jan 2004 13:04:36 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Jan 2004 13:04:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [rddp] RDDP Security - misc comments, 1-16 Date: Mon, 26 Jan 2004 13:04:27 -0800 Message-ID: Thread-Topic: [rddp] RDDP Security - misc comments, 1-16 thread-index: AcPggp77P7pVE3zjSJSQiu5j8qBCQgDnu1ag From: "Jim Pinkerton" To: "Jim Pinkerton" , X-OriginalArrivalTime: 26 Jan 2004 21:04:33.0503 (UTC) FILETIME=[FF6786F0:01C3E44F] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E44F.FBE37BEC" ------_=_NextPart_001_01C3E44F.FBE37BEC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 ________________________________ From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim Pinkerton Sent: Wednesday, January 21, 2004 4:57 PM To: rddp@ietf.org Subject: [rddp] RDDP Security - misc comments, 1-16 =20 Mike Krause has done a great job reviewing the doc and coming up with questions. Because there are quite a few questions/issues raised, I'm dividing them into multiple emails to help focus the discussion. This email handles questions which don't bring up organizational issues, through question 16. Organizational issues will be in a separate email. =20 > (9) 4.3 Is 4.3 just a place holder? Not clear its relevance to the draft > as many system properties can be attacked but these are outside the scope > of RDMA itself. =20 This was included at the direction of security folks - in general, all of the attacks described in the document fall into the category of system integrity. One thing that is not done in the document is to directly reference which categories the attacks fall into (integrity, stability, confidentiality). Alternatively, if folks don't see a lot of value in this section (i.e. what is being attacked is obvious), I could just delete the section. =20 [] I'll just delete it. I chatted with Sara Bitan, my new co-author on security, and the reality is that the concepts are pretty obvious - and the rest of the document specifies the exact thing being attacked and its repercussions, without referring to these generic, high level concepts. And I don't think it adds to the paper to put a new sentence after each attack stating which high level concept the attack applies to. =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C3E44F.FBE37BEC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim Pinkerton
Sent: Wednesday, January = 21, 2004 4:57 PM
To: rddp@ietf.org
Subject: [rddp] RDDP = Security - misc comments, 1-16

 

Mike Krause has done a great job reviewing the doc = and coming up with questions. Because there are quite a few questions/issues raised, I’m dividing them into multiple emails to help focus the discussion. This email handles questions which don’t bring up organizational issues, through question 16. Organizational issues will = be in a separate email.

 

> (9) 4.3 Is 4.3 just a place holder?  Not clear its = relevance to the draft

> as many system properties can be attacked but these are = outside the scope

> of RDMA itself.

 

This was included at the direction of security folks – in general, all of the attacks described in the document fall into the = category of system integrity.  One thing that is not done in the document  = is to directly reference which categories the attacks fall into (integrity, stability, confidentiality). Alternatively, if folks don’t see a = lot of value in this section (i.e. what is being attacked is obvious), I could = just delete the section.

 

[<jim>] I’ll just delete = it. I chatted with Sara Bitan, my new co-author on security, and the reality = is that the concepts are pretty obvious – and the rest of the document = specifies the exact thing being attacked and its repercussions, without referring = to these generic, high level concepts. And I don’t think it adds to the = paper to put a new sentence after each attack stating which high level concept = the attack applies to.

 

 

Jim

 

 

 

------_=_NextPart_001_01C3E44F.FBE37BEC-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Jan 27 21:11:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10712 for ; Tue, 27 Jan 2004 21:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfAW-000425-44 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 21:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S2B4I7015495 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 21:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfAV-00041q-Uk for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 21:11:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10560 for ; Tue, 27 Jan 2004 21:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfAT-0002Rz-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 21:11:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alf8g-00027n-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 21:09:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Alf7e-00023H-02 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 21:08:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Alf2F-0004Ey-1J for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 21:02:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldHw-0001nE-SB; Tue, 27 Jan 2004 19:10:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlDx0-0000Jo-9c for rddp@optimus.ietf.org; Mon, 26 Jan 2004 16:07:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20360 for ; Mon, 26 Jan 2004 16:07:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlDwy-0004BX-00 for rddp@ietf.org; Mon, 26 Jan 2004 16:07:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlDw2-00047l-00 for rddp@ietf.org; Mon, 26 Jan 2004 16:06:19 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AlDvN-00042h-00 for rddp@ietf.org; Mon, 26 Jan 2004 16:05:37 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 13:05:26 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 26 Jan 2004 13:05:55 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jan 2004 13:05:03 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 13:04:40 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Jan 2004 13:05:02 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Jan 2004 13:04:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Mon, 26 Jan 2004 13:04:53 -0800 Message-ID: Thread-Topic: security draft removal of "Trust Models" thread-index: AcPkP1An6hMxEH2jRp2u4S35vszlrg== From: "Jim Pinkerton" To: Cc: "Sara Bitan" X-OriginalArrivalTime: 26 Jan 2004 21:04:59.0252 (UTC) FILETIME=[0EC08340:01C3E450] Subject: [rddp] security draft removal of "Trust Models" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E450.0B1BE1A8" ------_=_NextPart_001_01C3E450.0B1BE1A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 In doing the editing of the document to move the "Trust Models" concept to an appendix, I'm using the following assumptions (significant editing is being done to make these assumptions clean). Comments welcome: =20 - The Remote Peer is generally "untrusted".=20 - The key issue remaining is whether local resources are shared or unshared. o For cases where resource sharing can occur, there is two categories - Streams where there is no "mutual trust", and Streams where there is "mutual trust". For example, an iSCSI session with multiple connections is an example of where streams share "mutual trust". A more complex example might be a file server, where multiple streams to a specific client might share mutual trust, but no client has mutual trust with another client. =20 =20 In writing this up, I couldn't find an example where it helped to further divide the definition to include remote and local - i.e. remote mutual trust or local mutual trust. While theoretically possible, it doesn't appear to apply for most protocols - and the document is already long enough (~60 pages by the time it will be submitted). For example, a file server may potentially have several Streams to a specific client that share mutual trust, but there is no mutual trust between any single collection of Streams which share mutual trust.=20 =20 Note that resource sharing can occur between streams which do not share mutual trust - the two issues are independent. You can have/ have not mutual trust between streams, and you can share/share not resources between streams. For example, if there is no mutual trust between Streams, then you should not expose the same STag to two streams because one could invalidate the STag while the other is using it. However you can share a common Untagged Receive Queue, as long as security mitigations are in place. =20 =20 Jim =20 =20 =20 =20 =20 ------_=_NextPart_001_01C3E450.0B1BE1A8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

In doing the editing of the document to move the = “Trust Models” concept to an appendix, I’m using the following = assumptions (significant editing is being done to make these assumptions clean). = Comments welcome:

 

-          The Remote Peer is generally = “untrusted”.

-          The key issue remaining is whether local = resources are shared or unshared.

o        For cases where resource sharing can occur, = there is two categories – Streams where there is no “mutual = trust”, and Streams where there is “mutual trust”. For example, an = iSCSI session with multiple connections is an example of where streams share = “mutual trust”. A more complex example might be a file server, where = multiple streams to a specific client might share mutual trust, but no client has = mutual trust with another client.  

 

In writing this up, I couldn’t find an example = where it helped to further divide the definition to include remote and local = – i.e. remote mutual trust or local mutual trust. While theoretically = possible, it doesn’t appear to apply for most protocols – and the = document is already long enough (~60 pages by the time it will be submitted). For = example, a file server may potentially have several Streams to a specific client = that share mutual trust, but there is no mutual trust between any single = collection of Streams which share mutual trust.

 

Note that resource sharing can occur between streams = which do not share mutual trust – the two issues are independent. You = can have/ have not mutual trust between streams, and you can share/share not = resources between streams. For example, if there is no mutual trust between Streams, then = you should not expose the same STag to two streams because one could = invalidate the STag while the other is using it. However you can share a common = Untagged Receive Queue, as long as security mitigations are in = place.

 

 

Jim

 

 

 

 

 

------_=_NextPart_001_01C3E450.0B1BE1A8-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Jan 27 21:54:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12906 for ; Tue, 27 Jan 2004 21:54:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfqH-0006qw-Sk for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 21:54:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S2sDdt026342 for rddp-archive@odin.ietf.org; Tue, 27 Jan 2004 21:54:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfqH-0006qn-OC for rddp-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 21:54:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12900 for ; Tue, 27 Jan 2004 21:54:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfqE-0005xo-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 21:54:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlfpS-0005uU-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 21:53:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alfp5-0005qU-00 for rddp-web-archive@ietf.org; Tue, 27 Jan 2004 21:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alfp6-0006lV-RB; Tue, 27 Jan 2004 21:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfoH-0006j6-Be for rddp@optimus.ietf.org; Tue, 27 Jan 2004 21:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12824 for ; Tue, 27 Jan 2004 21:52:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfoE-0005ny-00 for rddp@ietf.org; Tue, 27 Jan 2004 21:52:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlfnG-0005ie-00 for rddp@ietf.org; Tue, 27 Jan 2004 21:51:07 -0500 Received: from mail3.ttlc.net ([66.94.32.26] helo=mail.communicom.net) by ietf-mx with esmtp (Exim 4.12) id 1AlfmJ-0005ay-00 for rddp@ietf.org; Tue, 27 Jan 2004 21:50:07 -0500 Received: from lampreynetworks.com [66.94.32.4] by mail.communicom.net with ESMTP (SMTPD32-7.07) id A4AD1D3E00A4; Tue, 27 Jan 2004 21:55:41 -0500 Received: from i8600 [24.61.195.169] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A4A98E2C0148; Tue, 27 Jan 2004 21:55:37 -0500 From: "Barry Reinhold" To: , , , Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Date: Tue, 27 Jan 2004 21:49:21 -0500 Message-ID: <000a01c3e549$56236780$c282a8c0@i8600> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, Good catch -- your understanding of LLPSegNumCompleted is what I intended. Case 2 is incorrect, but you provided the information I was looking for anyways. -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of pat_thaler@agilent.com Sent: Tuesday, January 27, 2004 7:49 PM To: bbr@lampreynetworks.com; cait@asomi.com; paul.culley@hp.com; rddp@ietf.org Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Barry, In case 1, the transmitter sent the segments to the LLP in the correct order and they got misordered on the way to the receiver. As you stated, no errors occurred and the correct behavior is to deliver the message with a length of 200 octets. By the way, I think you meant that LLPSeqNumCompleted indicates that all octets in the LLP stream up to that point have been transfered to DDP. The LLP doesn't do placement - DDP does placement. Therefore, the LLP can't maintain a value indicating which octets in the stream have been placed. I also am assuming that when you mention your new terms, Seq=Seg. I don't understand your case 2. If I understand LLPSeqNumCompleted, it indicates how much of the LLP data stream has been completely received (that is, the point to which there are no gaps due to out of order arrival). Therefore, it should increase with time - it can never decrease. In case 2 below it decreases so either I don't understand LLPSeqNumCompleted or there is a typo in the example. Also note that item 11 in section 5 Reliable Deliver LLP Requirements is that the LLP MUST NOT pass a duplicate DDP segment to DDP after it has passed all previous segments to DDP. This requirement means that LLPSeqNumTag MUST always be greater then the previous value of LLPSeqNumCompleted. You said that this was the case where the transmitter violated sending the last segment last. In that case, the segment in 2 would have a higher sequence number than the segment in 1 so perhaps you meant: Case 2b DDP segments as seen in time order at the receiver: 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted = 600, LLPSegNumTag = 600 2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSegNumCompleted = 700, LLPSegNumTag = 700 In that case I agree that: There are two "allowed" behaviors after reception of item 1. 1. sending the ULP 200 bytes of data 2. sending the ULP an error message (not currently defined) I almost agree with your next statement: The ONLY correct behavior on reception of item 2 is to send the ULP the error (0x03 - invalid MSN - MSN range is not valid) There is the issue that Caitlin pointed out. It is possible that there is a window in a DDP implementation where it has received segment 1 and is still munching on it (hasn't advanced the MSN range yet) while segment 2 comes in and gets placed. In that case, segment 2 could come in and get placed without an error being detected. This would be similar to the behavior that could occur if segment 2 arrived out of order before segment 1. The ambiguous window should be over before the Untagged Message is delivered to the ULP because DDP should ensure that it doesn't touch the buffer once it has delivered it. So, if MSN 1 was delivered before 2 arrived, then 2 should cause the invalid MSN error. Regards, Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Barry Reinhold Sent: Tuesday, January 27, 2004 9:35 AM To: 'Caitlin Bestler'; 'Paul Culley'; 'RDDP' Subject: RE: [rddp] DDP segment sequences for Untagged DDP message Pat, Caitlin, Paul, I think several different issues have come up, as I formulated my initial post somewhat poorly. I would like to clarify it a bit to see if we have agreement. Definition of terms: QN - Queue Number in the header of the untagged DDP message MSN - Message Sequence number in the header of the untagged DDP message L - L bit in the header of the untagged DDP message Payload - The number of bytes in the payload of the DDP segment LLPSeqNumTag - Assume this to be the LLP Sequence number associated with the last octet of the DDP Segment received. LLPSegNumCompleted - Assume this to be an LLP maintained value that indicates that all octets in the LLP stream up to the value indicated have been placed. I recognize that LLPSegNumTag and LLPSegNumCompleted do not exist in the draft, but I don't see how to clearly specify the problem with terms currently defined in the draft. Also note that, for simplicity reasons, the LLP sequence numbers just follow DDP payload data, they are not real LLP sequence numbers. (The only condition that needs to be testable is if the LLPSeqNumCompleted matches the LLPSegNumTag of the segment with the L bit set to 1.) Case 1 DDP segments as seen in time order at the receiver: 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted = 500, LLPSeqNumTag = 600 2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSeqNumCompleted = 600, LLPSegNumTag = 500 Is the ONLY correct behavior to deliver 200 bytes of data to the ULP upon reception of the second (item 2.) DDP segment? Case 2 DDP segments as seen in time order at the receiver: 1. QN = 0, MSN = 1, MO = 100, L = 1, Payload = 100, LLPSegNumCompleted = 600, LLPSegNumTag = 600 2. QN = 0, MSN = 1, MO = 000, L = 0, Payload = 100, LLPSegNumCompleted = 500, LLPSegNumTag = 500 (In this case the transmitter has violated 6.1 which states: The DDP Segment with the L bit set to 1 MUST be posted to the LLP after all other DDP Segments of the associated DDP Message have been posted to the LLP. ) Agree/disagree (by part) There are two "allowed" behaviors after reception of item 1. 1. sending the ULP 200 bytes of data 2. sending the ULP an error message (not currently defined) The ONLY correct behavior on reception of item 2 is to send the ULP the error (0x03 - invalid MSN - MSN range is not valid) -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Caitlin Bestler Sent: Tuesday, January 27, 2004 9:59 AM To: Paul Culley; RDDP Subject: Re: [rddp] DDP segment sequences for Untagged DDP message On Jan 27, 2004, at 8:01 AM, Culley, Paul wrote: > OK, I realize that I missed a small point; in the first case below > > 1. QN = 0, MSN = 1, MO = 100 L = 1 Payload = 100 bytes > 2. QN = 0, MSN = 1, MO = 0 L = 0 Payload = 100 bytes > Result: DDP Message (bytes 0-200) is delivered to ULP > [prc] yes > [pat]DDP message (bytes 0-200) occurs after 1. > 2 will cause an invalid MSN error > > I was thinking of TCP segments as they arrive at the receiver, not as > sent at the transmitter. If the example was sent in this order, I > agree > that an invalid MSN error is the correct answer, The MSN is invalid, but the receiver is not obligated to catch it. If DDP-Segment 2 is placed *before* DDP-Segment 1 is completed, then no error will be detected. Both the MO and MSN are in range. The 100 bytes will be placed. This obviously can occur if DDP-Segment 2 arrives before DDP-Segment 1. But it can also occur if they arrive in order and the receiver pipelines processing of DDP-Segments. Remember that all implications of out-of-order processing hold no matter what the reason for the out-of-order processing is. The packets do not have to have been in the "wrong order" on the wire for out-of-order processing to occur. Similarly, the fact that MSN 17 invalidated STag 504 does not guarantee that use of STag 504 in a tagged message that is latter in the LLP stream will be flagged as an error. Invalidation is only guaranteed by the time it is reported to the Data Sink ULP. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ 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 exim@www1.ietf.org Thu Jan 29 13:29:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06395 for ; Thu, 29 Jan 2004 13:29:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGu2-0003at-2h for rddp-archive@odin.ietf.org; Thu, 29 Jan 2004 13:28:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TISYho013809 for rddp-archive@odin.ietf.org; Thu, 29 Jan 2004 13:28:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGu1-0003ae-VS for rddp-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 13:28:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06388 for ; Thu, 29 Jan 2004 13:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGtz-0004Ka-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 13:28:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGsz-0004Dt-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 13:27:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmGsW-00048i-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 13:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGsW-0003U8-CW; Thu, 29 Jan 2004 13:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGs2-0003TW-2T for rddp@optimus.ietf.org; Thu, 29 Jan 2004 13:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06357 for ; Thu, 29 Jan 2004 13:26:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGrz-00048D-00 for rddp@ietf.org; Thu, 29 Jan 2004 13:26:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGr6-00042z-00 for rddp@ietf.org; Thu, 29 Jan 2004 13:25:33 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AmGqQ-0003rZ-00 for rddp@ietf.org; Thu, 29 Jan 2004 13:24:50 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 10:26:34 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Jan 2004 10:24:20 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 10:24:19 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 10:24:33 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 29 Jan 2004 10:25:13 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Thu, 29 Jan 2004 10:24:18 -0800 Message-ID: Thread-Topic: Removing Trust Models and including "Mutual Trust" Thread-Index: AcPmlRt1FfHXSBJdTtC6PygMGhvzJA== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 29 Jan 2004 18:25:13.0322 (UTC) FILETIME=[3C54ECA0:01C3E695] Subject: [rddp] Removing Trust Models and including "Mutual Trust" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E695.1CF950F7" ------_=_NextPart_001_01C3E695.1CF950F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Per the last IETF meeting, the Trust Model concept has now been moved to the Appendix. The document now focuses on whether a resource is shared or not, and assumes the Remote Peer is untrusted. An interesting side-effect of this is that the definition for "Partial Trust" goes with it. And the document in general assumes the Remote Peer (and Unprivileged Local Peer) are simply "untrusted". =20 This semantic is unfortunately not rich enough, however. I've started editing the document to more directly address security concerns in a client/server environment. As part of that editing, it seems worthwhile to introduce a new concept Sara Bitan and I are calling "partial mutual trust" (Sara is now an author on the document, specifically working on the Security Services for RDMAP/DDP section). This more acurately describes the "session" concept that some applications have. And then one can talk about how two Streams do not share "mutual trust" and thus are subject to a specific attack and need X countermeasure - so we can now define a server that has multiple sessions (each with potentially multiple Streams) to individual clients, and individual clients do not trust each other. =20 Feedback on this model would be appreciated. =20 Here's my tentative definition of "partial mutual trust": =20 Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing to assume that the other Streams will not perform malicious attacks against any of the Streams in the collection. =20 =20 Jim =20 =20 ------_=_NextPart_001_01C3E695.1CF950F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Per the last IETF meeting, the Trust Model concept = has now been moved to the Appendix. The document now focuses on whether a = resource is shared or not, and assumes the Remote Peer is untrusted. An interesting side-effect of this is that the definition for “Partial = Trust” goes with it. And the document in general assumes the Remote Peer (and = Unprivileged Local Peer) are simply “untrusted”.

 

This semantic is unfortunately not rich enough, = however. I’ve started editing the document to more directly address security concerns = in a client/server environment. As part of that editing, it seems worthwhile = to introduce a new concept Sara Bitan and I are calling “partial = mutual trust” (Sara is now an author on the document, specifically = working on the Security Services for RDMAP/DDP section). This more acurately = describes the “session” concept that some applications have. And then one = can talk about how two Streams do not share “mutual trust” and = thus are subject to a specific attack and need X countermeasure – so we can = now define a server that has multiple sessions (each with potentially = multiple Streams) to individual clients, and individual clients do not trust each = other.

 

Feedback on this model would be = appreciated.

 

Here’s my tentative definition of = “partial mutual trust”:

 

Partial Mutual Trust – a collection of = RDMAP/DDP Streams are willing to assume that the other Streams will not perform = malicious attacks against any of the Streams in the collection.

 

 

Jim

 

 

------_=_NextPart_001_01C3E695.1CF950F7-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 29 16:45:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21294 for ; Thu, 29 Jan 2004 16:45:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJyc-0002Kg-Fk for rddp-archive@odin.ietf.org; Thu, 29 Jan 2004 16:45:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TLjUOu008962 for rddp-archive@odin.ietf.org; Thu, 29 Jan 2004 16:45:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJyc-0002KT-CV for rddp-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 16:45:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21155 for ; Thu, 29 Jan 2004 16:45:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmJya-0007gO-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 16:45:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmJwv-0007Ek-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 16:43:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmJuf-0006bh-09 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 16:41:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJhh-0000KL-KF; Thu, 29 Jan 2004 16:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJgz-0000Dh-Sg for rddp@optimus.ietf.org; Thu, 29 Jan 2004 16:27:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19605 for ; Thu, 29 Jan 2004 16:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmJgx-0004pn-00 for rddp@ietf.org; Thu, 29 Jan 2004 16:27:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmJfN-0004Vt-00 for rddp@ietf.org; Thu, 29 Jan 2004 16:25:38 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AmJeI-00047j-00 for rddp@ietf.org; Thu, 29 Jan 2004 16:24:30 -0500 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 31700273893; Thu, 29 Jan 2004 15:59:14 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: From: Caitlin Bestler Subject: Re: [rddp] Removing Trust Models and including "Mutual Trust" Date: Thu, 29 Jan 2004 14:58:05 -0600 To: "Jim Pinkerton" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Jan 29, 2004, at 12:24 PM, Jim Pinkerton wrote: > =A0 > > Per the last IETF meeting, the Trust Model concept has now been moved=20= > to the Appendix. The document now focuses on whether a resource is=20 > shared or not, and assumes the Remote Peer is untrusted. An=20 > interesting side-effect of this is that the definition for =93Partial=20= > Trust=94 goes with it. And the document in general assumes the Remote=20= > Peer (and Unprivileged Local Peer) are simply =93untrusted=94. > > =A0 > > This semantic is unfortunately not rich enough, however. I=92ve = started=20 > editing the > document to more directly address security concerns in a client/server=20= > environment. > As part of that editing, it seems worthwhile to introduce a new=20 > concept Sara Bitan > and I are calling =93partial mutual trust=94 (Sara is now an author on = the=20 > document, > specifically working on the Security Services for RDMAP/DDP section).=20= > This more > acurately describes the =93session=94 concept that some applications = have.=20 > And then > one can talk about how two Streams do not share =93mutual trust=94 and=20= > thus are subject > to a specific attack and need X countermeasure =96 so we can now = define=20 > a server that > has multiple sessions (each with potentially multiple Streams) to=20 > individual clients, > and individual clients do not trust each other. > > =A0 > > Feedback on this model would be appreciated. > > =A0 > > Here=92s my tentative definition of =93partial mutual trust=94: > > =A0 > > Partial Mutual Trust =96 a collection of RDMAP/DDP Streams are willing=20= > to assume that > the other Streams will not perform malicious attacks against any of=20 > the Streams in > the collection. > > =A0 On a purely semantic basis I'm not sure I like assigning intent to the=20= Streams, to the endpoints of the stream yes, but not the streams themselves. Aside from that, is the intent here to distinguish between absence of=20 malice from "full compliance with the ULP"? Where the latter would be Full=20 Mutual Trust? ("Full compliance with the ULP" implies compliance with all *rules* of=20= the ULP, not just the packet formats. Hence a properly filled out withdrawal request with a forged signature is not truly "ULP compliant" even if the syntax checks all pass because the packet is not submitted in compliance with the full ULP). _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 29 19:27:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02755 for ; Thu, 29 Jan 2004 19:27:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMUh-0005EE-81 for rddp-archive@odin.ietf.org; Thu, 29 Jan 2004 19:26:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U0QlSf020094 for rddp-archive@odin.ietf.org; Thu, 29 Jan 2004 19:26:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMUh-0005E1-4E for rddp-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 19:26:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02745 for ; Thu, 29 Jan 2004 19:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMUf-0001JJ-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 19:26:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMTk-0001D4-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 19:25:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmMT0-00016T-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 19:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMT0-0004zo-PG; Thu, 29 Jan 2004 19:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMSe-0004z4-3P for rddp@optimus.ietf.org; Thu, 29 Jan 2004 19:24:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02644 for ; Thu, 29 Jan 2004 19:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMSc-000154-00 for rddp@ietf.org; Thu, 29 Jan 2004 19:24:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMRm-0000zH-00 for rddp@ietf.org; Thu, 29 Jan 2004 19:23:48 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AmMR1-0000lP-00 for rddp@ietf.org; Thu, 29 Jan 2004 19:22:59 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 16:20:40 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Jan 2004 16:22:28 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 16:21:08 -0800 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, 29 Jan 2004 16:22:28 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 29 Jan 2004 16:24:15 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [rddp] Removing Trust Models and including "Mutual Trust" Date: Thu, 29 Jan 2004 16:22:24 -0800 Message-ID: Thread-Topic: [rddp] Removing Trust Models and including "Mutual Trust" Thread-Index: AcPmrj3i2/gNH28YStaU5jQsQW+G8QAGC+QQ From: "Jim Pinkerton" To: "Caitlin Bestler" Cc: X-OriginalArrivalTime: 30 Jan 2004 00:24:15.0504 (UTC) FILETIME=[64790900:01C3E6C7] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E6C7.23F448E9" ------_=_NextPart_001_01C3E6C7.23F448E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I'm not trying to make any statement about ULP behavior - just RDDP behavior. I.e. that the two ends of a Stream will not try to perform malicious RDMAP/DDP attacks on each other. Thus "full compliance with the ULP" would be out of scope (i.e. doesn't matter for this security document). =20 On the use of "Streams", I used "Streams" as short hand - the sentence now repeats the word multiple times - and the equivalent end point text is "the Local and Remote Peer". I don't see any loss of clarity in using Streams, and believe it to be more readable. =20 Separately, I got feedback to change the wording slightly to (change is in bold, if it gets through the reflector): =20 =20 Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing to assume that the Streams from the collection will not perform malicious attacks against any of the Streams in the collection. =20 Would it make it clearer if I changed "malicious attacks" to "malicious RDMAP/DDP attacks"? =20 =20 =20 Jim =20 =20 =20 > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, January 29, 2004 12:58 PM > To: Jim Pinkerton > Cc: rddp@ietf.org > Subject: Re: [rddp] Removing Trust Models and including "Mutual Trust" >=20 >=20 > On Jan 29, 2004, at 12:24 PM, Jim Pinkerton wrote: >=20 > > > > > > Per the last IETF meeting, the Trust Model concept has now been moved > > to the Appendix. The document now focuses on whether a resource is > > shared or not, and assumes the Remote Peer is untrusted. An > > interesting side-effect of this is that the definition for "Partial > > Trust" goes with it. And the document in general assumes the Remote > > Peer (and Unprivileged Local Peer) are simply "untrusted". > > > > > > > > This semantic is unfortunately not rich enough, however. I've started > > editing the > > document to more directly address security concerns in a client/server > > environment. > > As part of that editing, it seems worthwhile to introduce a new > > concept Sara Bitan > > and I are calling "partial mutual trust" (Sara is now an author on the > > document, > > specifically working on the Security Services for RDMAP/DDP section). > > This more > > acurately describes the "session" concept that some applications have. > > And then > > one can talk about how two Streams do not share "mutual trust" and > > thus are subject > > to a specific attack and need X countermeasure - so we can now define > > a server that > > has multiple sessions (each with potentially multiple Streams) to > > individual clients, > > and individual clients do not trust each other. > > > > > > > > Feedback on this model would be appreciated. > > > > > > > > Here's my tentative definition of "partial mutual trust": > > > > > > > > Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing > > to assume that > > the other Streams will not perform malicious attacks against any of > > the Streams in > > the collection. > > > > >=20 >=20 > On a purely semantic basis I'm not sure I like assigning intent to the > Streams, > to the endpoints of the stream yes, but not the streams themselves. >=20 > Aside from that, is the intent here to distinguish between absence of > malice > from "full compliance with the ULP"? Where the latter would be Full > Mutual Trust? > ("Full compliance with the ULP" implies compliance with all *rules* of > the > ULP, not just the packet formats. Hence a properly filled out withdrawal > request with a forged signature is not truly "ULP compliant" even if the > syntax checks all pass because the packet is not submitted in compliance > with the full ULP). =20 ------_=_NextPart_001_01C3E6C7.23F448E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I'm not trying to make any statement about ULP behavior - just = RDDP behavior. I.e. that the two ends of a Stream will not try to perform = malicious RDMAP/DDP attacks on each other. Thus "full compliance with the = ULP" would be out of scope (i.e. doesn't matter for this security = document).

 

On the use of "Streams", I used "Streams" as = short hand - the sentence now repeats the word multiple times - and the = equivalent end point text is "the Local and Remote Peer". I don't see any = loss of clarity in using Streams, and believe it to be more = readable.

 

Separately, I got feedback to change the wording slightly to = (change is in bold, if it gets through the reflector):

 

 

Partial Mutual Trust – a collection of = RDMAP/DDP Streams are willing to assume that the Streams from the collection will = not perform malicious attacks against any of the Streams in the = collection.

 

Would it make it clearer if I changed “malicious = attacks” to “malicious RDMAP/DDP attacks”?

 

 

 

Jim

 

 

 

> -----Original Message-----

> From: Caitlin Bestler = [mailto:cait@asomi.com]

> Sent: Thursday, January 29, 2004 12:58 PM

> To: Jim Pinkerton

> Cc: rddp@ietf.org

> Subject: Re: [rddp] Removing Trust Models and including "Mutual Trust"

>

>

> On Jan 29, 2004, at 12:24 PM, Jim Pinkerton = wrote:

>

> >

> >

> > Per the last IETF meeting, the Trust Model concept has = now been moved

> > to the Appendix. The document now focuses on whether a resource is

> > shared or not, and assumes the Remote Peer is = untrusted. An

> > interesting side-effect of this is that the definition = for “Partial

> > Trust” goes with it. And the document in general assumes the Remote

> > Peer (and Unprivileged Local Peer) are simply “untrusted”.

> >

> >

> >

> > This semantic is unfortunately not rich enough, = however. I’ve started

> > editing the

> > document to more directly address security concerns in = a client/server

> > environment.

> > As part of that editing, it seems worthwhile to = introduce a new

> > concept Sara Bitan

> > and I are calling “partial mutual trust” = (Sara is now an author on the

> > document,

> > specifically working on the Security Services for = RDMAP/DDP section).

> > This more

> > acurately describes the “session” concept = that some applications have.

> > And then

> > one can talk about how two Streams do not share = “mutual trust” and

> > thus are subject

> > to a specific attack and need X countermeasure – = so we can now define

> > a server that

> > has multiple sessions (each with potentially multiple Streams) to

> > individual clients,

> > and individual clients do not trust each = other.

> >

> >

> >

> > Feedback on this model would be = appreciated.

> >

> >

> >

> > Here’s my tentative definition of “partial = mutual trust”:

> >

> >

> >

> > Partial Mutual Trust – a collection of RDMAP/DDP Streams are willing

> > to assume that

> > the other Streams will not perform malicious attacks = against any of

> > the Streams in

> > the collection.

> >

> >

>

>

> On a purely semantic basis I'm not sure I like assigning = intent to the

> Streams,

> to the endpoints of the stream yes, but not the streams themselves.

>

> Aside from that, is the intent here to distinguish between = absence of

> malice

> from "full compliance with the ULP"? Where the = latter would be Full

> Mutual Trust?

> ("Full compliance with the ULP" implies = compliance with all *rules* of

> the

> ULP, not just the packet formats. Hence a properly filled = out withdrawal

> request with a forged signature is not truly "ULP compliant" even if the

> syntax checks all pass because the packet is not submitted = in compliance

> with the full ULP).

 

------_=_NextPart_001_01C3E6C7.23F448E9-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Jan 29 19:48:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03235 for ; Thu, 29 Jan 2004 19:48:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMoz-0006UU-2j for rddp-archive@odin.ietf.org; Thu, 29 Jan 2004 19:47:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U0lj6L024944 for rddp-archive@odin.ietf.org; Thu, 29 Jan 2004 19:47:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMoy-0006UF-V1 for rddp-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 19:47:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03231 for ; Thu, 29 Jan 2004 19:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMox-0003Xz-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 19:47:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMo6-0003Qw-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 19:46:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmMnI-0003Ku-00 for rddp-web-archive@ietf.org; Thu, 29 Jan 2004 19:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMnI-0006Qn-VK; Thu, 29 Jan 2004 19:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMn5-0006Pw-C7 for rddp@optimus.ietf.org; Thu, 29 Jan 2004 19:45:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03193 for ; Thu, 29 Jan 2004 19:45:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMn3-0003KO-00 for rddp@ietf.org; Thu, 29 Jan 2004 19:45:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMm4-0003EM-00 for rddp@ietf.org; Thu, 29 Jan 2004 19:44:46 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AmMlU-00036H-00 for rddp@ietf.org; Thu, 29 Jan 2004 19:44:08 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 16:41:46 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Jan 2004 16:43:38 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 16:42:16 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 16:43:52 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 29 Jan 2004 16:45:28 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [rddp] Removing Trust Models and including "Mutual Trust" Date: Thu, 29 Jan 2004 16:43:34 -0800 Message-ID: Thread-Topic: [rddp] Removing Trust Models and including "Mutual Trust" Thread-Index: AcPmrj3i2/gNH28YStaU5jQsQW+G8QAGC+QQAADl3ZA= From: "Jim Pinkerton" To: "Jim Pinkerton" , "Caitlin Bestler" Cc: X-OriginalArrivalTime: 30 Jan 2004 00:45:28.0283 (UTC) FILETIME=[5B1BB2B0:01C3E6CA] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E6CA.18C0454B" ------_=_NextPart_001_01C3E6CA.18C0454B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 How about this to resolove the use of "Streams"?? =20 Partial Mutual Trust - a collection of RDMAP/DDP Streams, which represent the local and remote end points of the Stream, are willing to assume that the Streams from the collection will not perform malicious attacks against any of the Streams in the collection. =20 =20 ________________________________ From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim Pinkerton Sent: Thursday, January 29, 2004 4:22 PM To: Caitlin Bestler Cc: rddp@ietf.org Subject: RE: [rddp] Removing Trust Models and including "Mutual Trust" =20 =20 I'm not trying to make any statement about ULP behavior - just RDDP behavior. I.e. that the two ends of a Stream will not try to perform malicious RDMAP/DDP attacks on each other. Thus "full compliance with the ULP" would be out of scope (i.e. doesn't matter for this security document). =20 On the use of "Streams", I used "Streams" as short hand - the sentence now repeats the word multiple times - and the equivalent end point text is "the Local and Remote Peer". I don't see any loss of clarity in using Streams, and believe it to be more readable. =20 Separately, I got feedback to change the wording slightly to (change is in bold, if it gets through the reflector): =20 =20 Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing to assume that the Streams from the collection will not perform malicious attacks against any of the Streams in the collection. =20 Would it make it clearer if I changed "malicious attacks" to "malicious RDMAP/DDP attacks"? =20 =20 =20 Jim =20 =20 =20 > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, January 29, 2004 12:58 PM > To: Jim Pinkerton > Cc: rddp@ietf.org > Subject: Re: [rddp] Removing Trust Models and including "Mutual Trust" >=20 >=20 > On Jan 29, 2004, at 12:24 PM, Jim Pinkerton wrote: >=20 > > > > > > Per the last IETF meeting, the Trust Model concept has now been moved > > to the Appendix. The document now focuses on whether a resource is > > shared or not, and assumes the Remote Peer is untrusted. An > > interesting side-effect of this is that the definition for "Partial > > Trust" goes with it. And the document in general assumes the Remote > > Peer (and Unprivileged Local Peer) are simply "untrusted". > > > > > > > > This semantic is unfortunately not rich enough, however. I've started > > editing the > > document to more directly address security concerns in a client/server > > environment. > > As part of that editing, it seems worthwhile to introduce a new > > concept Sara Bitan > > and I are calling "partial mutual trust" (Sara is now an author on the > > document, > > specifically working on the Security Services for RDMAP/DDP section). > > This more > > acurately describes the "session" concept that some applications have. > > And then > > one can talk about how two Streams do not share "mutual trust" and > > thus are subject > > to a specific attack and need X countermeasure - so we can now define > > a server that > > has multiple sessions (each with potentially multiple Streams) to > > individual clients, > > and individual clients do not trust each other. > > > > > > > > Feedback on this model would be appreciated. > > > > > > > > Here's my tentative definition of "partial mutual trust": > > > > > > > > Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing > > to assume that > > the other Streams will not perform malicious attacks against any of > > the Streams in > > the collection. > > > > >=20 >=20 > On a purely semantic basis I'm not sure I like assigning intent to the > Streams, > to the endpoints of the stream yes, but not the streams themselves. >=20 > Aside from that, is the intent here to distinguish between absence of > malice > from "full compliance with the ULP"? Where the latter would be Full > Mutual Trust? > ("Full compliance with the ULP" implies compliance with all *rules* of > the > ULP, not just the packet formats. Hence a properly filled out withdrawal > request with a forged signature is not truly "ULP compliant" even if the > syntax checks all pass because the packet is not submitted in compliance > with the full ULP). =20 ------_=_NextPart_001_01C3E6CA.18C0454B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

How about this to resolove the use = of “Streams”??

 

Partial Mutual Trust – a collection of = RDMAP/DDP Streams, which represent the local and remote end points of the Stream, = are willing to assume that the Streams from the collection will not perform malicious attacks against any of the Streams in the = collection.

 

 

From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim Pinkerton
Sent: Thursday, January = 29, 2004 4:22 PM
To: Caitlin Bestler
Cc: rddp@ietf.org
Subject: RE: [rddp] = Removing Trust Models and including "Mutual Trust"

 

 

I'm not trying to make any statement about ULP behavior - just = RDDP behavior. I.e. that the two ends of a Stream will not try to perform = malicious RDMAP/DDP attacks on each other. Thus "full compliance with the = ULP" would be out of scope (i.e. doesn't matter for this security = document).

 

On the use of "Streams", I used "Streams" as = short hand - the sentence now repeats the word multiple times - and the = equivalent end point text is "the Local and Remote Peer". I don't see any = loss of clarity in using Streams, and believe it to be more = readable.

 

Separately, I got feedback to change the wording slightly to = (change is in bold, if it gets through the reflector):

 

 

Partial Mutual Trust – a collection of = RDMAP/DDP Streams are willing to assume that the Streams from the collection will = not perform malicious attacks against any of the Streams in the = collection.

 

Would it make it clearer if I changed “malicious = attacks” to “malicious RDMAP/DDP attacks”?

 

 

 

Jim

 

 

 

> -----Original Message-----

> From: Caitlin Bestler = [mailto:cait@asomi.com]

> Sent: Thursday, January 29, 2004 12:58 PM

> To: Jim Pinkerton

> Cc: rddp@ietf.org

> Subject: Re: [rddp] Removing Trust Models and including "Mutual Trust"

>

>

> On Jan 29, 2004, at 12:24 PM, Jim Pinkerton = wrote:

>

> >

> >

> > Per the last IETF meeting, the Trust Model concept has = now been moved

> > to the Appendix. The document now focuses on whether a resource is

> > shared or not, and assumes the Remote Peer is = untrusted. An

> > interesting side-effect of this is that the definition = for “Partial

> > Trust” goes with it. And the document in general assumes the Remote

> > Peer (and Unprivileged Local Peer) are simply “untrusted”.

> >

> >

> >

> > This semantic is unfortunately not rich enough, = however. I’ve started

> > editing the

> > document to more directly address security concerns in = a client/server

> > environment.

> > As part of that editing, it seems worthwhile to = introduce a new

> > concept Sara Bitan

> > and I are calling “partial mutual trust” = (Sara is now an author on the

> > document,

> > specifically working on the Security Services for = RDMAP/DDP section).

> > This more

> > acurately describes the “session” concept = that some applications have.

> > And then

> > one can talk about how two Streams do not share = “mutual trust” and

> > thus are subject

> > to a specific attack and need X countermeasure – = so we can now define

> > a server that

> > has multiple sessions (each with potentially multiple Streams) to

> > individual clients,

> > and individual clients do not trust each = other.

> >

> >

> >

> > Feedback on this model would be = appreciated.

> >

> >

> >

> > Here’s my tentative definition of “partial = mutual trust”:

> >

> >

> >

> > Partial Mutual Trust – a collection of RDMAP/DDP Streams are willing

> > to assume that

> > the other Streams will not perform malicious attacks = against any of

> > the Streams in

> > the collection.

> >

> >

>

>

> On a purely semantic basis I'm not sure I like assigning = intent to the

> Streams,

> to the endpoints of the stream yes, but not the streams themselves.

>

> Aside from that, is the intent here to distinguish between = absence of

> malice

> from "full compliance with the ULP"? Where the = latter would be Full

> Mutual Trust?

> ("Full compliance with the ULP" implies = compliance with all *rules* of

> the

> ULP, not just the packet formats. Hence a properly filled = out withdrawal

> request with a forged signature is not truly "ULP compliant" even if the

> syntax checks all pass because the packet is not submitted = in compliance

> with the full ULP).

 

------_=_NextPart_001_01C3E6CA.18C0454B-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp