From exim@www1.ietf.org Tue Apr 6 23:35:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00583 for ; Tue, 6 Apr 2004 23:35:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB3qL-0008E2-UZ for rddp-archive@odin.ietf.org; Tue, 06 Apr 2004 23:35:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i373ZDf6031619 for rddp-archive@odin.ietf.org; Tue, 6 Apr 2004 23:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB3qL-0008Dq-L0 for rddp-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 23:35:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00389 for ; Tue, 6 Apr 2004 23:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB3qJ-00065Q-00 for rddp-web-archive@ietf.org; Tue, 06 Apr 2004 23:35:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2Zq-00078S-00 for rddp-web-archive@ietf.org; Tue, 06 Apr 2004 22:14:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB1yq-00014a-01 for rddp-web-archive@ietf.org; Tue, 06 Apr 2004 21:35:52 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB1ia-0006Wi-B3 for rddp-web-archive@ietf.org; Tue, 06 Apr 2004 21:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1iZ-0008Fk-NA; Tue, 06 Apr 2004 21:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1iC-0008D4-5N for rddp@optimus.ietf.org; Tue, 06 Apr 2004 21:18:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19470 for ; Tue, 6 Apr 2004 21:18:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB1i9-0007Js-00 for rddp@ietf.org; Tue, 06 Apr 2004 21:18:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0ec-0001CU-00 for rddp@ietf.org; Tue, 06 Apr 2004 20:10:55 -0400 Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx with esmtp (Exim 4.12) id 1BB03g-00038L-00 for rddp@ietf.org; Tue, 06 Apr 2004 19:32:44 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i36NWDW26863; Tue, 6 Apr 2004 16:32:13 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i36NWD812407; Tue, 6 Apr 2004 16:32: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] MPA issue (3): Rejected Connection bit Date: Tue, 6 Apr 2004 16:32:09 -0700 Message-ID: <59C7D667A0EADB45866C62DD1B55A0FD01F0C58A@aime2k02.adaptec.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQV9bJghiqVMI0NQJmE0XOTCMVhDAGMvz3g From: "Carrier, John" To: , 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 guess I would like to hear a clarification for how the rejected bit = would be used. =20 In the startup scenarios described in the MPA draft, when the MPA = Responder sends the MPA Reply Frame, the responder 'binds' DDP to MPA so = that, after sending the reply frame, the MPA Responder will be ready to = receive FPDUs and pass them to DDP. If the Request Frame is invalid or = if the private data is unacceptable, then the ULP should close the = connection without sending a Reply Frame. =20 Adding the rejected bit enables the ULP to send a Reply Frame without = binding DDP to MPA. The Reply Frame may also contain private data that = further describes why the request was rejected. =20 If that is the intent, then what should the state of MPA be after = sending the Reply Frame with the rejected bit set? Does it return to = 'responder mode' so that the Initiator can resend the MPA Request Frame = or does it transition to a new state where it drops any received data = while it waits for the ULP to close the connection? If this has already been discussed on the list, please point me to the = thread. thanks. --jc John Carrier Adaptec > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > Black_David@emc.com > Sent: Monday, March 29, 2004 5:21 PM > To: rddp@ietf.org > Subject: [rddp] MPA issue (3): Rejected Connection bit >=20 >=20 > Moving on to issue (3), the Seoul minutes say: >=20 > (3) Rejected Connection bit. Dissension expressed, this leads to=20 > interoperability issues because it forces a ULP to=20 > interpret private=20 > data to figure out that the connection setup failed, and requires > MPA to handle TCP close specially (more detail in mail to list). > Further discussion:=20 >=20 > Q: If MPA does not do "teardown", why is the bit needed to=20 > free resources at MPA layer?=20 > A: Practically speaking, implementations will allocate and free=20 > resources in MPA (e.g. connection model in kernel), this enables=20 > layering and better control.=20 > A: The bit will prevent some timed-wait resource consumption issues, > if used properly (this is about cooperating systems, not malicious > resource consumption attacks). >=20 > Rough consensus in room to include the bit. Take to list. >=20 > I suggest to the WG that the right thing to do is include this bit > because it produces better behavior in an important error case for > cooperative clients where something is misconfigured. This bit > allows the RDDP layers to immediately know that a connection setup > has failed and release/reuse any resources committed to it without > waiting for a ULP to look at the private data that came back. It > also ties the fact that the connection is closing with the > associated private data unambiguously (both can be immediately > logged at RDDP level). Yes, this is optimizing an error case, > but it seems to be common enough/of sufficient concern to be > worth spending a bit on. That was where the discussion among > the subset of us who were in Seoul wound up. >=20 > Comments? I intend to let the technical discussion run on this > before trying to call consensus on the list. >=20 > Thanks, > --David >=20 > ---------------------------------------------------- > 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 > ---------------------------------------------------- >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 7 06:05:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04390 for ; Wed, 7 Apr 2004 06:05:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB9vZ-0002iX-3Q for rddp-archive@odin.ietf.org; Wed, 07 Apr 2004 06:05:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37A518o010446 for rddp-archive@odin.ietf.org; Wed, 7 Apr 2004 06:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB9vY-0002iP-Np for rddp-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 06:05:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04317 for ; Wed, 7 Apr 2004 06:04:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB9vV-0005no-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 06:04:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB8xo-000667-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 05:03:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BB7vh-0005WY-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 03:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB7vj-0004Q0-2E; Wed, 07 Apr 2004 03:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB7vd-0004Os-Kx for rddp@optimus.ietf.org; Wed, 07 Apr 2004 03:56:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21934 for ; Wed, 7 Apr 2004 03:56:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB7vb-0005VF-00 for rddp@ietf.org; Wed, 07 Apr 2004 03:56:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB6eK-0004VE-00 for rddp@ietf.org; Wed, 07 Apr 2004 02:35:01 -0400 Received: from host51a.simplicato.com ([207.99.47.51]) by ietf-mx with smtp (Exim 4.12) id 1BB5gY-0003qp-00 for rddp@ietf.org; Wed, 07 Apr 2004 01:33:14 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host51a.simplicato.com (Postfix) with ESMTP id F21D4430DC5; Wed, 7 Apr 2004 01:33:14 -0400 (EDT) Received: from host51a.simplicato.com ([127.0.0.1]) by localhost (host51a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 32316-03; Wed, 7 Apr 2004 01:33:13 -0400 (EDT) Received: by host51a.simplicato.com (Postfix, from userid 15001) id B51CC430DA6; Wed, 7 Apr 2004 01:33:13 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host51a.simplicato.com (Postfix) with SMTP id C86A7430D31; Wed, 7 Apr 2004 01:33:12 -0400 (EDT) Received: from 82.166.131.196 (proxying for 82.166.131.196) (SquirrelMail authenticated user cait@asomi.com) by mail51a.simplicato.com with HTTP; Wed, 7 Apr 2004 00:33:12 -0500 (CDT) Message-ID: <22625.82.166.131.196.1081315992.squirrel@mail51a.simplicato.com> In-Reply-To: <59C7D667A0EADB45866C62DD1B55A0FD01F0C58A@aime2k02.adaptec.com> References: <59C7D667A0EADB45866C62DD1B55A0FD01F0C58A@aime2k02.adaptec.com> Date: Wed, 7 Apr 2004 00:33:12 -0500 (CDT) Subject: RE: [rddp] MPA issue (3): Rejected Connection bit From: "Caitlin Bestler" To: rddp@ietf.org, "Carrier, John" Cc: black_david@emc.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at simplicato.com 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.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Carrier, John said: > I guess I would like to hear a clarification for how the rejected bit > would be used. > > In the startup scenarios described in the MPA draft, when the MPA > Responder sends the MPA Reply Frame, the responder 'binds' DDP to MPA s= o > that, after sending the reply frame, the MPA Responder will be ready to > receive FPDUs and pass them to DDP. If the Request Frame is invalid or= if > the private data is unacceptable, then the ULP should close the connect= ion > without sending a Reply Frame. > > Adding the rejected bit enables the ULP to send a Reply Frame without > binding DDP to MPA. The Reply Frame may also contain private data that > further describes why the request was rejected. > Exactly. The typical use is when the private data sent by the active side was unacceptable to the passive side, or for some other ULP reason the connection is not to proceed further. This capability is assumed by RDMA-aware APIs such as uDAPL and IT-API. Without this capability they must simulate the rejection bit by sending options that they know will be rejected. An "honest" reject bit is a far cleaner solution. > > If that is the intent, then what should the state of MPA be after sendi= ng > the Reply Frame with the rejected bit set? Does it return to 'responde= r > mode' so that the Initiator can resend the MPA Request Frame or does it > transition to a new state where it drops any received data while it wai= ts > for the ULP to close the connection? > To be technically precise, it means that the TCP connection does not enter the MPA state. What, if anything, happens to the TCP connection after that might not be in scope (unless someone has a strong reason why something should be specified). For both uDAPL and IT-API (so far) the connection should be torn down. But in those contexts the LLP connection was created "under the covers" by the API layer for the purpose of supporting an Endpoint. There will likely be API extensions that expose the LLP connection, allowing the applicication to request that this TCP connection be used to initiate an MPA connection for this endpoint. In that case I suppose it would be slightly preferable for a failure to leave the TCP connection intact in case the application wishes to continue in non-MPA mode. But if we were to decide that the reject bit mandated a TCP disconnect, there would be numerous methods available to an "optional RDMA:" application to determine the mode that will succeed *before* sending MPA Start frames. The intent of the bit is to optimize the large class of applications that know they will be using RDMA from the start, and wish to engage in a simple negotiation before proceeding or terminating the connection. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 7 17:19:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07719 for ; Wed, 7 Apr 2004 17:19:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBKRR-0005q2-Sa for rddp-archive@odin.ietf.org; Wed, 07 Apr 2004 17:18:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37LIbSV022443 for rddp-archive@odin.ietf.org; Wed, 7 Apr 2004 17:18:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBKRR-0005pu-LZ for rddp-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 17:18:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07591 for ; Wed, 7 Apr 2004 17:18:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBKRP-0005VH-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 17:18:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBIhG-0000mD-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 15:26:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBHJL-00061r-01 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 13:58:03 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBH2Z-00045F-AX for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 13:40:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH23-0003BD-Bn; Wed, 07 Apr 2004 13:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGRj-00060X-Aa for rddp@optimus.ietf.org; Wed, 07 Apr 2004 13:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10512 for ; Wed, 7 Apr 2004 12:58:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGNh-0004P1-00 for rddp@ietf.org; Wed, 07 Apr 2004 12:58:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBEuZ-0001yd-00 for rddp@ietf.org; Wed, 07 Apr 2004 11:24:21 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1BBDuJ-0002vG-00 for rddp@ietf.org; Wed, 07 Apr 2004 10:19:59 -0400 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i37EJSZh020291 for ; Wed, 7 Apr 2004 07:19:28 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i37EJSTR010221 for ; Wed, 7 Apr 2004 07:19:28 -0700 (PDT) Received: from tmt.netapp.com ([10.97.6.30]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 7 Apr 2004 10:19:23 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41CAB.52F52780" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: Re: [rddp] MPA issue (3): Rejected Connection bit Date: Wed, 7 Apr 2004 07:18:54 -0700 Message-ID: <6.0.3.0.2.20040403091231.01dcb150@silver.nane.netapp.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQcq1OUEUU8tGIUST+dNiJ+P0btzA== From: "Talpey, Thomas" To: 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41CAB.52F52780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 08:21 PM 3/29/2004, Black_David@emc.com wrote: >I suggest to the WG that the right thing to do is include this bit >because it produces better behavior in an important error case for >cooperative clients where something is misconfigured. This bit >allows the RDDP layers to immediately know that a connection setup >has failed and release/reuse any resources committed to it without >waiting for a ULP to look at the private data that came back. It >also ties the fact that the connection is closing with the >associated private data unambiguously (both can be immediately >logged at RDDP level). Yes, this is optimizing an error case, >but it seems to be common enough/of sufficient concern to be >worth spending a bit on. I agree with this, and would add that by not having the bit, RDDP violates layering requirements on TCP regarding the FIN. In order to unambiguously indicate "reject" to the RDDP peer, the TCP FIN must accompany the returned private data. Otherwise, the initiating peer must wait for a subsequent close. Also, with the bit, the connection may remain open for further operation in streaming mode, if desired. Here is some proposed text around the reject bit. The Reject bit provides a means for the responding MPA peer to reject an incoming RDDP connection. When an incoming connection is unacceptable to the responding peer, the Reject bit MUST be set in the reply, along with any ULP-specific private data. When the Reject bit is true, the connection remains in stream (TCP) mode, and may be used and/or subsequently closed by either peer. Additional justifications: Enhances interoperability by not leaving reject to the upper layer. This permits ULP-independent rejection, and does not require ULP private data manipulation. Simple, non-complicated change to MPA (single bit). Does not require the receiver to wait for subsequent event, as current proposal does (the FIN). Allows receiver to clean up MPA resources immediately upon rejection, avoiding resource retention if connection not closed. Tom.=20 ------_=_NextPart_001_01C41CAB.52F52780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [rddp] MPA issue (3): Rejected Connection bit

At 08:21 PM 3/29/2004, Black_David@emc.com = wrote:
>I suggest to the WG that the right thing to do is = include this bit
>because it produces better behavior in an = important error case for
>cooperative clients where something is = misconfigured.  This bit
>allows the RDDP layers to immediately know that a = connection setup
>has failed and release/reuse any resources = committed to it without
>waiting for a ULP to look at the private data = that came back.  It
>also ties the fact that the connection is closing = with the
>associated private data unambiguously (both can = be immediately
>logged at RDDP level).  Yes, this is = optimizing an error case,
>but it seems to be common enough/of sufficient = concern to be
>worth spending a bit on.

I agree with this, and would add that by not having = the bit, RDDP
violates layering requirements on TCP regarding the = FIN. In order
to unambiguously indicate "reject" to the = RDDP peer, the TCP FIN
must accompany the returned private data. Otherwise, = the
initiating peer must wait for a subsequent close. = Also, with the
bit, the connection may remain open for further = operation in
streaming mode, if desired.

Here is some proposed text around the reject = bit.

The Reject bit provides a means for the responding MPA = peer to
reject an incoming RDDP connection. When an incoming = connection
is unacceptable to the responding peer, the Reject = bit MUST be
set in the reply, along with any ULP-specific private = data. When
the Reject bit is true, the connection remains in = stream (TCP) mode,
and may be used and/or subsequently closed by either = peer.

Additional justifications:

Enhances interoperability by not leaving reject to the = upper
layer. This permits ULP-independent rejection, and = does not
require ULP private data manipulation.

Simple, non-complicated change to MPA (single = bit).

Does not require the receiver to wait for subsequent = event,
as current proposal does (the FIN).

Allows receiver to clean up MPA resources = immediately
upon rejection, avoiding resource retention if = connection
not closed.

Tom.

------_=_NextPart_001_01C41CAB.52F52780-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 7 17:24:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08768 for ; Wed, 7 Apr 2004 17:24:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBKWW-0008BF-Ol for rddp-archive@odin.ietf.org; Wed, 07 Apr 2004 17:23:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37LNq4e031441 for rddp-archive@odin.ietf.org; Wed, 7 Apr 2004 17:23:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBKWV-0008B2-PI for rddp-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 17:23:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08672 for ; Wed, 7 Apr 2004 17:23:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBKWT-0006Ny-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 17:23:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBIrZ-0001i0-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 15:37:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBHLh-0006dq-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 14:00:30 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBHIB-0007Fv-J0 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 13:56:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHFa-0002y6-CK; Wed, 07 Apr 2004 13:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHF4-0002pT-2n for rddp@optimus.ietf.org; Wed, 07 Apr 2004 13:53:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19355 for ; Wed, 7 Apr 2004 13:53:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHF1-0005KS-00 for rddp@ietf.org; Wed, 07 Apr 2004 13:53:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGNr-0004Qd-00 for rddp@ietf.org; Wed, 07 Apr 2004 12:58:40 -0400 Received: from zcamail03.zca.compaq.com ([161.114.32.103]) by ietf-mx with esmtp (Exim 4.12) id 1BBEuu-0001wq-00 for rddp@ietf.org; Wed, 07 Apr 2004 11:24:40 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.46]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id F3916AC00; Wed, 7 Apr 2004 08:24:09 -0700 (PDT) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.21]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 08:24:09 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6529.0 Subject: RE: [rddp] MPA issue (3): Rejected Connection bit Date: Wed, 7 Apr 2004 10:24:08 -0500 Message-ID: <717252EC3E37AE4392E2614EA24E9F2B07FDEAA6@txnexc01.americas.cpqcorp.net> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQcdfYIP0IQRxLAQvKW1u1+aFIBLwAPPuKw From: "Teisberg, Robert" To: "Caitlin Bestler" , , "Carrier, John" Cc: X-OriginalArrivalTime: 07 Apr 2004 15:24:09.0959 (UTC) FILETIME=[5FC40770:01C41CB4] 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 Caitlin Bestler wrote: >=20 > The typical use is when the private data sent by the active=20 > side was unacceptable to the passive side, or for some other=20 > ULP reason the connection is not to proceed further. >=20 > This capability is assumed by RDMA-aware APIs such as uDAPL=20 > and IT-API. Without this capability they must simulate the=20 > rejection bit by sending options that they know will be=20 > rejected. An "honest" reject bit is a far cleaner solution. >=20 "Must" is a little strong. An alternative is to silently drop the connection. The API will report this as "connection lost" or "connection reset" or something equally mysterious. This is hardly ideal but not totally unworkable. Bob _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 7 18:10:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16110 for ; Wed, 7 Apr 2004 18:10:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLFR-0002PY-0J for rddp-archive@odin.ietf.org; Wed, 07 Apr 2004 18:10:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37MAGL2009258 for rddp-archive@odin.ietf.org; Wed, 7 Apr 2004 18:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLFQ-0002Oy-Kr for rddp-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 18:10:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16000 for ; Wed, 7 Apr 2004 18:10:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBLFN-0005br-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 18:10:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBK8J-0002Js-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 16:58:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBICf-0005pY-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 14:55:13 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBI8o-0004Gi-BD for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 14:51:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBI6k-0004KE-4b; Wed, 07 Apr 2004 14:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBI5z-00049F-LT for rddp@optimus.ietf.org; Wed, 07 Apr 2004 14:48:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26296 for ; Wed, 7 Apr 2004 14:48:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBI5v-0005BR-00 for rddp@ietf.org; Wed, 07 Apr 2004 14:48:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBHEr-0005IQ-00 for rddp@ietf.org; Wed, 07 Apr 2004 13:53:26 -0400 Received: from enigma.barak.net.il ([212.150.48.101]) by ietf-mx with esmtp (Exim 4.12) id 1BBGNU-0004Jp-00 for rddp@ietf.org; Wed, 07 Apr 2004 12:58:16 -0400 Received: from [192.168.122.53] ([82.166.6.94]) by enigma.barak.net.il (InterMail vK.4.04.00.00 201-232-137 license e5bc39f1001e7dfa47fa92d56cd12779) with ESMTP id <20040407165717.CNYR10439.enigma@[82.166.6.94]>; Wed, 7 Apr 2004 19:57:17 +0300 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B07FDEAA6@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B07FDEAA6@txnexc01.americas.cpqcorp.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] MPA issue (3): Rejected Connection bit Date: Wed, 7 Apr 2004 19:57:36 +0300 To: "Teisberg, Robert" , RDDP X-Mailer: Apple Mail (2.613) 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Apr 7, 2004, at 6:24 PM, Teisberg, Robert wrote: > Caitlin Bestler wrote: > >> >> The typical use is when the private data sent by the active >> side was unacceptable to the passive side, or for some other >> ULP reason the connection is not to proceed further. >> >> This capability is assumed by RDMA-aware APIs such as uDAPL >> and IT-API. Without this capability they must simulate the >> rejection bit by sending options that they know will be >> rejected. An "honest" reject bit is a far cleaner solution. >> > > "Must" is a little strong. An alternative is to silently > drop the connection. The API will report this as "connection > lost" or "connection reset" or something equally mysterious. > This is hardly ideal but not totally unworkable. > > The APIs make a distinction between a connection request refused by the peer and those that failed for other reasons. This is an important distinction. If a connection failed for "other" (non-peer) reasons, the chance of another session request being honored is very low -- but the chance that the same session will be accepted at some later time is good. If the connection was rejected by the peer, the opposite is true. Generally the applications themselves do not care about exactly what network error killed the connection, but there is a very big difference between "cannot communicate with X" and "X does not want to talk with you." _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 7 20:44:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24300 for ; Wed, 7 Apr 2004 20:44:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNe0-0000E0-9T for rddp-archive@odin.ietf.org; Wed, 07 Apr 2004 20:43:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i380hmjE000851 for rddp-archive@odin.ietf.org; Wed, 7 Apr 2004 20:43:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNdz-0000C0-V4 for rddp-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 20:43:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24096 for ; Wed, 7 Apr 2004 20:43:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBNdx-0004q3-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 20:43:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBLSE-000715-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 18:23:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBKEB-0002v2-02 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 17:04:55 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBK4g-0003MM-W2 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 16:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK4g-0004Fz-1s; Wed, 07 Apr 2004 16:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK4N-00049Q-B3 for rddp@optimus.ietf.org; Wed, 07 Apr 2004 16:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03332 for ; Wed, 7 Apr 2004 16:54:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBK4L-0001cO-00 for rddp@ietf.org; Wed, 07 Apr 2004 16:54:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBI45-0004pO-00 for rddp@ietf.org; Wed, 07 Apr 2004 14:46:24 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1BBH9O-0004DI-00 for rddp@ietf.org; Wed, 07 Apr 2004 13:47:46 -0400 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i37HlFZh029374; Wed, 7 Apr 2004 10:47:15 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i37HlEbe006760; Wed, 7 Apr 2004 10:47:15 -0700 (PDT) Received: from tmt.netapp.com ([10.97.6.30]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 7 Apr 2004 13:46:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41CC8.3FA48500" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [rddp] MPA issue (3): Rejected Connection bit Date: Wed, 7 Apr 2004 10:46:00 -0700 Message-ID: <6.1.0.6.2.20040407111131.01e7dec0@silver.nane.netapp.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQcyD/mUPpG8JKYRTetg6xomalEjw== From: "Talpey, Thomas" To: "Carrier, John" Cc: 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41CC8.3FA48500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In my view, the state of the connection after an MPA reject is up the responding ULP (i.e. the one that rejected). The connection, initially, remains in TCP streaming mode. The ULP consumer may opt to close the connection, return the connection to MPA responder mode (before consuming any TCP stream data), or simply remain in TCP. The decision is not MPA's, nor should it be. Tom. At 07:32 PM 4/6/2004, Carrier, John wrote: >I guess I would like to hear a clarification for how the rejected bit = would=20 >be used. =20 > >In the startup scenarios described in the MPA draft, when the MPA = Responder=20 >sends the MPA Reply Frame, the responder 'binds' DDP to MPA so that, = after=20 >sending the reply frame, the MPA Responder will be ready to receive = FPDUs=20 >and pass them to DDP. If the Request Frame is invalid or if the = private=20 >data is unacceptable, then the ULP should close the connection without=20 >sending a Reply Frame. =20 > >Adding the rejected bit enables the ULP to send a Reply Frame without=20 >binding DDP to MPA. The Reply Frame may also contain private data that = >further describes why the request was rejected. =20 > >If that is the intent, then what should the state of MPA be after = sending=20 >the Reply Frame with the rejected bit set? Does it return to = 'responder=20 >mode' so that the Initiator can resend the MPA Request Frame or does it = >transition to a new state where it drops any received data while it = waits=20 >for the ULP to close the connection? > >If this has already been discussed on the list, please point me to the = thread. > >thanks. > >--jc > > >John Carrier >Adaptec > >> -----Original Message----- >> From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of >> Black_David@emc.com >> Sent: Monday, March 29, 2004 5:21 PM >> To: rddp@ietf.org >> Subject: [rddp] MPA issue (3): Rejected Connection bit >>=20 >>=20 >> Moving on to issue (3), the Seoul minutes say: >>=20 >> (3) Rejected Connection bit. Dissension expressed, this leads to=20 >> interoperability issues because it forces a ULP to=20 >> interpret private=20 >> data to figure out that the connection setup failed, and requires >> MPA to handle TCP close specially (more detail in mail to list). >> Further discussion:=20 >>=20 >> Q: If MPA does not do "teardown", why is the bit needed to=20 >> free resources at MPA layer?=20 >> A: Practically speaking, implementations will allocate and free=20 >> resources in MPA (e.g. connection model in kernel), this enables=20 >> layering and better control.=20 >> A: The bit will prevent some timed-wait resource consumption = issues, >> if used properly (this is about cooperating systems, not malicious >> resource consumption attacks). >>=20 >> Rough consensus in room to include the bit. Take to list. >>=20 >> I suggest to the WG that the right thing to do is include this bit >> because it produces better behavior in an important error case for >> cooperative clients where something is misconfigured. This bit >> allows the RDDP layers to immediately know that a connection setup >> has failed and release/reuse any resources committed to it without >> waiting for a ULP to look at the private data that came back. It >> also ties the fact that the connection is closing with the >> associated private data unambiguously (both can be immediately >> logged at RDDP level). Yes, this is optimizing an error case, >> but it seems to be common enough/of sufficient concern to be >> worth spending a bit on. That was where the discussion among >> the subset of us who were in Seoul wound up. >>=20 >> Comments? I intend to let the technical discussion run on this >> before trying to call consensus on the list. >>=20 >> Thanks, >> --David >>=20 >> ---------------------------------------------------- >> 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 >> ---------------------------------------------------- >>=20 >>=20 >> _______________________________________________ >> rddp mailing list >> rddp@ietf.org >> https://www1.ietf.org/mailman/listinfo/rddp >>=20 > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp ------_=_NextPart_001_01C41CC8.3FA48500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rddp] MPA issue (3): Rejected Connection bit

In my view, the state of the connection after an MPA = reject is
up the responding ULP (i.e. the one that = rejected).

The connection, initially, remains in TCP streaming = mode. The ULP
consumer may opt to close the connection, return the = connection
to MPA responder mode (before consuming any TCP = stream data),
or simply remain in TCP. The decision is not MPA's, = nor should it be.

Tom.

At 07:32 PM 4/6/2004, Carrier, John wrote:
>I guess I would like to hear a clarification for = how the rejected bit would
>be used. 
>
>In the startup scenarios described in the MPA = draft, when the MPA Responder
>sends the MPA Reply Frame, the responder 'binds' = DDP to MPA so that, after
>sending the reply frame, the MPA Responder will = be ready to receive FPDUs
>and pass them to DDP.  If the Request Frame = is invalid or if the private
>data is unacceptable, then the ULP should close = the connection without
>sending a Reply Frame. 
>
>Adding the rejected bit enables the ULP to send a = Reply Frame without
>binding DDP to MPA.  The Reply Frame may = also contain private data that
>further describes why the request was = rejected.  
>
>If that is the intent, then what should the state = of MPA be after sending
>the Reply Frame with the rejected bit set?  = Does it return to 'responder
>mode' so that the Initiator can resend the MPA = Request Frame or does it
>transition to a new state where it drops any = received data while it waits
>for the ULP to close the connection?
>
>If this has already been discussed on the list, = please point me to the thread.
>
>thanks.
>
>--jc
>
>
>John Carrier
>Adaptec
>
>> -----Original Message-----
>> From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On = Behalf Of
>> Black_David@emc.com
>> Sent: Monday, March 29, 2004 5:21 PM
>> To: rddp@ietf.org
>> Subject: [rddp] MPA issue (3): Rejected = Connection bit
>>
>>
>> Moving on to issue (3), the Seoul minutes = say:
>>
>>   (3) Rejected Connection bit. = Dissension expressed, this leads to
>>   interoperability issues because = it forces a ULP to
>> interpret private
>>   data to figure out that the = connection setup failed, and requires
>>   MPA to handle TCP close = specially (more detail in mail to list).
>>   Further discussion:
>>
>>   Q: If MPA does not do = "teardown", why is the bit needed to
>>    free resources at MPA = layer?
>>   A: Practically speaking, = implementations will allocate and free
>>    resources in MPA (e.g. = connection model in kernel), this enables
>>    layering and better = control.
>>   A: The bit will prevent some = timed-wait resource consumption issues,
>>    if used properly (this is = about cooperating systems, not malicious
>>    resource consumption = attacks).
>>
>>   Rough consensus in room to = include the bit. Take to list.
>>
>> I suggest to the WG that the right thing to = do is include this bit
>> because it produces better behavior in an = important error case for
>> cooperative clients where something is = misconfigured.  This bit
>> allows the RDDP layers to immediately know = that a connection setup
>> has failed and release/reuse any resources = committed to it without
>> waiting for a ULP to look at the private = data that came back.  It
>> also ties the fact that the connection is = closing with the
>> associated private data unambiguously (both = can be immediately
>> logged at RDDP level).  Yes, this is = optimizing an error case,
>> but it seems to be common enough/of = sufficient concern to be
>> worth spending a bit on.  That was = where the discussion among
>> the subset of us who were in Seoul wound = up.
>>
>> Comments?  I intend to let the = technical discussion run on this
>> before trying to call consensus on the = list.
>>
>> Thanks,
>> --David
>>
>> = ----------------------------------------------------
>> David L. Black, Senior Technologist
>> EMC Corporation, 176 South St., Hopkinton, = MA  01748
>> +1 (508) = 293-7953           = ;  FAX: +1 (508) 293-7786
>> = black_david@emc.com        Mobile: +1 = (978) 394-7754
>> = ----------------------------------------------------
>>
>>
>> = _______________________________________________
>> rddp mailing list
>> rddp@ietf.org
>> https://www1.ietf.or= g/mailman/listinfo/rddp
>>
>
>_______________________________________________
>rddp mailing list
>rddp@ietf.org
>https://www1.ietf.or= g/mailman/listinfo/rddp

------_=_NextPart_001_01C41CC8.3FA48500-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 7 20:44:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24345 for ; Wed, 7 Apr 2004 20:44:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNe4-0000Qt-FV for rddp-archive@odin.ietf.org; Wed, 07 Apr 2004 20:43:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i380hqaw001658 for rddp-archive@odin.ietf.org; Wed, 7 Apr 2004 20:43:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNe4-0000Qb-7K for rddp-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 20:43:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24117 for ; Wed, 7 Apr 2004 20:43:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBNe1-0004qs-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 20:43:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBLSM-000725-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 18:23:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBKEC-0002v2-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 17:04:56 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBK4e-0003Ly-3P for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 16:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK4d-0004D1-IO; Wed, 07 Apr 2004 16:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK4C-00048v-J9 for rddp@optimus.ietf.org; Wed, 07 Apr 2004 16:54:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03307 for ; Wed, 7 Apr 2004 16:54:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBK4A-0001aD-00 for rddp@ietf.org; Wed, 07 Apr 2004 16:54:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBI38-0004eB-00 for rddp@ietf.org; Wed, 07 Apr 2004 14:45:23 -0400 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 1BBH6x-0003mu-00 for rddp@ietf.org; Wed, 07 Apr 2004 13:45:15 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.46]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id C00B651FE; Wed, 7 Apr 2004 10:44:44 -0700 (PDT) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.21]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 10:44:44 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6529.0 Subject: RE: [rddp] MPA issue (3): Rejected Connection bit Date: Wed, 7 Apr 2004 12:44:43 -0500 Message-ID: <717252EC3E37AE4392E2614EA24E9F2B07FDEB5D@txnexc01.americas.cpqcorp.net> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQcwYAZEjh4ZC8ARSaNN12UhLBs8AABRRdw From: "Teisberg, Robert" To: "Caitlin Bestler" , "RDDP" X-OriginalArrivalTime: 07 Apr 2004 17:44:44.0413 (UTC) FILETIME=[031792D0:01C41CC8] 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 >=20 > The APIs make a distinction between a connection request > refused by the peer and those that failed for other reasons. There is room for disagreement whether APIs should conform to protocols or protocols to APIs. That's why I'm unconvinced by citing the authority of API specs. Especially in light of your other argument.... > This is an important distinction. If a connection failed for > "other" (non-peer) reasons, the chance of another session > request being honored is very low -- but the chance that the > same session will be accepted at some later time is good. >=20 > If the connection was rejected by the peer, the opposite > is true. >=20 > Generally the applications themselves do not care about > exactly what network error killed the connection, but there > is a very big difference between "cannot communicate > with X" and "X does not want to talk with you." >=20 >=20 I find this much more persuasive. That it keeps us out of the philosophical tarpit is a bonus. Bob=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 7 21:41:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04678 for ; Wed, 7 Apr 2004 21:41:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOXU-0006c0-7W for rddp-archive@odin.ietf.org; Wed, 07 Apr 2004 21:41:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i381f8Zn025408 for rddp-archive@odin.ietf.org; Wed, 7 Apr 2004 21:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOXU-0006bV-0h for rddp-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 21:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04559 for ; Wed, 7 Apr 2004 21:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOXR-0006SZ-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 21:41:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNBY-0001Bx-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 20:14:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBKuo-0002tA-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 17:48:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBKuq-00022h-Gk; Wed, 07 Apr 2004 17:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBKtw-0001UX-BJ for rddp@optimus.ietf.org; Wed, 07 Apr 2004 17:48:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13385 for ; Wed, 7 Apr 2004 17:48:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBKtt-0002lX-00 for rddp@ietf.org; Wed, 07 Apr 2004 17:48:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBJiD-0006R7-00 for rddp@ietf.org; Wed, 07 Apr 2004 16:31:58 -0400 Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx with esmtp (Exim 4.12) id 1BBHf5-0001g8-00 for rddp@ietf.org; Wed, 07 Apr 2004 14:20:31 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i37IK0W19051 for ; Wed, 7 Apr 2004 11:20:00 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i37IK0819322 for ; Wed, 7 Apr 2004 11:20:00 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41CCC.F07E01C0" Subject: RE: [rddp] MPA issue (3): Rejected Connection bit Date: Wed, 7 Apr 2004 11:20:00 -0700 Message-ID: <59C7D667A0EADB45866C62DD1B55A0FD01F0C63D@aime2k02.adaptec.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQcyD/mUPpG8JKYRTetg6xomalEjwAA6tBw From: "Carrier, John" To: 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,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41CCC.F07E01C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll follow up to the email I just sent with the 'state machine' = perspective.=20 =20 I think we need to specify what happens after MPA sends the Reply Frame = with the reject bit set. As I proposed, MPA is 'inactive' but the TCP = connection is still open. We could just as easily say that MPA = transitions into 'responder mode' again. =20 =20 In either case, we need to specify whether MPA is still consuming the = TCP data stream after sending the Reply Frame with the reject bit set. = Doing so in no way affects the ULP's control of the connection, but I = think makes clear what the ULP can expect from its LLP. =20 =20 --jc -----Original Message----- From: Talpey, Thomas [mailto:Thomas.Talpey@netapp.com] Sent: Wednesday, April 07, 2004 10:46 AM To: Carrier, John Cc: rddp@ietf.org Subject: RE: [rddp] MPA issue (3): Rejected Connection bit In my view, the state of the connection after an MPA reject is=20 up the responding ULP (i.e. the one that rejected).=20 The connection, initially, remains in TCP streaming mode. The ULP=20 consumer may opt to close the connection, return the connection=20 to MPA responder mode (before consuming any TCP stream data),=20 or simply remain in TCP. The decision is not MPA's, nor should it be.=20 Tom.=20 At 07:32 PM 4/6/2004, Carrier, John wrote:=20 >I guess I would like to hear a clarification for how the rejected bit = would=20 >be used. =20 >=20 >In the startup scenarios described in the MPA draft, when the MPA = Responder=20 >sends the MPA Reply Frame, the responder 'binds' DDP to MPA so that, = after=20 >sending the reply frame, the MPA Responder will be ready to receive = FPDUs=20 >and pass them to DDP. If the Request Frame is invalid or if the = private=20 >data is unacceptable, then the ULP should close the connection without=20 >sending a Reply Frame. =20 >=20 >Adding the rejected bit enables the ULP to send a Reply Frame without=20 >binding DDP to MPA. The Reply Frame may also contain private data that = >further describes why the request was rejected. =20 >=20 >If that is the intent, then what should the state of MPA be after = sending=20 >the Reply Frame with the rejected bit set? Does it return to = 'responder=20 >mode' so that the Initiator can resend the MPA Request Frame or does it = >transition to a new state where it drops any received data while it = waits=20 >for the ULP to close the connection?=20 >=20 >If this has already been discussed on the list, please point me to the = thread.=20 >=20 >thanks.=20 >=20 >--jc=20 >=20 >=20 >John Carrier=20 >Adaptec=20 >=20 >> -----Original Message-----=20 >> From: rddp-admin@ietf.org [ mailto:rddp-admin@ietf.org]On Behalf Of=20 >> Black_David@emc.com=20 >> Sent: Monday, March 29, 2004 5:21 PM=20 >> To: rddp@ietf.org=20 >> Subject: [rddp] MPA issue (3): Rejected Connection bit=20 >>=20 >>=20 >> Moving on to issue (3), the Seoul minutes say:=20 >>=20 >> (3) Rejected Connection bit. Dissension expressed, this leads to=20 >> interoperability issues because it forces a ULP to=20 >> interpret private=20 >> data to figure out that the connection setup failed, and requires=20 >> MPA to handle TCP close specially (more detail in mail to list).=20 >> Further discussion:=20 >>=20 >> Q: If MPA does not do "teardown", why is the bit needed to=20 >> free resources at MPA layer?=20 >> A: Practically speaking, implementations will allocate and free=20 >> resources in MPA (e.g. connection model in kernel), this enables=20 >> layering and better control.=20 >> A: The bit will prevent some timed-wait resource consumption = issues,=20 >> if used properly (this is about cooperating systems, not malicious = >> resource consumption attacks).=20 >>=20 >> Rough consensus in room to include the bit. Take to list.=20 >>=20 >> I suggest to the WG that the right thing to do is include this bit=20 >> because it produces better behavior in an important error case for=20 >> cooperative clients where something is misconfigured. This bit=20 >> allows the RDDP layers to immediately know that a connection setup=20 >> has failed and release/reuse any resources committed to it without=20 >> waiting for a ULP to look at the private data that came back. It=20 >> also ties the fact that the connection is closing with the=20 >> associated private data unambiguously (both can be immediately=20 >> logged at RDDP level). Yes, this is optimizing an error case,=20 >> but it seems to be common enough/of sufficient concern to be=20 >> worth spending a bit on. That was where the discussion among=20 >> the subset of us who were in Seoul wound up.=20 >>=20 >> Comments? I intend to let the technical discussion run on this=20 >> before trying to call consensus on the list.=20 >>=20 >> Thanks,=20 >> --David=20 >>=20 >> ----------------------------------------------------=20 >> David L. Black, Senior Technologist=20 >> EMC Corporation, 176 South St., Hopkinton, MA 01748=20 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 >> black_david@emc.com Mobile: +1 (978) 394-7754=20 >> ----------------------------------------------------=20 >>=20 >>=20 >> _______________________________________________=20 >> rddp mailing list=20 >> rddp@ietf.org=20 >> https://www1.ietf.org/mailman/listinfo/rddp=20 >>=20 >=20 >_______________________________________________=20 >rddp mailing list=20 >rddp@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/rddp=20 ------_=_NextPart_001_01C41CCC.F07E01C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rddp] MPA issue (3): Rejected Connection bit
I'll follow up to the email I just sent with the 'state = machine'=20 perspective.
 
I think we need to specify what happens after MPA sends the = Reply Frame=20 with the reject bit set.  As I proposed, MPA is 'inactive' but the = TCP=20 connection is still open.  We could just as easily say that MPA = transitions=20 into 'responder mode' again. 
 
In either case, we need to specify whether MPA is still = consuming=20 the TCP data stream after sending the Reply Frame with the reject bit = set. =20 Doing so in no way affects the ULP's control of the connection, but I = think=20 makes clear what the ULP can expect from its LLP.
 
 
--jc
-----Original Message-----
From: Talpey, Thomas=20 [mailto:Thomas.Talpey@netapp.com]
Sent: Wednesday, April 07, = 2004=20 10:46 AM
To: Carrier, John
Cc:=20 rddp@ietf.org
Subject: RE: [rddp] MPA issue (3): Rejected = Connection=20 bit

In my view, the state of the connection after an MPA = reject=20 is
up the responding ULP (i.e. the one that=20 rejected).

The connection, initially, remains in TCP streaming = mode. The=20 ULP
consumer may opt to close the = connection, return=20 the connection
to MPA responder mode (before = consuming=20 any TCP stream data),
or simply remain in = TCP. The=20 decision is not MPA's, nor should it be.

Tom.

At 07:32 PM 4/6/2004, Carrier, John wrote: =
>I guess I would like to hear a clarification for how the = rejected=20 bit would
>be used.  =
>
>In the startup scenarios = described in=20 the MPA draft, when the MPA Responder
>sends the=20 MPA Reply Frame, the responder 'binds' DDP to MPA so that, after=20
>sending the reply frame, the MPA = Responder will be=20 ready to receive FPDUs
>and pass them to = DDP. =20 If the Request Frame is invalid or if the private
>data is unacceptable, then the ULP should close the = connection=20 without
>sending a Reply Frame. =20
>
>Adding = the rejected=20 bit enables the ULP to send a Reply Frame without
>binding DDP to MPA.  The Reply Frame may also = contain private=20 data that
>further describes why the = request was=20 rejected.  
>
>If that is the intent, then what should the state of MPA = be after=20 sending
>the Reply Frame with the = rejected bit=20 set?  Does it return to 'responder
>mode' so=20 that the Initiator can resend the MPA Request Frame or does it=20
>transition to a new state where it drops = any=20 received data while it waits
>for the ULP = to close=20 the connection?
>
>If=20 this has already been discussed on the list, please point me to the=20 thread.
>
>thanks.
>
>--jc
>
>
>John Carrier =
>Adaptec
>
>> -----Original Message-----
>>=20 From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On = Behalf=20 Of
>> Black_David@emc.com =
>> Sent: Monday, March 29, 2004 5:21 PM =
>> To: rddp@ietf.org
>> = Subject:=20 [rddp] MPA issue (3): Rejected Connection bit
>>=20
>>
>> = Moving on to=20 issue (3), the Seoul minutes say:
>>=20
>>   (3) Rejected Connection = bit.=20 Dissension expressed, this leads to
>>   interoperability issues because it = forces a ULP to=20
>> interpret private
>>   data to figure out that the connection = setup=20 failed, and requires
>>   = MPA to=20 handle TCP close specially (more detail in mail to list). =
>>   Further discussion:
>>
>>   Q: If = MPA does=20 not do "teardown", why is the bit needed to
>>    free resources at MPA layer?=20
>>   A: Practically = speaking,=20 implementations will allocate and free
>>    resources in MPA (e.g. connection = model in=20 kernel), this enables
>>   =20 layering and better control.
>>   A:=20 The bit will prevent some timed-wait resource consumption = issues,=20
>>    if used properly (this = is about=20 cooperating systems, not malicious
>>    resource consumption = attacks).=20
>>
>>   Rough=20 consensus in room to include the bit. Take to list.
>>
>> I suggest to the = WG that the=20 right thing to do is include this bit
>> because=20 it produces better behavior in an important error case for =
>> cooperative clients where something is = misconfigured. =20 This bit
>> allows the RDDP layers to=20 immediately know that a connection setup
>> has=20 failed and release/reuse any resources committed to it without=20
>> waiting for a ULP to look at the private = data that=20 came back.  It
>> also ties the = fact that=20 the connection is closing with the
>> = associated=20 private data unambiguously (both can be immediately
>> logged at RDDP level).  Yes, this is optimizing = an error=20 case,
>> but it seems to be common = enough/of=20 sufficient concern to be
>> worth = spending a bit=20 on.  That was where the discussion among
>>=20 the subset of us who were in Seoul wound up.
>>=20
>> Comments?  I intend to let the = technical=20 discussion run on this
>> before = trying to call=20 consensus on the list.
>> =
>> Thanks,
>> = --David=20
>>
>>=20 ----------------------------------------------------
>> David L. Black, Senior Technologist
>> EMC Corporation, 176 South St., Hopkinton, MA =20 01748
>> +1 (508)=20 = 293-7953           = ; =20 FAX: +1 (508) 293-7786
>>=20 black_david@emc.com        Mobile: = +1 (978)=20 394-7754
>>=20 ----------------------------------------------------
>>
>>
>> = _______________________________________________=20
>> rddp mailing list
>>=20 rddp@ietf.org
>> https://www1.ietf.or= g/mailman/listinfo/rddp=20
>>
> =
>_______________________________________________ =
>rddp mailing list
>rddp@ietf.org=20
>https://www1.ietf.or= g/mailman/listinfo/rddp=20

------_=_NextPart_001_01C41CCC.F07E01C0-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 7 21:41:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04695 for ; Wed, 7 Apr 2004 21:41:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOXd-0006fg-Mb for rddp-archive@odin.ietf.org; Wed, 07 Apr 2004 21:41:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i381fH3o025642 for rddp-archive@odin.ietf.org; Wed, 7 Apr 2004 21:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOXd-0006fR-GH for rddp-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 21:41:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04593 for ; Wed, 7 Apr 2004 21:41:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOXa-0006U8-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 21:41:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNBq-0001Dg-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 20:14:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBKv0-0002vy-00 for rddp-web-archive@ietf.org; Wed, 07 Apr 2004 17:49:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBKr2-0000Zp-O4; Wed, 07 Apr 2004 17:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBKqe-0000PJ-6e for rddp@optimus.ietf.org; Wed, 07 Apr 2004 17:44:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12712 for ; Wed, 7 Apr 2004 17:44:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBKqb-0002F4-00 for rddp@ietf.org; Wed, 07 Apr 2004 17:44:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBJaR-0005Mn-00 for rddp@ietf.org; Wed, 07 Apr 2004 16:23:54 -0400 Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx with esmtp (Exim 4.12) id 1BBHTZ-0000Fz-00 for rddp@ietf.org; Wed, 07 Apr 2004 14:08:37 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i37I87W11517 for ; Wed, 7 Apr 2004 11:08:07 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i37I87812658 for ; Wed, 7 Apr 2004 11:08:07 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41CCB.4759B884" Subject: RE: [rddp] MPA issue (3): Rejected Connection bit Date: Wed, 7 Apr 2004 11:08:07 -0700 Message-ID: <59C7D667A0EADB45866C62DD1B55A0FD01F0C639@aime2k02.adaptec.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQcq1OUEUU8tGIUST+dNiJ+P0btzAAHFqSA From: "Carrier, John" To: 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41CCB.4759B884 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Okay, so let me take another shot at clarification: =20 The draft shows that MPA is in 'responder mode' while waiting for the = MPA Request Frame. Saying that the connection stays in 'TCP stream = mode' after sending the Reject Reply Frame is not a sufficient = description of the state change in MPA because it was in 'TCP stream = mode' while in 'responder mode'. =20 =20 So, from a state machine perspective: * the ULP at the responder puts MPA into 'responder mode' while it waits = for the Request Frame from the initiator. In this state, MPA consumes = the TCP data stream. * after the responding MPA receives an MPA Request Frame from the MPA = initiator, it transitions to a 'request received' state. In this state, = the connection is still in TCP stream mode, although MPA is not = expecting any other received data from the initiator (should there be an = error if it receives any?). MPA stays in this state until it receives = an indication from the ULP to reply to the initiator.=20 * if the Request Frame is valid and the ULP accepts the connection, MPA = will transition to 'MPA mode' after sending the Reply Frame with the = rejected bit set to 0. In this state, MPA at the responder is bound to = DDP and is waiting for the first FPDU from the initiator. 'Full MPA = mode', where the responder can send FPDUs, doesn't occur until after the = responder receives the first FPDU from the initiator. * if the Request Frame is invalid or if the ULP rejects the connection, = MPA will transition to an 'inactive' state after sending the Reply Frame = with the rejected bit set to 1. In this state, the TCP connection is = open, but MPA is no longer consuming any of the TCP data stream; instead = any received data goes directly to the ULP. =20 --jc =20 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of = Talpey, Thomas Sent: Wednesday, April 07, 2004 7:19 AM To: rddp@ietf.org Subject: Re: [rddp] MPA issue (3): Rejected Connection bit At 08:21 PM 3/29/2004, Black_David@emc.com wrote:=20 >I suggest to the WG that the right thing to do is include this bit=20 >because it produces better behavior in an important error case for=20 >cooperative clients where something is misconfigured. This bit=20 >allows the RDDP layers to immediately know that a connection setup=20 >has failed and release/reuse any resources committed to it without=20 >waiting for a ULP to look at the private data that came back. It=20 >also ties the fact that the connection is closing with the=20 >associated private data unambiguously (both can be immediately=20 >logged at RDDP level). Yes, this is optimizing an error case,=20 >but it seems to be common enough/of sufficient concern to be=20 >worth spending a bit on.=20 I agree with this, and would add that by not having the bit, RDDP=20 violates layering requirements on TCP regarding the FIN. In order=20 to unambiguously indicate "reject" to the RDDP peer, the TCP FIN=20 must accompany the returned private data. Otherwise, the=20 initiating peer must wait for a subsequent close. Also, with the=20 bit, the connection may remain open for further operation in=20 streaming mode, if desired.=20 Here is some proposed text around the reject bit.=20 The Reject bit provides a means for the responding MPA peer to=20 reject an incoming RDDP connection. When an incoming connection=20 is unacceptable to the responding peer, the Reject bit MUST be=20 set in the reply, along with any ULP-specific private data. When=20 the Reject bit is true, the connection remains in stream (TCP) mode,=20 and may be used and/or subsequently closed by either peer.=20 Additional justifications:=20 Enhances interoperability by not leaving reject to the upper=20 layer. This permits ULP-independent rejection, and does not=20 require ULP private data manipulation.=20 Simple, non-complicated change to MPA (single bit).=20 Does not require the receiver to wait for subsequent event,=20 as current proposal does (the FIN).=20 Allows receiver to clean up MPA resources immediately=20 upon rejection, avoiding resource retention if connection=20 not closed.=20 Tom.=20 ------_=_NextPart_001_01C41CCB.4759B884 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [rddp] MPA issue (3): Rejected Connection bit
Okay, so let me take another shot at = clarification:
 
The draft shows that MPA is in 'responder mode' while waiting = for the MPA=20 Request Frame.  Saying that the connection stays in 'TCP stream = mode' after=20 sending the Reject Reply Frame is not a sufficient description of = the state=20 change in MPA because it was in 'TCP stream mode' while in 'responder=20 mode'. 
 
So, from a state machine perspective:
* the ULP at the responder puts MPA into 'responder mode' while = it waits=20 for the Request Frame from the initiator.  In this state, MPA = consumes the=20 TCP data stream.
* after the responding MPA receives an MPA Request Frame from = the MPA=20 initiator, it transitions to a 'request received' state.  In = this=20 state, the connection is still in TCP stream mode, although MPA is not = expecting=20 any other received data from the initiator (should there be an error if = it=20 receives any?).  MPA stays in this state until it receives an = indication=20 from the ULP to reply to the initiator.
* if the Request Frame is valid and the ULP accepts the = connection, MPA=20 will transition to 'MPA mode' after sending the Reply Frame with the = rejected=20 bit set to 0.  In this state, MPA at the responder is = bound to=20 DDP and is waiting for the first FPDU from the initiator.  'Full = MPA mode',=20 where the responder can send FPDUs, doesn't occur until after the = responder=20 receives the first FPDU from the initiator.
* if the Request Frame is = invalid or if=20 the ULP rejects the connection, MPA will transition to an 'inactive' = state after=20 sending the Reply Frame with the rejected bit set to 1.  In this=20 state, the TCP connection is open, but MPA is no longer consuming = any of=20 the TCP data stream; instead any received data goes directly to the=20 ULP.
 
--jc
 
-----Original Message-----
From: = rddp-admin@ietf.org=20 [mailto:rddp-admin@ietf.org]On Behalf Of Talpey, = Thomas
Sent:=20 Wednesday, April 07, 2004 7:19 AM
To:=20 rddp@ietf.org
Subject: Re: [rddp] MPA issue (3): Rejected = Connection=20 bit

At 08:21 PM 3/29/2004, Black_David@emc.com = wrote:=20
>I suggest to the WG that the right thing to do = is include=20 this bit
>because it produces better = behavior in an=20 important error case for
>cooperative = clients where=20 something is misconfigured.  This bit
>allows=20 the RDDP layers to immediately know that a connection setup =
>has failed and release/reuse any resources committed to = it=20 without
>waiting for a ULP to look at the = private=20 data that came back.  It
>also ties = the fact=20 that the connection is closing with the
>associated=20 private data unambiguously (both can be immediately
>logged at RDDP level).  Yes, this is optimizing an = error=20 case,
>but it seems to be common = enough/of=20 sufficient concern to be
>worth spending = a bit=20 on.

I agree with this, and would add that by not having = the bit,=20 RDDP
violates layering requirements on TCP = regarding=20 the FIN. In order
to unambiguously indicate = "reject"=20 to the RDDP peer, the TCP FIN
must accompany = the=20 returned private data. Otherwise, the
initiating peer=20 must wait for a subsequent close. Also, with the
bit,=20 the connection may remain open for further operation in =
streaming mode, if desired.

Here is some proposed text around the reject = bit.

The Reject bit provides a means for the responding = MPA peer=20 to
reject an incoming RDDP connection. When = an=20 incoming connection
is unacceptable to the = responding=20 peer, the Reject bit MUST be
set in the = reply, along=20 with any ULP-specific private data. When
the = Reject=20 bit is true, the connection remains in stream (TCP) mode, =
and may be used and/or subsequently closed by either = peer.

Additional justifications:

Enhances interoperability by not leaving reject to = the=20 upper
layer. This permits ULP-independent = rejection,=20 and does not
require ULP private data=20 manipulation.

Simple, non-complicated change to MPA (single = bit).=20

Does not require the receiver to wait for subsequent = event,
as current proposal does (the = FIN).

Allows receiver to clean up MPA resources = immediately=20
upon rejection, avoiding resource retention if=20 connection
not closed.

Tom.

------_=_NextPart_001_01C41CCB.4759B884-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 8 06:30:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04532 for ; Thu, 8 Apr 2004 06:30:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBWmt-0007y4-T9 for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 06:29:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38ATZvm030628 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 06:29:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBWmt-0007xv-Hy for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 06:29:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04350 for ; Thu, 8 Apr 2004 06:29:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBWmp-0005w9-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 06:29:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBVH3-0006V5-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 04:52:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBSjW-0006Sd-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 02:09:50 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBSb6-0006wz-0C for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 02:01:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSb4-00079h-Hx; Thu, 08 Apr 2004 02:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSaV-0006qj-IH for rddp@optimus.ietf.org; Thu, 08 Apr 2004 02:00:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27858 for ; Thu, 8 Apr 2004 02:00:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBSaR-0005KT-00 for rddp@ietf.org; Thu, 08 Apr 2004 02:00:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRDO-0006zK-00 for rddp@ietf.org; Thu, 08 Apr 2004 00:32:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBOhW-0007hb-01 for rddp@ietf.org; Wed, 07 Apr 2004 21:51:30 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBORl-0003Wf-PH for rddp@ietf.org; Wed, 07 Apr 2004 21:35:13 -0400 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i381YfZh017795; Wed, 7 Apr 2004 18:34:42 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i381Yfbc016678; Wed, 7 Apr 2004 18:34:41 -0700 (PDT) Received: from tmt.netapp.com ([10.97.6.41]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 7 Apr 2004 21:34:36 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41D09.A6965E00" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [rddp] MPA issue (3): Rejected Connection bit Date: Wed, 7 Apr 2004 18:34:19 -0700 Message-ID: <6.1.0.6.2.20040407212713.01d49ec0@silver.nane.netapp.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQdCabxiozpCeMGSPuF1T+Rwtf5HQ== From: "Talpey, Thomas" To: "Carrier, John" Cc: 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41D09.A6965E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sounds good to me. Thanks for the clearer rewording. Only thing to add is that after the last step, the ULP can choose to return the MPA to Responder mode, or close the connection, etc as previously discussed. Tom. At 02:08 PM 4/7/2004, Carrier, John wrote: >Okay, so let me take another shot at clarification: >=20 >The draft shows that MPA is in 'responder mode' while waiting for the = MPA=20 >Request Frame. Saying that the connection stays in 'TCP stream mode' = after=20 >sending the Reject Reply Frame is not a sufficient description of the = state=20 >change in MPA because it was in 'TCP stream mode' while in 'responder = mode'. =20 >=20 >So, from a state machine perspective: >* the ULP at the responder puts MPA into 'responder mode' while it = waits for=20 >the Request Frame from the initiator. In this state, MPA consumes the = TCP=20 >data stream. >* after the responding MPA receives an MPA Request Frame from the MPA=20 >initiator, it transitions to a 'request received' state. In this = state, the=20 >connection is still in TCP stream mode, although MPA is not expecting = any=20 >other received data from the initiator (should there be an error if it=20 >receives any?). MPA stays in this state until it receives an = indication=20 >from the ULP to reply to the initiator.=20 >* if the Request Frame is valid and the ULP accepts the connection, MPA = will=20 >transition to 'MPA mode' after sending the Reply Frame with the = rejected bit=20 >set to 0. In this state, MPA at the responder is bound to DDP and is=20 >waiting for the first FPDU from the initiator. 'Full MPA mode', where = the=20 >responder can send FPDUs, doesn't occur until after the responder = receives=20 >the first FPDU from the initiator. >* if the Request Frame is invalid or if the ULP rejects the connection, = MPA=20 >will transition to an 'inactive' state after sending the Reply Frame = with=20 >the rejected bit set to 1. In this state, the TCP connection is open, = but=20 >MPA is no longer consuming any of the TCP data stream; instead any = received=20 >data goes directly to the ULP. >=20 >--jc >=20 > >-----Original Message----- >From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of = Talpey,=20 >Thomas >Sent: Wednesday, April 07, 2004 7:19 AM >To: rddp@ietf.org >Subject: Re: [rddp] MPA issue (3): Rejected Connection bit > > > >At 08:21 PM 3/29/2004, Black_David@emc.com wrote:=20 >>I suggest to the WG that the right thing to do is include this bit=20 >>because it produces better behavior in an important error case for=20 >>cooperative clients where something is misconfigured. This bit=20 >>allows the RDDP layers to immediately know that a connection setup=20 >>has failed and release/reuse any resources committed to it without=20 >>waiting for a ULP to look at the private data that came back. It=20 >>also ties the fact that the connection is closing with the=20 >>associated private data unambiguously (both can be immediately=20 >>logged at RDDP level). Yes, this is optimizing an error case,=20 >>but it seems to be common enough/of sufficient concern to be=20 >>worth spending a bit on.=20 > >I agree with this, and would add that by not having the bit, RDDP=20 >violates layering requirements on TCP regarding the FIN. In order=20 >to unambiguously indicate "reject" to the RDDP peer, the TCP FIN=20 >must accompany the returned private data. Otherwise, the=20 >initiating peer must wait for a subsequent close. Also, with the=20 >bit, the connection may remain open for further operation in=20 >streaming mode, if desired.=20 > >Here is some proposed text around the reject bit.=20 > >The Reject bit provides a means for the responding MPA peer to=20 >reject an incoming RDDP connection. When an incoming connection=20 >is unacceptable to the responding peer, the Reject bit MUST be=20 >set in the reply, along with any ULP-specific private data. When=20 >the Reject bit is true, the connection remains in stream (TCP) mode,=20 >and may be used and/or subsequently closed by either peer.=20 > >Additional justifications:=20 > >Enhances interoperability by not leaving reject to the upper=20 >layer. This permits ULP-independent rejection, and does not=20 >require ULP private data manipulation.=20 > >Simple, non-complicated change to MPA (single bit).=20 > >Does not require the receiver to wait for subsequent event,=20 >as current proposal does (the FIN).=20 > >Allows receiver to clean up MPA resources immediately=20 >upon rejection, avoiding resource retention if connection=20 >not closed.=20 > >Tom.=20 ------_=_NextPart_001_01C41D09.A6965E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rddp] MPA issue (3): Rejected Connection bit

Sounds good to me. Thanks for the clearer = rewording.

Only thing to add is that after the last step, the ULP = can
choose to return the MPA to Responder mode, or close = the
connection, etc as previously discussed.

Tom.

At 02:08 PM 4/7/2004, Carrier, John wrote:
>Okay, so let me take another shot at = clarification:
>
>The draft shows that MPA is in 'responder mode' = while waiting for the MPA
>Request Frame.  Saying that the connection = stays in 'TCP stream mode' after
>sending the Reject Reply Frame is not a = sufficient description of the state
>change in MPA because it was in 'TCP stream mode' = while in 'responder mode'. 
>
>So, from a state machine perspective:
>* the ULP at the responder puts MPA into = 'responder mode' while it waits for
>the Request Frame from the initiator.  In = this state, MPA consumes the TCP
>data stream.
>* after the responding MPA receives an MPA = Request Frame from the MPA
>initiator, it transitions to a 'request received' = state.  In this state, the
>connection is still in TCP stream mode, although = MPA is not expecting any
>other received data from the initiator (should = there be an error if it
>receives any?).  MPA stays in this state = until it receives an indication
>from the ULP to reply to the initiator.
>* if the Request Frame is valid and the ULP = accepts the connection, MPA will
>transition to 'MPA mode' after sending the Reply = Frame with the rejected bit
>set to 0.  In this state, MPA at the = responder is bound to DDP and is
>waiting for the first FPDU from the = initiator.  'Full MPA mode', where the
>responder can send FPDUs, doesn't occur until = after the responder receives
>the first FPDU from the initiator.
>* if the Request Frame is invalid or if the ULP = rejects the connection, MPA
>will transition to an 'inactive' state after = sending the Reply Frame with
>the rejected bit set to 1.  In this state, = the TCP connection is open, but
>MPA is no longer consuming any of the TCP data = stream; instead any received
>data goes directly to the ULP.
>
>--jc
>
>
>-----Original Message-----
>From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On = Behalf Of Talpey,
>Thomas
>Sent: Wednesday, April 07, 2004 7:19 AM
>To: rddp@ietf.org
>Subject: Re: [rddp] MPA issue (3): Rejected = Connection bit
>
>
>
>At 08:21 PM 3/29/2004, Black_David@emc.com wrote: =
>>I suggest to the WG that the right thing to = do is include this bit
>>because it produces better behavior in an = important error case for
>>cooperative clients where something is = misconfigured.  This bit
>>allows the RDDP layers to immediately know = that a connection setup
>>has failed and release/reuse any resources = committed to it without
>>waiting for a ULP to look at the private data = that came back.  It
>>also ties the fact that the connection is = closing with the
>>associated private data unambiguously (both = can be immediately
>>logged at RDDP level).  Yes, this is = optimizing an error case,
>>but it seems to be common enough/of = sufficient concern to be
>>worth spending a bit on.
>
>I agree with this, and would add that by not = having the bit, RDDP
>violates layering requirements on TCP regarding = the FIN. In order
>to unambiguously indicate "reject" to = the RDDP peer, the TCP FIN
>must accompany the returned private data. = Otherwise, the
>initiating peer must wait for a subsequent close. = Also, with the
>bit, the connection may remain open for further = operation in
>streaming mode, if desired.
>
>Here is some proposed text around the reject bit. =
>
>The Reject bit provides a means for the = responding MPA peer to
>reject an incoming RDDP connection. When an = incoming connection
>is unacceptable to the responding peer, the = Reject bit MUST be
>set in the reply, along with any ULP-specific = private data. When
>the Reject bit is true, the connection remains in = stream (TCP) mode,
>and may be used and/or subsequently closed by = either peer.
>
>Additional justifications:
>
>Enhances interoperability by not leaving reject = to the upper
>layer. This permits ULP-independent rejection, = and does not
>require ULP private data manipulation.
>
>Simple, non-complicated change to MPA (single = bit).
>
>Does not require the receiver to wait for = subsequent event,
>as current proposal does (the FIN).
>
>Allows receiver to clean up MPA resources = immediately
>upon rejection, avoiding resource retention if = connection
>not closed.
>
>Tom.

------_=_NextPart_001_01C41D09.A6965E00-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 8 13:23:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05097 for ; Thu, 8 Apr 2004 13:23:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdEe-0000LP-3k for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 13:22:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38HMc1c001212 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 13:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdEY-0000IA-4B for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 13:22:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04967 for ; Thu, 8 Apr 2004 13:22:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBdEJ-0002iD-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 13:22:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBaVc-0007no-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 10:28:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBYCf-00079u-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 08:00:17 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBXyu-0006Pb-BM for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 07:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBXys-0000z0-69; Thu, 08 Apr 2004 07:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBXyg-0000xs-V6 for rddp@optimus.ietf.org; Thu, 08 Apr 2004 07:45:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08790 for ; Thu, 8 Apr 2004 07:45:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBXyf-0005bj-00 for rddp@ietf.org; Thu, 08 Apr 2004 07:45:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBVz4-0005NH-00 for rddp@ietf.org; Thu, 08 Apr 2004 05:38:08 -0400 Received: from host51a.simplicato.com ([207.99.47.51]) by ietf-mx with smtp (Exim 4.12) id 1BBTpR-0006IU-00 for rddp@ietf.org; Thu, 08 Apr 2004 03:20:01 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host51a.simplicato.com (Postfix) with ESMTP id 81A34430D2F; Thu, 8 Apr 2004 03:20:01 -0400 (EDT) Received: from host51a.simplicato.com ([127.0.0.1]) by localhost (host51a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 33437-03; Thu, 8 Apr 2004 03:20:00 -0400 (EDT) Received: by host51a.simplicato.com (Postfix, from userid 15001) id 8A832430D2E; Thu, 8 Apr 2004 03:20:00 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host51a.simplicato.com (Postfix) with SMTP id D4789430D24; Thu, 8 Apr 2004 03:19:58 -0400 (EDT) Received: from 82.166.131.196 (proxying for 82.166.131.196) (SquirrelMail authenticated user cait@asomi.com) by mail51a.simplicato.com with HTTP; Thu, 8 Apr 2004 02:19:58 -0500 (CDT) Message-ID: <4717.82.166.131.196.1081408798.squirrel@mail51a.simplicato.com> In-Reply-To: <59C7D667A0EADB45866C62DD1B55A0FD01F0C639@aime2k02.adaptec.com> References: <59C7D667A0EADB45866C62DD1B55A0FD01F0C639@aime2k02.adaptec.com> Date: Thu, 8 Apr 2004 02:19:58 -0500 (CDT) Subject: RE: [rddp] MPA issue (3): Rejected Connection bit From: "Caitlin Bestler" To: "Carrier, John" Cc: rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at simplicato.com 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.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Carrier, John said: > * if the Request Frame is invalid or if the ULP rejects the connection, > MPA will transition to an 'inactive' state after sending the Reply Fram= e > with the rejected bit set to 1. In this state, the TCP connection is > open, but MPA is no longer consuming any of the TCP data stream; instea= d > any received data goes directly to the ULP. > The two reject cases should be distinquished. If the Request Frame is invalid the request is being rejected by the MPA layer, not by the ULP. There is no Private Data available for a response. If it was rejected by the ULP, there will be Private Data supplied in accordance with the specific protocol. Providing a zero length Private Data may have specific meaning under that protocol. Generally, if the Request Frame itself is invalid the most likely cause is a misdirected connect request by a non-RDMA client. Such a client will not be able to parse the Reply Frame anyway (and given that it cannot format a Request Frame there is little reason to believe that it will). In that case I believe the correct respsonse to an invalid request frame would be to simply terminate the connection. This means that invalid MPA Request Frames will be lumped with other "network related" errors from the initiating ULPs perspective. In my opinion this is a better grouping than lumping it with a peer reject, particularly if it forces the ULP to specify a non-zero lenght "nothing" message just to prove it was the ULP that had indeed said nothing. If someone can suggest a reason why this error is of particular signifigance to the source ULP then I could see having a distinct error bit. But my suspicion is that this error will seldom be seen between actual RDMA peers, and more often be the result of a misdirected non-RDMA client. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 8 19:14:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06701 for ; Thu, 8 Apr 2004 19:14:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiii-0004V7-B5 for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 19:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NE4NU017293 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 19:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiii-0004UY-6i for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06625 for ; Thu, 8 Apr 2004 19:14:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiig-0002b7-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 19:14:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiUz-0001Fh-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 18:59:55 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBgtD-0004eh-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 17:16:47 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBgf4-0004qh-OI for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 17:02:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgew-0005Ax-I5; Thu, 08 Apr 2004 17:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgeb-000595-CT for rddp@optimus.ietf.org; Thu, 08 Apr 2004 17:01:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23391 for ; Thu, 8 Apr 2004 17:01:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBgeX-0003K1-00 for rddp@ietf.org; Thu, 08 Apr 2004 17:01:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBe4x-0000Se-00 for rddp@ietf.org; Thu, 08 Apr 2004 14:16:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBbWy-0005jf-00 for rddp@ietf.org; Thu, 08 Apr 2004 11:33:28 -0400 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBajy-0001xc-4k for rddp@ietf.org; Thu, 08 Apr 2004 10:42:50 -0400 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A502B6EC014A; Thu, 08 Apr 2004 10:43:14 -0400 From: "Barry Reinhold" To: "RDDP" Date: Thu, 8 Apr 2004 10:42:24 -0400 Message-ID: <002d01c41d77$b8457550$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [rddp] (no subject) 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 How would you expect a MPA receiver to handle an out of order TCP segment with markers disabled and CRC off? Does it just buffer it until the gap is filled? Also, if CRCs are enabled and we are processing an out of order PDU without markers, what is the behavioral expectation of a failed CRC check? A matched CRC would be sufficient to determine FPDU alignment, but a failed CRC appears only to say that you may not have FPDU alignment. That is, if I created a test that produced a gap in the TCP sequence and then sent an unaligned FPDU within a TCP segment, followed by the missing information I would expect the receiver to: (1) Not drop the connection, (2) Advance the ACK through the unaligned segment when the missing information was sent. Is this the correct understanding? 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 Apr 8 20:05:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13312 for ; Thu, 8 Apr 2004 20:05:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjWO-0000uE-Ja for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 20:05:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3905O9Y003478 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 20:05:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjWK-0000sy-Bt for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:05:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13250 for ; Thu, 8 Apr 2004 20:05:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjWH-0000j0-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:05:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBigP-0002C9-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 19:11:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBi53-0006CX-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 18:33:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBi4z-0006jC-7v; Thu, 08 Apr 2004 18:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBi4X-0006gw-Ir for rddp@optimus.ietf.org; Thu, 08 Apr 2004 18:32:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02727 for ; Thu, 8 Apr 2004 18:32:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBi4S-0006AC-00 for rddp@ietf.org; Thu, 08 Apr 2004 18:32:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBg5b-0006Ec-00 for rddp@ietf.org; Thu, 08 Apr 2004 16:25:33 -0400 Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx with esmtp (Exim 4.12) id 1BBdBe-0002EP-00 for rddp@ietf.org; Thu, 08 Apr 2004 13:19:34 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i38HImW12209; Thu, 8 Apr 2004 10:18:48 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i38HIm802550; Thu, 8 Apr 2004 10:18:48 -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] MPA issue (3): Rejected Connection bit Date: Thu, 8 Apr 2004 10:18:48 -0700 Message-ID: <59C7D667A0EADB45866C62DD1B55A0FD01F0C732@aime2k02.adaptec.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQdXxka2/uyRGJzQxqflNfhVpA86gALhT2Q From: "Carrier, John" To: "Caitlin Bestler" Cc: 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Caitlin, Again a clarification: MPA does not send a Reply Frame unless instructed = to do so by the ULP. If MPA receives an invalid Request Frame, then it = indicates the error to the ULP but takes no other action of its own. =20 My interpretation of what you describe below is that if there is an = invalid Request Frame, there should be no Reply Frame generated. In = that case, MPA would transition to what I called the 'inactive' state = after it passes the error to the ULP. The result would be that MPA is = decoupled from the TCP stream. The ULP would then, presumably, = terminate the connection. =20 right? --jc > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of > Caitlin Bestler > Sent: Thursday, April 08, 2004 12:20 AM > To: Carrier, John > Cc: rddp@ietf.org > Subject: RE: [rddp] MPA issue (3): Rejected Connection bit >=20 >=20 > Carrier, John said: >=20 > > * if the Request Frame is invalid or if the ULP rejects the=20 > connection, > > MPA will transition to an 'inactive' state after sending=20 > the Reply Frame > > with the rejected bit set to 1. In this state, the TCP=20 > connection is > > open, but MPA is no longer consuming any of the TCP data=20 > stream; instead > > any received data goes directly to the ULP. > > >=20 > The two reject cases should be distinquished. >=20 > If the Request Frame is invalid the request is being rejected by > the MPA layer, not by the ULP. There is no Private Data available > for a response. >=20 > If it was rejected by the ULP, there will be Private Data supplied > in accordance with the specific protocol. Providing a zero length > Private Data may have specific meaning under that protocol. >=20 > Generally, if the Request Frame itself is invalid the most likely > cause is a misdirected connect request by a non-RDMA client. > Such a client will not be able to parse the Reply Frame anyway > (and given that it cannot format a Request Frame there is little > reason to believe that it will). >=20 > In that case I believe the correct respsonse to an invalid request > frame would be to simply terminate the connection. >=20 > This means that invalid MPA Request Frames will be lumped with > other "network related" errors from the initiating ULPs perspective. > In my opinion this is a better grouping than lumping it with a > peer reject, particularly if it forces the ULP to specify a non-zero > lenght "nothing" message just to prove it was the ULP that had > indeed said nothing. >=20 > If someone can suggest a reason why this error is of particular > signifigance to the source ULP then I could see having a distinct > error bit. But my suspicion is that this error will seldom be seen > between actual RDMA peers, and more often be the result of > a misdirected non-RDMA client. >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 8 20:07:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13803 for ; Thu, 8 Apr 2004 20:07:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjYD-0001Gx-4t for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 20:07:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3907Hxd004887 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 20:07:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjYD-0001Gk-0G for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:07:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13713 for ; Thu, 8 Apr 2004 20:07:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjYA-00011e-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:07:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiiE-0002XR-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 19:13:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBiSD-0000p7-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 18:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiSE-0002Ui-4j; Thu, 08 Apr 2004 18:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiRa-0002UC-BV for rddp@optimus.ietf.org; Thu, 08 Apr 2004 18:56:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05039 for ; Thu, 8 Apr 2004 18:56:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiRW-0000jF-00 for rddp@ietf.org; Thu, 08 Apr 2004 18:56:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgdR-0003Du-00 for rddp@ietf.org; Thu, 08 Apr 2004 17:00:31 -0400 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 1BBe4F-0000La-00 for rddp@ietf.org; Thu, 08 Apr 2004 14:15:59 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.46]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id D93D053B5 for ; Thu, 8 Apr 2004 11:15:18 -0700 (PDT) Received: from cacexc05.americas.cpqcorp.net ([16.92.1.29]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 11:15:16 -0700 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: [rddp] SDP LocIRD and LocORD in Hello & HelloAck msg Date: Thu, 8 Apr 2004 11:15:16 -0700 Message-ID: Thread-Topic: [rddp] SDP LocIRD and LocORD in Hello & HelloAck msg Thread-Index: AcQdlXFyQCuLL9ZiTZmees6/yzZcCw== From: "Wong, Isaac M (U.S.A. EUD, SNSL)" To: X-OriginalArrivalTime: 08 Apr 2004 18:15:16.0812 (UTC) FILETIME=[71B338C0:01C41D95] 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 am looking for some clarification on the two fields, LocIRD and LocORD in SDP Hello and HelloAck message as described in=20 draft-pinkerton-iwarp-sdp-00.txt. I believe the description of Hello and HelloAck message in section 6.2.1 and 6.2.2 is from the perspective of the senders of the messages. If this is true, then LocIRD in the Hello Message should relate to the LocORD in the HelloAck Message. Similarly, the LocORD in the Hello Message should relate to the LocIRD in the HelloAck Message.=20 I am not clear if these fields are listed as part of setup negotiation. I suspect they are. If this is true, then I believe the owner of each of the read queues should have the final say on the maximum queue length, and the senders to these queues can advertize a lower number. So, LocORD in HelloAck <=3D LocIRD in Hello. LocORD in Hello >=3D LocIRD in = HelloAck. Thus, FinalLocIRD at Hello sender =3D FinalLocORD at HelloAck sender =3D = min (LocIRD in Hello, LocORD in HelloAck);=20 FinalLocORD at Hello sender =3D FinalLocIRD at HelloAck sender =3D min (LocORD in Hello, LocIRD in HelloAck); Is this the way they should be interpreted? Isaac Wong Hewlett Packard _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 8 21:05:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18385 for ; Thu, 8 Apr 2004 21:05:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkSM-0001Qz-HD for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 21:05:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3915IFC005509 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 21:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkSM-0001Qm-Dw for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:05:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18287 for ; Thu, 8 Apr 2004 21:05:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkSJ-0007kU-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 21:05:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkDA-0005Jo-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:49:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjpz-0002aq-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:25:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjpx-0002yc-BG; Thu, 08 Apr 2004 20:25:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiz8-0005to-RF for rddp@optimus.ietf.org; Thu, 08 Apr 2004 19:31:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08763 for ; Thu, 8 Apr 2004 19:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiz6-0004vf-00 for rddp@ietf.org; Thu, 08 Apr 2004 19:31:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhrn-0004UW-00 for rddp@ietf.org; Thu, 08 Apr 2004 18:19:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfqn-00031k-00 for rddp@ietf.org; Thu, 08 Apr 2004 16:10:13 -0400 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBf6m-00022J-Ju for rddp@ietf.org; Thu, 08 Apr 2004 15:22:40 -0400 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A6A3A795008E; Thu, 08 Apr 2004 15:23:15 -0400 From: "Barry Reinhold" To: "RDDP" Date: Thu, 8 Apr 2004 15:22:11 -0400 Message-ID: <003d01c41d9e$d5a73580$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [rddp] Expectations for FPDU alignment when processing out of order TCP segment 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 This may be a duplicate posting, my apologies if it is. How would you expect a MPA receiver to handle an out of order TCP segment with markers disabled and CRC off? Does it just buffer it until the gap is filled? Also, if CRCs are enabled and we are processing an out of order PDU without markers, what is the behavioral expectation of a failed CRC check? A matched CRC would be sufficient to determine FPDU alignment, but a failed CRC appears only to say that you may not have FPDU alignment. That is, if I created a test that produced a gap in the TCP sequence and then sent an unaligned FPDU within a TCP segment, followed by the missing information I would expect the receiver to: (1) Not drop the connection, (2) Advance the ACK through the unaligned segment when the missing information was sent. Is this the correct understanding? 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 Apr 8 21:05:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18444 for ; Thu, 8 Apr 2004 21:05:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkSY-0001S6-DO for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 21:05:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3915UiL005578 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 21:05:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkSY-0001Rt-97 for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:05:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18309 for ; Thu, 8 Apr 2004 21:05:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkSV-0007lF-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 21:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkDH-0005LW-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:49:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjq9-0002cX-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:25:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjqA-00038b-La; Thu, 08 Apr 2004 20:25:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBj1N-0006CE-Ad for rddp@optimus.ietf.org; Thu, 08 Apr 2004 19:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09069 for ; Thu, 8 Apr 2004 19:33:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBj1L-00059L-00 for rddp@ietf.org; Thu, 08 Apr 2004 19:33:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhtm-0004pD-00 for rddp@ietf.org; Thu, 08 Apr 2004 18:21:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfs5-0003Kv-00 for rddp@ietf.org; Thu, 08 Apr 2004 16:11:33 -0400 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBelD-0007MQ-MU for rddp@ietf.org; Thu, 08 Apr 2004 15:00:23 -0400 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A1602EAD020E; Thu, 08 Apr 2004 15:00:48 -0400 From: "Barry Reinhold" To: "RDDP" Date: Thu, 8 Apr 2004 14:59:55 -0400 Message-ID: <003b01c41d9b$b3514280$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [rddp] Note for second conference call on conformance and interoperability testing effort 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 The second conference call for establishing the iWARP interoperability and conformance effort will be held on Wednesday April 14 at 1:30 EDT. Please send me an email if you need to obtain the conference call bridge numbers. If you already have that information from the previous call it is still valid. 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 Apr 8 21:15:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19502 for ; Thu, 8 Apr 2004 21:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkbl-00038W-BM for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 21:15:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391F1Td012050 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 21:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkbk-000389-0J for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:15:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19450 for ; Thu, 8 Apr 2004 21:14:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkbg-0000jn-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 21:14:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkK8-0006mj-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:56:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBk6p-0004L8-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:43:04 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBjv2-0005LN-PI for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:30:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjuF-0005oI-G8; Thu, 08 Apr 2004 20:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjth-0005Nf-M3 for rddp@optimus.ietf.org; Thu, 08 Apr 2004 20:29:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15874 for ; Thu, 8 Apr 2004 20:29:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjte-00035D-00 for rddp@ietf.org; Thu, 08 Apr 2004 20:29:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBjN9-0007Pb-00 for rddp@ietf.org; Thu, 08 Apr 2004 19:55:52 -0400 Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx with esmtp (Exim 4.12) id 1BBiR1-0000XB-00 for rddp@ietf.org; Thu, 08 Apr 2004 18:55:47 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i38Mt7W25506; Thu, 8 Apr 2004 15:55:07 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i38Mt7820515; Thu, 8 Apr 2004 15:55:07 -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] (no subject) Date: Thu, 8 Apr 2004 15:55:07 -0700 Message-ID: <59C7D667A0EADB45866C62DD1B55A0FD01F0C798@aime2k02.adaptec.com> Thread-Topic: [rddp] (no subject) Thread-Index: AcQdrNRXgZdT9/DBSOud3I9ELqFHqAADW+JA From: "Carrier, John" To: "Barry Reinhold" , "RDDP" 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Barry, FPDU alignment is a property of the TCP segment where the first byte of = the FPDU follows the TCP header. A valid FPDU CRC, however, does not = guarantee FPDU alignment. Thus, turning CRCs off is orthogonal to = turning markers off. If markers are disabled, an MPA receiver can only determine the start of = the next FPDU from the length of the previous FPDU. If a TCP segment is = received out of order, the MPA receiver would have to buffer the segment = until the gap is filled.=20 --jc > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On=20 > Behalf Of Barry > Reinhold > Sent: Thursday, April 08, 2004 7:42 AM > To: RDDP > Subject: [rddp] (no subject) >=20 >=20 > How would you expect a MPA receiver to handle an out of order TCP > segment with markers disabled and CRC off? Does it just=20 > buffer it until > the gap is filled? >=20 > Also, if CRCs are enabled and we are processing an out of order PDU > without markers, what is the behavioral expectation of a failed CRC > check? A matched CRC would be sufficient to determine FPDU alignment, > but a failed CRC appears only to say that you may not have FPDU > alignment.=20 >=20 > That is, if I created a test that produced a gap in the TCP=20 > sequence and > then sent an unaligned FPDU within a TCP segment, followed by the > missing information I would expect the receiver to: (1) Not drop the > connection, (2) Advance the ACK through the unaligned segment when the > missing information was sent. >=20 > Is this the correct understanding? >=20 > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 8 21:17:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19837 for ; Thu, 8 Apr 2004 21:17:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkdI-0003Jx-No for rddp-archive@odin.ietf.org; Thu, 08 Apr 2004 21:16:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391GaaB012761 for rddp-archive@odin.ietf.org; Thu, 8 Apr 2004 21:16:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkdI-0003Jg-5y for rddp-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:16:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19708 for ; Thu, 8 Apr 2004 21:16:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkdF-0000qS-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 21:16:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkKw-0006w9-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:57:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBk7F-0004L8-00 for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:43:29 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBjtq-0005JF-Bb for rddp-web-archive@ietf.org; Thu, 08 Apr 2004 20:29:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjtd-0005MF-G6; Thu, 08 Apr 2004 20:29:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjhE-0001sY-Ud for rddp@optimus.ietf.org; Thu, 08 Apr 2004 20:16:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14300 for ; Thu, 8 Apr 2004 20:16:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjhA-0001x5-00 for rddp@ietf.org; Thu, 08 Apr 2004 20:16:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiqX-0003u1-00 for rddp@ietf.org; Thu, 08 Apr 2004 19:22:11 -0400 Received: from zcamail05.zca.compaq.com ([161.114.32.105]) by ietf-mx with esmtp (Exim 4.12) id 1BBhgc-0002iK-00 for rddp@ietf.org; Thu, 08 Apr 2004 18:07:50 -0400 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.50]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 1C04FB7F6; Thu, 8 Apr 2004 15:07:10 -0700 (PDT) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.21]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 15:07:08 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6529.0 Subject: RE: [rddp] (no subject) Date: Thu, 8 Apr 2004 17:07:07 -0500 Message-ID: <717252EC3E37AE4392E2614EA24E9F2B080E8F3D@txnexc01.americas.cpqcorp.net> Thread-Topic: [rddp] (no subject) Thread-Index: AcQdrNEijlJmCz5wQbKwRrrIo5h+pQAAxw4g From: "Teisberg, Robert" To: "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 08 Apr 2004 22:07:08.0241 (UTC) FILETIME=[D58ED410:01C41DB5] 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 >=20 >=20 > How would you expect a MPA receiver to handle an out of order TCP > segment with markers disabled and CRC off? Does it just=20 > buffer it until > the gap is filled? Most likely. It could also discard it. Anything plain TCP can do is allowed. For what it's worth, if markers and CRCs are turned off, the implementation is probably software MPA over MPA-unaware TCP. A survey of existing TCP implementations will give you a good idea what to expect. >=20 > Also, if CRCs are enabled and we are processing an out of order PDU > without markers, what is the behavioral expectation of a failed CRC > check? A matched CRC would be sufficient to determine FPDU alignment, > but a failed CRC appears only to say that you may not have FPDU > alignment.=20 >=20 > That is, if I created a test that produced a gap in the TCP=20 > sequence and > then sent an unaligned FPDU within a TCP segment, followed by the > missing information I would expect the receiver to: (1) Not drop the > connection, (2) Advance the ACK through the unaligned segment when the > missing information was sent. >=20 > Is this the correct understanding? >=20 It's one possibility. Depending on timing and the receiver's TCP implementation, there are some potentially interesting alternatives: (2a) Discard the out-of-order segment, and advance the ACK only through the previously missing information (go-back-n). (2b) and (2c) SACK, and otherwise behave as in either (2) or (2a). I don't know how likely these are, but they're all legitimate. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Apr 9 02:35:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14112 for ; Fri, 9 Apr 2004 02:35:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpbq-0006RP-4r for rddp-archive@odin.ietf.org; Fri, 09 Apr 2004 02:35:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i396ZQb7024755 for rddp-archive@odin.ietf.org; Fri, 9 Apr 2004 02:35:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpbp-0006RC-Nx for rddp-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 02:35:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14093 for ; Fri, 9 Apr 2004 02:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBpbl-0006FQ-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 02:35:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBpZk-00067I-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 02:33:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBpXa-000603-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 02:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpXZ-00062i-95; Fri, 09 Apr 2004 02:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpXV-00061n-E3 for rddp@optimus.ietf.org; Fri, 09 Apr 2004 02:30:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13984 for ; Fri, 9 Apr 2004 02:30:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBpXO-0005x8-00 for rddp@ietf.org; Fri, 09 Apr 2004 02:30:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBpWC-0005iz-00 for rddp@ietf.org; Fri, 09 Apr 2004 02:29:37 -0400 Received: from host51a.simplicato.com ([207.99.47.51]) by ietf-mx with smtp (Exim 4.12) id 1BBpV9-0005cr-00 for rddp@ietf.org; Fri, 09 Apr 2004 02:28:31 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host51a.simplicato.com (Postfix) with ESMTP id 1971C430C2A; Fri, 9 Apr 2004 02:28:19 -0400 (EDT) Received: from host51a.simplicato.com ([127.0.0.1]) by localhost (host51a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 77766-02; Fri, 9 Apr 2004 02:28:18 -0400 (EDT) Received: by host51a.simplicato.com (Postfix, from userid 15001) id 3560E430DF7; Fri, 9 Apr 2004 02:28:17 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host51a.simplicato.com (Postfix) with SMTP id D5B0B430BF4; Fri, 9 Apr 2004 02:28:16 -0400 (EDT) Received: from 82.166.131.196 (proxying for 82.166.131.196) (SquirrelMail authenticated user cait@asomi.com) by mail51a.simplicato.com with HTTP; Fri, 9 Apr 2004 01:28:16 -0500 (CDT) Message-ID: <14460.82.166.131.196.1081492096.squirrel@mail51a.simplicato.com> In-Reply-To: <003d01c41d9e$d5a73580$467fa8c0@i8600> References: <003d01c41d9e$d5a73580$467fa8c0@i8600> Date: Fri, 9 Apr 2004 01:28:16 -0500 (CDT) Subject: Re: [rddp] Expectations for FPDU alignment when processing out of order TCP segment From: "Caitlin Bestler" To: "Barry Reinhold" Cc: "RDDP" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at simplicato.com 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,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry Reinhold said: > This may be a duplicate posting, my apologies if it is. > > How would you expect a MPA receiver to handle an out of order TCP > segment with markers disabled and CRC off? Does it just buffer it until > the gap is filled? As noted in John's response, when markers are disabled the only way to know where a DDP Segment starts is to know where the prior one started. To be very technical, it is hypothetically possible to have a gap still pending in the middle of a segment that you have the start of. Hence you *could* recognize that you had a valid TCP Segment and within it a valid DDP Segment, and you *could* process it of order. Then all you have to do is figure out how to test it. Realistically, if you are working without markers you pretty much have to process in order. You *could* do a *speculative* analysis, to determine if something *might* be a DDP Segment. And it the CRC failed it would certainly be useful diagnostic data. However a receiver should not "speculate" on placement until it knows legitimately that something is a DDP Segment. After all, there is no rule that says a valid DDP Segment could not be the *payload* that is being delivered within a DDP Segment. If I recall correctly, Jim Williams posted a proposed alternative to MPA a bit back that had an excellent description of what a receiver would have to do if it were to do speculative handling of DDP Segments to ensure that it had no adverse impact on the ULP. > > Also, if CRCs are enabled and we are processing an out of order PDU > without markers, what is the behavioral expectation of a failed CRC > check? A matched CRC would be sufficient to determine FPDU alignment, > but a failed CRC appears only to say that you may not have FPDU > alignment. > The effect of a bad CRC is to terminate the connection. But the receiver must not take that action until it knows that the bad CRC is indeed attached to a valid DDP Segment and not merely something that looks like one. > That is, if I created a test that produced a gap in the TCP sequence an= d > then sent an unaligned FPDU within a TCP segment, followed by the > missing information I would expect the receiver to: (1) Not drop the > connection, (2) Advance the ACK through the unaligned segment when the > missing information was sent. > > Is this the correct understanding? Mostly correct. In the previously noted case where the starting location of the DDP Segment could be known legitimately, the receiver MAY process the DDP Segment as soon as all enclosing TCP segments are validated, and the MPA checksum is validated. And at that point it *could* note that there was an MPA error, or even a DDP layer error, and terminate the connection. But I doubt that anyone will take heroic efforts to process non-marker MPA FULPDUs out-of-order. If you want to work out-of-order you will simply insist on receiving markers. So techically, an analysis tool that expected no action would be technica= lly incorrect. But if I were assigning a "bug value" to such a mistake it wou= ld probably be a 1 out of a possible 100. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Apr 9 04:40:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18193 for ; Fri, 9 Apr 2004 04:40:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBrY7-0008SI-SD for rddp-archive@odin.ietf.org; Fri, 09 Apr 2004 04:39:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i398dh88032502 for rddp-archive@odin.ietf.org; Fri, 9 Apr 2004 04:39:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBrY5-0008S8-5I for rddp-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 04:39:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18183 for ; Fri, 9 Apr 2004 04:39:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBrY1-00012d-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 04:39:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBrW0-0000uH-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 04:37:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBrUX-0000ip-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 04:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBrUX-0007z7-DQ; Fri, 09 Apr 2004 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBrTm-0007yG-33 for rddp@optimus.ietf.org; Fri, 09 Apr 2004 04:35:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18059 for ; Fri, 9 Apr 2004 04:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBrTh-0000fd-00 for rddp@ietf.org; Fri, 09 Apr 2004 04:35:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBrS2-0000U0-00 for rddp@ietf.org; Fri, 09 Apr 2004 04:33:27 -0400 Received: from [207.99.47.51] (helo=host51a.simplicato.com) by ietf-mx with smtp (Exim 4.12) id 1BBrR1-0000H9-00 for rddp@ietf.org; Fri, 09 Apr 2004 04:32:24 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host51a.simplicato.com (Postfix) with ESMTP id 522274312D9; Fri, 9 Apr 2004 04:32:17 -0400 (EDT) Received: from host51a.simplicato.com ([127.0.0.1]) by localhost (host51a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 98505-08; Fri, 9 Apr 2004 04:32:16 -0400 (EDT) Received: by host51a.simplicato.com (Postfix, from userid 15001) id 714974312E6; Fri, 9 Apr 2004 04:32:16 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host51a.simplicato.com (Postfix) with SMTP id 04E844312E5; Fri, 9 Apr 2004 04:32:16 -0400 (EDT) Received: from 82.166.131.196 (proxying for 82.166.131.196) (SquirrelMail authenticated user cait@asomi.com) by mail51a.simplicato.com with HTTP; Fri, 9 Apr 2004 03:32:16 -0500 (CDT) Message-ID: <58774.82.166.131.196.1081499536.squirrel@mail51a.simplicato.com> In-Reply-To: <59C7D667A0EADB45866C62DD1B55A0FD01F0C732@aime2k02.adaptec.com> References: <59C7D667A0EADB45866C62DD1B55A0FD01F0C732@aime2k02.adaptec.com> Date: Fri, 9 Apr 2004 03:32:16 -0500 (CDT) Subject: RE: [rddp] MPA issue (3): Rejected Connection bit From: "Caitlin Bestler" To: "Carrier, John" Cc: "Caitlin Bestler" , rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at simplicato.com 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,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Carrier, John said: > Hi Caitlin, > > Again a clarification: MPA does not send a Reply Frame unless instructe= d > to do so by the ULP. If MPA receives an invalid Request Frame, then it > indicates the error to the ULP but takes no other action of its own. > > My interpretation of what you describe below is that if there is an > invalid Request Frame, there should be no Reply Frame generated. In th= at > case, MPA would transition to what I called the 'inactive' state after = it > passes the error to the ULP. The result would be that MPA is decoupled > from the TCP stream. The ULP would then, presumably, terminate the > connection. > > right? > Yes, with the understanding that the ULP may have instructed MPA in advan= ce to terminate the connection. But the decision to terminate the connection should indeed belong to the ULP. Applications using the "connect or using RDMA or bust" APIs currently found in DAT and IT-API would presumably prefer for the TCP connection to be terminated rather than being forced to do a round-trip. Those doing iSER/SDP over iWarp style setup might want their connection back to allow them to continue in non-RDMA mode (even though it is more likely that they negotiated use of RDMA in streaming mode, so a failure to enter RDMA mode would probably still result in terminating the connection -- who wants to deal with a peer that changes their mind that quickly?) _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Apr 9 18:31:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28401 for ; Fri, 9 Apr 2004 18:31:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Wd-0003B5-TF for rddp-archive@odin.ietf.org; Fri, 09 Apr 2004 18:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39MV3Xj012216 for rddp-archive@odin.ietf.org; Fri, 9 Apr 2004 18:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Wc-0003Ax-U0 for rddp-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 18:31:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28363 for ; Fri, 9 Apr 2004 18:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4WZ-0001sY-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 18:30:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4So-0001T3-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 18:27:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC4Mz-0000zn-00 for rddp-web-archive@ietf.org; Fri, 09 Apr 2004 18:21:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Mx-0001e4-6E; Fri, 09 Apr 2004 18:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Mj-0001c3-DW for rddp@optimus.ietf.org; Fri, 09 Apr 2004 18:20:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27862 for ; Fri, 9 Apr 2004 18:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4Mf-0000x6-00 for rddp@ietf.org; Fri, 09 Apr 2004 18:20:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4Fk-0000KV-00 for rddp@ietf.org; Fri, 09 Apr 2004 18:13:37 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 1BC45G-0007KL-00 for rddp@ietf.org; Fri, 09 Apr 2004 18:02:46 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i39M1v67691276; Fri, 9 Apr 2004 18:01:57 -0400 Received: from d01ml604.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i39M2G9t105156; Fri, 9 Apr 2004 18:02:19 -0400 In-Reply-To: <58774.82.166.131.196.1081499536.squirrel@mail51a.simplicato.com> Importance: Normal MIME-Version: 1.0 To: "Caitlin Bestler" Cc: rddp@ietf.org Subject: RE: [rddp] MPA issue (3): Rejected Connection bit X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Mike Ko Date: Fri, 9 Apr 2004 15:01:51 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF87 | March 11, 2004) at 04/09/2004 18:01:56, Serialize complete at 04/09/2004 18:01:56 Content-Type: text/plain; charset="US-ASCII" Sender: rddp-admin@ietf.org Errors-To: rddp-admin@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , 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 The handling of the MPA Request Frame was not considered when the iSER draft was written. But since the decision to enter RDMA mode is made during the iSCSI login phase in stream mode, if the subsequent MPA Request Frame is invalid, it will be treated as an LLP error and presumably the MPA layer will be instructed to tear the connection down. Mike Sent by: rddp-admin@ietf.org To: "Carrier, John" cc: "Caitlin Bestler" , rddp@ietf.org Subject: RE: [rddp] MPA issue (3): Rejected Connection bit Carrier, John said: > Hi Caitlin, > > Again a clarification: MPA does not send a Reply Frame unless instructed > to do so by the ULP. If MPA receives an invalid Request Frame, then it > indicates the error to the ULP but takes no other action of its own. > > My interpretation of what you describe below is that if there is an > invalid Request Frame, there should be no Reply Frame generated. In that > case, MPA would transition to what I called the 'inactive' state after it > passes the error to the ULP. The result would be that MPA is decoupled > from the TCP stream. The ULP would then, presumably, terminate the > connection. > > right? > Yes, with the understanding that the ULP may have instructed MPA in advance to terminate the connection. But the decision to terminate the connection should indeed belong to the ULP. Applications using the "connect or using RDMA or bust" APIs currently found in DAT and IT-API would presumably prefer for the TCP connection to be terminated rather than being forced to do a round-trip. Those doing iSER/SDP over iWarp style setup might want their connection back to allow them to continue in non-RDMA mode (even though it is more likely that they negotiated use of RDMA in streaming mode, so a failure to enter RDMA mode would probably still result in terminating the connection -- who wants to deal with a peer that changes their mind that quickly?) _______________________________________________ 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 Mon Apr 12 09:17:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18582 for ; Mon, 12 Apr 2004 09:17:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1Ih-0002MT-DP for rddp-archive@odin.ietf.org; Mon, 12 Apr 2004 09:16:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CDGZxO009073 for rddp-archive@odin.ietf.org; Mon, 12 Apr 2004 09:16:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1Ih-0002MG-76 for rddp-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 09:16:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18545 for ; Mon, 12 Apr 2004 09:16:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1If-0000Ip-00 for rddp-web-archive@ietf.org; Mon, 12 Apr 2004 09:16:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1I0-00009X-00 for rddp-web-archive@ietf.org; Mon, 12 Apr 2004 09:15:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD1GC-0007l7-00 for rddp-web-archive@ietf.org; Mon, 12 Apr 2004 09:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1GC-000258-Qz; Mon, 12 Apr 2004 09:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1FM-00024S-Uw for rddp@optimus.ietf.org; Mon, 12 Apr 2004 09:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18339 for ; Mon, 12 Apr 2004 09:13:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1FJ-0007dh-00 for rddp@ietf.org; Mon, 12 Apr 2004 09:13:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1Dg-0007RS-00 for rddp@ietf.org; Mon, 12 Apr 2004 09:11:25 -0400 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BD1Cx-0007J9-00 for rddp@ietf.org; Mon, 12 Apr 2004 09:10:39 -0400 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A56FDE70080; Mon, 12 Apr 2004 09:11:11 -0400 From: "Barry Reinhold" To: "Renato Recio" Cc: "RDDP" Date: Mon, 12 Apr 2004 09:10:16 -0400 Message-ID: <000201c4208f$82e45230$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] bit locations not specified for HdrCt 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 The bit locations for the M, D, and R bits of the HdrCt field are not specified in either figure 7 or 8. Based on the order in which they are listed on page 39 under HdrCt, it is clear that a "normal" engineer would assume that the M bit goes into the MSB. However, there may be "MSB challenged" engineers who believe that the M bit belongs in the LSB of the field. Since there may be some "MSB challenged" engineers in our midst, we probably ought to specify this. 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 Apr 12 20:32:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27885 for ; Mon, 12 Apr 2004 20:32:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDBqA-0002Fd-Qe for rddp-archive@odin.ietf.org; Mon, 12 Apr 2004 20:31:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D0VoVn008642 for rddp-archive@odin.ietf.org; Mon, 12 Apr 2004 20:31:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDBq7-0002Ep-0r for rddp-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 20:31:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27845 for ; Mon, 12 Apr 2004 20:31:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDBq3-0001mS-00 for rddp-web-archive@ietf.org; Mon, 12 Apr 2004 20:31:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDBli-0001Db-00 for rddp-web-archive@ietf.org; Mon, 12 Apr 2004 20:27:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDBds-0000ce-00 for rddp-web-archive@ietf.org; Mon, 12 Apr 2004 20:19:08 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDBdp-0003aX-W1 for rddp-web-archive@ietf.org; Mon, 12 Apr 2004 20:19:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDBdl-0001cA-1S; Mon, 12 Apr 2004 20:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDBcy-0001Xd-1r for rddp@optimus.ietf.org; Mon, 12 Apr 2004 20:18:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27115 for ; Mon, 12 Apr 2004 20:18:07 -0400 (EDT) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDBct-0000R5-00 for rddp@ietf.org; Mon, 12 Apr 2004 20:18:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDBRW-0007N7-00 for rddp@ietf.org; Mon, 12 Apr 2004 20:06:23 -0400 Received: from msgbas2x.cos.agilent.com ([192.25.240.37]) by ietf-mx with esmtp (Exim 4.12) id 1BDBEL-0005uq-00 for rddp@ietf.org; Mon, 12 Apr 2004 19:52:45 -0400 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 75B548D58; Mon, 12 Apr 2004 17:52:36 -0600 (MDT) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 59C0F208; Mon, 12 Apr 2004 17:52:36 -0600 (MDT) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Apr 2004 17:52:36 -0600 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] MPA issue (3): Rejected Connection bit Date: Mon, 12 Apr 2004 17:52:35 -0600 Message-ID: Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit Thread-Index: AcQegQ95C7tpsnaNSquiVNUGXyGUFgCZmONw To: , Cc: X-OriginalArrivalTime: 12 Apr 2004 23:52:36.0204 (UTC) FILETIME=[3AF85AC0:01C420E9] 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 There is also another reason that reversion to non-RDMA would not be = useful for iSCSI. The selection of operation over iSER may have = influenced the values that were negotiated for other parameters, e.g. = digests and PDU sizes. If the RDMA connection fails, then those = parameters may be significantly sub-optimal for operation in stream = mode. If the trasition into RDMA connection didn't work, then the iSCSI = would just close the connection. It can try the negotiation again = without offering RDMA operation. Regards, Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Mike Ko Sent: Friday, April 09, 2004 3:02 PM To: Caitlin Bestler Cc: rddp@ietf.org Subject: RE: [rddp] MPA issue (3): Rejected Connection bit The handling of the MPA Request Frame was not considered when the iSER=20 draft was written. But since the decision to enter RDMA mode is made=20 during the iSCSI login phase in stream mode, if the subsequent MPA = Request=20 Frame is invalid, it will be treated as an LLP error and presumably the=20 MPA layer will be instructed to tear the connection down. Mike Sent by: rddp-admin@ietf.org To: "Carrier, John" cc: "Caitlin Bestler" , rddp@ietf.org=20 Subject: RE: [rddp] MPA issue (3): Rejected Connection bit Carrier, John said: > Hi Caitlin, > > Again a clarification: MPA does not send a Reply Frame unless = instructed > to do so by the ULP. If MPA receives an invalid Request Frame, then = it > indicates the error to the ULP but takes no other action of its own. > > My interpretation of what you describe below is that if there is an > invalid Request Frame, there should be no Reply Frame generated. In=20 that > case, MPA would transition to what I called the 'inactive' state after = it > passes the error to the ULP. The result would be that MPA is decoupled > from the TCP stream. The ULP would then, presumably, terminate the > connection. > > right? > Yes, with the understanding that the ULP may have instructed MPA in=20 advance to terminate the connection. But the decision to terminate the = connection should indeed belong to the ULP. Applications using the "connect or using RDMA or bust" APIs currently found in DAT and IT-API would presumably prefer for the TCP connection to be terminated rather than being forced to do a round-trip. Those doing iSER/SDP over iWarp style setup might want their connection back to allow them to continue in non-RDMA mode (even though it is more likely that they negotiated use of RDMA in streaming mode, so a failure to enter RDMA mode would probably still result in terminating the connection -- who wants to deal with a peer that changes their mind that quickly?) _______________________________________________ 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 Wed Apr 14 19:18:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05057 for ; Wed, 14 Apr 2004 19:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtaT-0003RY-Ji for rddp-archive@odin.ietf.org; Wed, 14 Apr 2004 19:14:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ENEXx9013234 for rddp-archive@odin.ietf.org; Wed, 14 Apr 2004 19:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtTs-0001Wh-LA for rddp-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 19:07:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04714 for ; Wed, 14 Apr 2004 19:07:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDtTp-0004Me-00 for rddp-web-archive@ietf.org; Wed, 14 Apr 2004 19:07:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDtSz-0004Ke-00 for rddp-web-archive@ietf.org; Wed, 14 Apr 2004 19:06:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDtSa-0004HY-00 for rddp-web-archive@ietf.org; Wed, 14 Apr 2004 19:06:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtQH-0000g7-4M; Wed, 14 Apr 2004 19:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtN4-00005A-JI for rddp@optimus.ietf.org; Wed, 14 Apr 2004 19:00:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04455 for ; Wed, 14 Apr 2004 19:00:37 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDtN1-0003yq-00 for rddp@ietf.org; Wed, 14 Apr 2004 19:00:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDtM7-0003wJ-00 for rddp@ietf.org; Wed, 14 Apr 2004 18:59:44 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BDtLT-0003qp-00 for rddp@ietf.org; Wed, 14 Apr 2004 18:59:03 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Apr 2004 18:58:25 -0400 Message-ID: To: rddp@ietf.org Date: Wed, 14 Apr 2004 18:58:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] MPA issue (3): Rejected Connection bit - Rough Consensus Sender: rddp-admin@ietf.org Errors-To: rddp-admin@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , 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 Closing this issue out, based on the Seoul meeting and subsequent list discussion, I believe that the rough consensus of the RDDP WG is to include the rejected connection bit in MPA. Any further dissension needs to be posted to the list. 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 ---------------------------------------------------- > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On > Behalf Of Black_David@emc.com > Sent: Monday, March 29, 2004 8:21 PM > To: rddp@ietf.org > Subject: [rddp] MPA issue (3): Rejected Connection bit > > > Moving on to issue (3), the Seoul minutes say: > > (3) Rejected Connection bit. Dissension expressed, this leads to > interoperability issues because it forces a ULP to > interpret private > data to figure out that the connection setup failed, and requires > MPA to handle TCP close specially (more detail in mail to list). > Further discussion: > > Q: If MPA does not do "teardown", why is the bit needed to > free resources at MPA layer? > A: Practically speaking, implementations will allocate and free > resources in MPA (e.g. connection model in kernel), this enables > layering and better control. > A: The bit will prevent some timed-wait resource consumption issues, > if used properly (this is about cooperating systems, not malicious > resource consumption attacks). > > Rough consensus in room to include the bit. Take to list. > > I suggest to the WG that the right thing to do is include this bit > because it produces better behavior in an important error case for > cooperative clients where something is misconfigured. This bit > allows the RDDP layers to immediately know that a connection setup > has failed and release/reuse any resources committed to it without > waiting for a ULP to look at the private data that came back. It > also ties the fact that the connection is closing with the > associated private data unambiguously (both can be immediately > logged at RDDP level). Yes, this is optimizing an error case, > but it seems to be common enough/of sufficient concern to be > worth spending a bit on. That was where the discussion among > the subset of us who were in Seoul wound up. > > Comments? I intend to let the technical discussion run on this > before trying to call consensus on the list. > > Thanks, > --David > > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 14 19:39:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05911 for ; Wed, 14 Apr 2004 19:39:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDty5-0001qj-0U for rddp-archive@odin.ietf.org; Wed, 14 Apr 2004 19:38:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ENcuSK007101 for rddp-archive@odin.ietf.org; Wed, 14 Apr 2004 19:38:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtvs-0000ty-Jx for rddp-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 19:36:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05687 for ; Wed, 14 Apr 2004 19:36:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDtvr-0005jR-00 for rddp-web-archive@ietf.org; Wed, 14 Apr 2004 19:36:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDtuv-0005hX-00 for rddp-web-archive@ietf.org; Wed, 14 Apr 2004 19:35:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDtun-0005fs-00 for rddp-web-archive@ietf.org; Wed, 14 Apr 2004 19:35:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtqP-0007iC-Lg; Wed, 14 Apr 2004 19:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtjH-00065Y-3f for rddp@optimus.ietf.org; Wed, 14 Apr 2004 19:23:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05307 for ; Wed, 14 Apr 2004 19:23:37 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDtjF-000553-00 for rddp@ietf.org; Wed, 14 Apr 2004 19:23:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDtiJ-00052b-00 for rddp@ietf.org; Wed, 14 Apr 2004 19:22:40 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BDthc-0004xQ-00 for rddp@ietf.org; Wed, 14 Apr 2004 19:21:56 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Apr 2004 19:21:27 -0400 Message-ID: To: rddp@ietf.org Date: Wed, 14 Apr 2004 19:21:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] Security draft issue (5) - Protection for shared RQ 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 With the expectation that discussion on (4) [IPsec support] will be lengthy, I'm going to go to (5) and come back to (4). Issue (5) is our old friend, the Shared Receive Queue protection problem, but an interesting solution for this was devised in Seoul. Here is what the minutes have to say on this issue: (5) Need to address "protection for shared RQ" problem. The security draft makes a "valiant" attempt to make it a ULP issue - but can't. Exhaustion of receive buffers is a key attack. Is this the job of each and every ULP, or RDDP's? Probably the latter. OTOH, there is general discomfort with specifying this in a fashion that would require checking it in the fast receive path (e.g., in hardware in a hardware-optimized implementation). Scenario - server mis-implements resource management, bug in one handler drags down others. E.g., a multiprotocol server with busted filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP should not impose non-uniform controls. The goal is to specify a functionality that is guaranteed to exist, though possibly overridable given sufficient trust. Absence of any required control here doesn't line up with the Partial Mutual Trust concept discussed earlier. Proposed approach: Require a default implementation of this protection, as part of the Privileged Resource Manager. Privileged protocols can override it, but the base function is always provided. Does a similar situation exist for CQs? (Response: yes, with suppressed completions, underprovision is desirable!) The current approach in Section 7.5.2 (and subsections) of the security draft that make defending against this class of attacks entirely the responsibility of all applications, including non-privileged ones is not going to be acceptable as non-privileged applications shouldn't have to engage in this sort of defensive resource management. The proposed approach from Seoul is to require implementation of shared resource protection functionality in the privileged resource manager that has to be used by non-privileged apps (e.g., the high-water and low-water notifications would go to the resource manager rather than the application); implementation of this functionality can then be imposed as a responsibility on privileged applications as part of the price of to bypassing/replacing this portion of the privileged resource manager. This should respond to the major concern about keeping this support out of any receive fast path (e.g., in hardware). This would apply to support for shared Receive Queues (7.5.2.1), and shared Completion Queues (7.5.2.3). It would not apply to shared RDMA Read Queues, as 7.5.2.4 already says that RDMA Read Queues SHOULD NOT be shared in a fashion that can create this problem. This is for discussion before I call rough consensus. Comments? 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 Thu Apr 15 01:51:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19449 for ; Thu, 15 Apr 2004 01:51:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzkS-00055a-0o for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 01:49:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F5nFPC019554 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 01:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzjE-0004Zf-0C for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 01:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19317 for ; Thu, 15 Apr 2004 01:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDzjA-0004pc-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 01:47:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDziJ-0004lN-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 01:47:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDzht-0004h4-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 01:46:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzXe-0001SZ-CJ; Thu, 15 Apr 2004 01:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzVQ-0000Mh-6K for rddp@optimus.ietf.org; Thu, 15 Apr 2004 01:33:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18864 for ; Thu, 15 Apr 2004 01:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDzVM-0003nL-00 for rddp@ietf.org; Thu, 15 Apr 2004 01:33:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDzTe-0003lH-00 for rddp@ietf.org; Thu, 15 Apr 2004 01:31:54 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BDzT1-0003iq-00 for rddp@ietf.org; Thu, 15 Apr 2004 01:31:15 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id BDDF811E813; Thu, 15 Apr 2004 01:31:09 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69385-08; Thu, 15 Apr 2004 01:31:09 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id EE53311E82D; Thu, 15 Apr 2004 01:31:08 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 84DA111E828; Thu, 15 Apr 2004 01:31:08 -0400 (EDT) Received: from 82.166.247.237 (proxying for 82.166.247.237) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Thu, 15 Apr 2004 00:31:08 -0500 (CDT) Message-ID: <48595.82.166.247.237.1082007068.squirrel@mail52a.simplicato.com> In-Reply-To: References: Date: Thu, 15 Apr 2004 00:31:08 -0500 (CDT) Subject: Re: [rddp] MPA issue (3): Rejected Connection bit - Rough Consensus From: "Caitlin Bestler" To: Black_David@emc.com Cc: rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable 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,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Black_David@emc.com said: > Closing this issue out, based on the Seoul meeting and > subsequent list discussion, I believe that the rough consensus > of the RDDP WG is to include the rejected connection bit in MPA. > > Any further dissension needs to be posted to the list. > I also believe the consensus is that the state of the TCP connection after the rejection should be under ULP control, meaning it could be automatically disconnected or returned to ULP control. However, I believe it has also been shown that the option to return the TCP connection to the ULP is mostly a theoretical nicety. There is no identified *need* for such a feature. So if anyone put forward a scenario where it was difficult to return the TCP connection then it would probably be agreed to allow the MPA layer to simply terminate the connection after the Reset bit. >From both the perspective of an MPA provider and RDMA Consumer, I prefer the automatic termination. But leaving that decidsion to the ULP is indeed cleaner layering. And barring a real implementation issue I suspect clean layering is the stronger argument. -- 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 Thu Apr 15 02:25:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04196 for ; Thu, 15 Apr 2004 02:25:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0AY-0008R5-Jx for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 02:16:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F6GEFI032422 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 02:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE07Y-0006gA-Pj for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 02:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29825 for ; Thu, 15 Apr 2004 02:13:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE07V-0006Ze-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 02:13:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE06q-0006SP-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 02:12:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE05f-0006Gi-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 02:11:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE02b-0003eC-0G; Thu, 15 Apr 2004 02:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzsl-0006qE-AD for rddp@optimus.ietf.org; Thu, 15 Apr 2004 01:57:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19628 for ; Thu, 15 Apr 2004 01:57:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDzsi-0005Of-00 for rddp@ietf.org; Thu, 15 Apr 2004 01:57:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDzrk-0005Lg-00 for rddp@ietf.org; Thu, 15 Apr 2004 01:56:48 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BDzqo-0005G5-00 for rddp@ietf.org; Thu, 15 Apr 2004 01:55:50 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id BD6A711EC16; Thu, 15 Apr 2004 01:55:39 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74581-05; Thu, 15 Apr 2004 01:55:38 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id A68D311EBFC; Thu, 15 Apr 2004 01:55:38 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 3CA7911EBEC; Thu, 15 Apr 2004 01:55:38 -0400 (EDT) Received: from 82.166.247.237 (proxying for 82.166.247.237) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Thu, 15 Apr 2004 00:55:38 -0500 (CDT) Message-ID: <54009.82.166.247.237.1082008538.squirrel@mail52a.simplicato.com> In-Reply-To: References: Date: Thu, 15 Apr 2004 00:55:38 -0500 (CDT) Subject: Re: [rddp] Security draft issue (5) - Protection for shared RQ From: "Caitlin Bestler" To: rddp@ietf.org Cc: black_david@emc.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable 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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Black_David@emc.com said: > > The proposed approach from Seoul is to require implementation of > shared resource protection functionality in the privileged resource > manager that has to be used by non-privileged apps (e.g., the > high-water and low-water notifications would go to the resource > manager rather than the application); implementation of this > functionality can then be imposed as a responsibility on privileged > applications as part of the price of to bypassing/replacing this > portion of the privileged resource manager. This should respond > to the major concern about keeping this support out of any receive > fast path (e.g., in hardware). > The security draft should be compatible with what I have termed "hard" or per-endpoint limits. Under this approach, which the RDMAC verbs makes the mistake of explicitly forbidding, the RNIC maintains the per-endpoint credit count while still using a shared buffer pool. If an untagged message arrives while the endpoint has no credits it is not allowed to tap the pool, even if the pool has buffers. This prevents the pool from being drained by a single runaway peer. The vulnerability of soft limits is that an asynchronous response is required to respond to a runaway or "one too many" cheating peer. The latter is actually a bigger concern, because it could lead to an arms race if clients feel they *must* cheat by having one extra message in flight because all of the other clients are doing it too. Shifting the response from the user to the Privileged Resource Manager is a step in the correct direction. Presumably the Privileged Resource Manager can respond more promptly and more predictably than the ULP. However, it lacks the discretion of the ULP. If no ULP discretion is involved I would contend that it is more appropriate to delegate all the way to hardware and have the hard limit automatically enforce per-endpoint credit restrictions. With proper enforcement of per-endpoint credits (however synchronous or asynchronous) the end-to-end security issues are solved, leaving only price/performance issues. If I understand your recap correctly, the determination in Seoul was that forcing any ULP that uses shared resources to provide a deterministic guarantee as to how quickly it will process an "over-limit" event is not an acceptable security policy. Actually I agree, but from a standards approach I was more inclined to simply require that it be labeled accurately (with the appropriate euphemism for 'really stupid'). But as long as applications are allowed to be labelled as 'privileged' then system designes will retain their full rights to shoot themselves in the foot, something that all good standards should protect. The important thing is that *some* mechanism provide a deterministic response to over-limit. This mechanism can be automatic disconnect, asynchronous decision by the Privileged Resource Manager, or even asynchronous decision by a ULP that has agreed to guarantee a prompt response. Once we know that a limits can be placed on how much a single peer can drain from the pool, it is a purely local issue on how to provision the pool. The ideal degree of statistical under-provisioning is very dependent on the application and deployoment environment. -- Caitlin Bestler - cait@aosmi.com http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 15 09:25:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22761 for ; Thu, 15 Apr 2004 09:25:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6nH-0001Hd-J7 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 09:20:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDKdMC004925 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 09:20:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6ks-0000Fi-Hb for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:18:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22284 for ; Thu, 15 Apr 2004 09:18:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6kq-00017i-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 09:18:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6jt-00011i-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 09:17:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE6iz-0000xe-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 09:16:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6c2-0005db-Ng; Thu, 15 Apr 2004 09:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6Lg-0006Od-EH for rddp@optimus.ietf.org; Thu, 15 Apr 2004 08:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20570 for ; Thu, 15 Apr 2004 08:52:05 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6Le-00067d-00 for rddp@ietf.org; Thu, 15 Apr 2004 08:52:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6Ki-00064H-00 for rddp@ietf.org; Thu, 15 Apr 2004 08:51:08 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BE6KN-00060u-00 for rddp@ietf.org; Thu, 15 Apr 2004 08:50:47 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Apr 2004 08:50:16 -0400 Message-ID: To: cait@asomi.com, rddp@ietf.org Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ Date: Thu, 15 Apr 2004 08:50:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rddp-admin@ietf.org Errors-To: rddp-admin@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , 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 > Black_David@emc.com said: > > > > > The proposed approach from Seoul is to require implementation of > > shared resource protection functionality in the privileged resource > > manager that has to be used by non-privileged apps (e.g., the > > high-water and low-water notifications would go to the resource > > manager rather than the application); implementation of this > > functionality can then be imposed as a responsibility on privileged > > applications as part of the price of to bypassing/replacing this > > portion of the privileged resource manager. This should respond > > to the major concern about keeping this support out of any receive > > fast path (e.g., in hardware). > > > > The security draft should be compatible with what I have termed > "hard" or per-endpoint limits. That makes a lot of sense - implementers who want to enforce the additional limits in a shared pool should be able to do so. Thanks, --David _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 15 09:56:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24243 for ; Thu, 15 Apr 2004 09:56:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Fo-0003TG-Hb for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 09:50:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDo8ob013327 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 09:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7B1-0001at-DD for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:45:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23605 for ; Thu, 15 Apr 2004 09:45:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Az-0003Xp-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 09:45:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7A8-0003Sn-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 09:44:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE79X-0003Oq-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 09:43:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE71F-0005Ac-6E; Thu, 15 Apr 2004 09:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6up-0003WL-8G for rddp@optimus.ietf.org; Thu, 15 Apr 2004 09:28:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22889 for ; Thu, 15 Apr 2004 09:28:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6un-00026R-00 for rddp@ietf.org; Thu, 15 Apr 2004 09:28:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6tf-000205-00 for rddp@ietf.org; Thu, 15 Apr 2004 09:27:15 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 1BE6t9-0001uj-00 for rddp@ietf.org; Thu, 15 Apr 2004 09:26:43 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.33]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 98C33B352 for ; Thu, 15 Apr 2004 08:26:12 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Apr 2004 08:26:12 -0500 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] Security draft issue (5) - Protection for shared RQ Date: Thu, 15 Apr 2004 08:21:15 -0500 Message-ID: <4D027986353D1341ADA4F2A4F8A170762D913F2B@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] Security draft issue (5) - Protection for shared RQ Thread-Index: AcQieMUeJ5uTCT+rTviXLoTlQ59mWgAcehCA From: "Culley, Paul" To: X-OriginalArrivalTime: 15 Apr 2004 13:26:12.0419 (UTC) FILETIME=[38872130:01C422ED] 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 >=20 > (5) Need to address "protection for shared RQ" problem.=20 >=20 > Scenario - server mis-implements resource management, bug in one > handler drags down others. E.g., a multiprotocol server with busted > filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP > should not impose non-uniform controls.=20 >=20 It should be noted that some of the authors do not expect shared receive queues to be shared between applications. Rather, a single application that must talk to many peers or clients might utilize such a queue. One reason this is desirable is to limit the scope of "partial mutual trust" to the application, another is that applications using a shared receive queue must also have a clear understanding of the size of the buffers on the queue. Users of the SRQ must agree to the size of the largest buffer used, or there will be a failure. Disparate applications would be unlikely to need the same general size of buffers, potentially leading to an inefficient size of buffers being used. If this usage model is agreed upon, I personally believe that the whole SRQ overrun protection problem is ok as it is. Paul R. Culley HP Fellow 281-514-5543=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 15 10:41:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27804 for ; Thu, 15 Apr 2004 10:41:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7vp-0008Pc-8F for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 10:33:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEXXR5032316 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 10:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7k4-00035p-MC for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26771 for ; Thu, 15 Apr 2004 10:21:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7k2-00072L-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:21:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7j3-0006vl-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:20:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7i8-0006q9-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:19:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7ds-0008Id-Ul; Thu, 15 Apr 2004 10:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7QV-0007CS-Kp for rddp@optimus.ietf.org; Thu, 15 Apr 2004 10:01:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24482 for ; Thu, 15 Apr 2004 10:01:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7QT-00055f-00 for rddp@ietf.org; Thu, 15 Apr 2004 10:01:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7Ph-00052G-00 for rddp@ietf.org; Thu, 15 Apr 2004 10:00:21 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BE7PK-0004xL-00 for rddp@ietf.org; Thu, 15 Apr 2004 09:59:58 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id D4BDC11EBE3; Thu, 15 Apr 2004 09:59:47 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78737-03; Thu, 15 Apr 2004 09:59:46 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 9B90D11EB0D; Thu, 15 Apr 2004 09:59:44 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id F0D8D11E9C2; Thu, 15 Apr 2004 09:59:43 -0400 (EDT) Received: from 82.166.247.237 (proxying for 82.166.247.237) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Thu, 15 Apr 2004 08:59:44 -0500 (CDT) Message-ID: <25947.82.166.247.237.1082037584.squirrel@mail52a.simplicato.com> In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762D913F2B@cceexc18.americas.cpqcorp.ne t> References: <4D027986353D1341ADA4F2A4F8A170762D913F2B@cceexc18.americas.cpqcorp.net> Date: Thu, 15 Apr 2004 08:59:44 -0500 (CDT) Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ From: "Caitlin Bestler" To: "Culley, Paul" Cc: rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable 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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Culley, Paul said: >> >> (5) Need to address "protection for shared RQ" problem. >> >> Scenario - server mis-implements resource management, bug in one >> handler drags down others. E.g., a multiprotocol server with busted >> filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP >> should not impose non-uniform controls. >> > It should be noted that some of the authors do not expect shared receiv= e > queues to be shared between applications. Rather, a single application > that must talk to many peers or clients might utilize such a queue. On= e > reason this is desirable is to limit the scope of "partial mutual trust= " > to the application, another is that applications using a shared receive > queue must also have a clear understanding of the size of the buffers o= n > the queue. Users of the SRQ must agree to the size of the largest > buffer used, or there will be a failure. Disparate applications would > be unlikely to need the same general size of buffers, potentially > leading to an inefficient size of buffers being used. > > If this usage model is agreed upon, I personally believe that the whole > SRQ overrun protection problem is ok as it is. > > I agree. Purely local issues about wise sharing of resources are a local issue, and in no way related to iWarp specific issues. The iWarp specific issue directly related to impact of handling out-of-or= der untagged messages against a shared receive queue. With a simple receive queue whatever resources are allocated to deal with a wildly out-of-order untagged buffer are unique to the QP. But because RDMA encourages holding out-of-order messages for later delivery, the claim against the common pool can be both long (because the attacker picked a very advanced MSN) and invisible (because the DDP Layer does not bother the high layers with details on messages that have not yet completed). With simple receive queues the typical solution is to only accept untagged messages within the MSN range implied by the number of receive buffers posted exclusively for that QP. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 15 10:43:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27936 for ; Thu, 15 Apr 2004 10:43:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7wM-00008x-7f for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 10:34:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEY6Tn000536 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 10:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7pc-0005dd-Gv for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27020 for ; Thu, 15 Apr 2004 10:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7pa-0007WM-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:27:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7ob-0007Qk-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:26:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7ne-0007ME-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7dv-0008K6-I0; Thu, 15 Apr 2004 10:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7TQ-00029I-8V for rddp@optimus.ietf.org; Thu, 15 Apr 2004 10:04:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24636 for ; Thu, 15 Apr 2004 10:04:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7TN-0005KT-00 for rddp@ietf.org; Thu, 15 Apr 2004 10:04:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7SX-0005Fm-00 for rddp@ietf.org; Thu, 15 Apr 2004 10:03:18 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Rf-00056s-00 for rddp@ietf.org; Thu, 15 Apr 2004 10:02:24 -0400 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i3FE1nZh015575; Thu, 15 Apr 2004 07:01:49 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i3FE1mt8017250; Thu, 15 Apr 2004 07:01:48 -0700 (PDT) Received: from tmt.netapp.com ([10.97.6.44]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 15 Apr 2004 10:01:45 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C422F2.2FA52A80" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ Date: Thu, 15 Apr 2004 07:01:30 -0700 Message-ID: <6.1.0.6.2.20040415095451.01f6cec0@silver.nane.netapp.com> Thread-Topic: [rddp] Security draft issue (5) - Protection for shared RQ Thread-Index: AcQi8jA/U4qDJxMnTbSfoEnLShoEPg== From: "Talpey, Thomas" To: "Culley, Paul" Cc: 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C422F2.2FA52A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think you're saying that, if the security document constrains shared receive queues in the same way it does RDMA Read queues (i.e. SHOULD NOT be shared among applications), then the draft is OK as-is. But doesn't this mean that any shared RQ must be owned by a privileged consumer? That seems too stringent. I do agree with the notion that applications that share an RQ are themselves related. The issue is leveraging this into a guarantee of system protection. Tom. At 09:21 AM 4/15/2004, Culley, Paul wrote: >>=20 >> (5) Need to address "protection for shared RQ" problem.=20 >>=20 >> Scenario - server mis-implements resource management, bug in one >> handler drags down others. E.g., a multiprotocol server with busted >> filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP >> should not impose non-uniform controls.=20 >>=20 >It should be noted that some of the authors do not expect shared = receive >queues to be shared between applications. Rather, a single application >that must talk to many peers or clients might utilize such a queue. = One >reason this is desirable is to limit the scope of "partial mutual = trust" >to the application, another is that applications using a shared receive >queue must also have a clear understanding of the size of the buffers = on >the queue. Users of the SRQ must agree to the size of the largest >buffer used, or there will be a failure. Disparate applications would >be unlikely to need the same general size of buffers, potentially >leading to an inefficient size of buffers being used. > >If this usage model is agreed upon, I personally believe that the whole >SRQ overrun protection problem is ok as it is. > > >Paul R. Culley >HP Fellow >281-514-5543=20 > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp ------_=_NextPart_001_01C422F2.2FA52A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rddp] Security draft issue (5) - Protection for shared = RQ

I think you're saying that, if the security document = constrains
shared receive queues in the same way it does RDMA = Read
queues (i.e. SHOULD NOT be shared among = applications),
then the draft is OK as-is.

But doesn't this mean that any shared RQ must be owned = by a
privileged consumer? That seems too stringent.

I do agree with the notion that applications that = share an RQ
are themselves related. The issue is leveraging this = into a
guarantee of system protection.

Tom.

At 09:21 AM 4/15/2004, Culley, Paul wrote:
>>
>>   (5) Need to address = "protection for shared RQ" problem.
>>
>>   Scenario - server mis-implements = resource management, bug in one
>>   handler drags down others. E.g., = a multiprotocol server with busted
>>   filesystem component kills HTTP, = etc. "Unsafe by design", i.e. RDDP
>>   should not impose non-uniform = controls.
>>
>It should be noted that some of the authors do = not expect shared receive
>queues to be shared between applications.  = Rather, a single application
>that must talk to many peers or clients might = utilize such a queue.  One
>reason this is desirable is to limit the scope of = "partial mutual trust"
>to the application, another is that applications = using a shared receive
>queue must also have a clear understanding of the = size of the buffers on
>the queue.  Users of the SRQ must agree to = the size of the largest
>buffer used, or there will be a failure.  = Disparate applications would
>be unlikely to need the same general size of = buffers, potentially
>leading to an inefficient size of buffers being = used.
>
>If this usage model is agreed upon, I personally = believe that the whole
>SRQ overrun protection problem is ok as it = is.
>
>
>Paul R. Culley
>HP Fellow
>281-514-5543
>
>_______________________________________________
>rddp mailing list
>rddp@ietf.org
>https://www1.ietf.or= g/mailman/listinfo/rddp

------_=_NextPart_001_01C422F2.2FA52A80-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 15 10:43:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27993 for ; Thu, 15 Apr 2004 10:43:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7zF-0001Al-Nf for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 10:37:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FEb5CG004502 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 10:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7re-0006GH-Og for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:29:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27109 for ; Thu, 15 Apr 2004 10:29:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7rb-0007i8-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:29:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7qm-0007eO-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:28:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7qE-0007ZU-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 10:27:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7fr-0000xm-8G; Thu, 15 Apr 2004 10:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7ZM-0005kF-5o for rddp@optimus.ietf.org; Thu, 15 Apr 2004 10:10:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25415 for ; Thu, 15 Apr 2004 10:10:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7ZJ-0005uz-00 for rddp@ietf.org; Thu, 15 Apr 2004 10:10:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7YT-0005qA-00 for rddp@ietf.org; Thu, 15 Apr 2004 10:09:25 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Xw-0005j0-00 for rddp@ietf.org; Thu, 15 Apr 2004 10:08:52 -0400 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i3FE8IZh016908; Thu, 15 Apr 2004 07:08:18 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i3FE8GY1020075; Thu, 15 Apr 2004 07:08:17 -0700 (PDT) Received: from tmt.netapp.com ([10.97.6.44]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 15 Apr 2004 10:07:14 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C422F2.F3BE9500" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: Re: [rddp] MPA issue (3): Rejected Connection bit - Rough Consensus Date: Thu, 15 Apr 2004 07:06:37 -0700 Message-ID: <6.1.0.6.2.20040415071049.01da8ec0@silver.nane.netapp.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit - Rough Consensus Thread-Index: AcQi8vRHSVY6x7eATZWckQFS4e6LtQ== From: "Talpey, Thomas" To: "Caitlin Bestler" Cc: , 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C422F2.F3BE9500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 01:31 AM 4/15/2004, Caitlin Bestler wrote: >However, I believe it has also been shown that the option to return >the TCP connection to the ULP is mostly a theoretical nicety. There >is no identified *need* for such a feature. So if anyone put forward >a scenario where it was difficult to return the TCP connection then >it would probably be agreed to allow the MPA layer to simply >terminate the connection after the Reset bit. The NFS/RDMA mode of the NFSv4/Session protocol supports a mode where RDMA mode is offered by the client via NFS/TCP exchange, but may be declined by the server (for example, inability to support=20 requested RDMA parameters). Currently, this exchange is handled in TCP mode, but we are examining options which may lead us to also perform it via MPA, using private data and reject. In this case, leaving the session in TCP mode will enhance availability and robustness. While we have no current implementation with this requirement, i.e. we have no proof it is compelling, it is trivially easy for the RDMA provider. Therefore I argue for inclusion of the requirement that the MPA layer return to idle mode. Tom.=20 ------_=_NextPart_001_01C422F2.F3BE9500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [rddp] MPA issue (3): Rejected Connection bit - Rough = Consensus

At 01:31 AM 4/15/2004, Caitlin Bestler wrote:
>However, I believe it has also been shown that = the option to return
>the TCP connection to the ULP is mostly a = theoretical nicety. There
>is no identified *need* for such a feature. So if = anyone put forward
>a scenario where it was difficult to return the = TCP connection then
>it would probably be agreed to allow the MPA = layer to simply
>terminate the connection after the Reset = bit.

The NFS/RDMA mode of the NFSv4/Session protocol = supports a mode
where RDMA mode is offered by the client via NFS/TCP = exchange, but
may be declined by the server (for example, inability = to support
requested RDMA parameters). Currently, this exchange = is handled
in TCP mode, but we are examining options which may = lead us to
also perform it via MPA, using private data and = reject. In this case,
leaving the session in TCP mode will enhance = availability and
robustness.

While we have no current implementation with this = requirement, i.e.
we have no proof it is compelling, it is trivially = easy for the RDMA
provider. Therefore I argue for inclusion of the = requirement that the
MPA layer return to idle mode.

Tom.

------_=_NextPart_001_01C422F2.F3BE9500-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 15 19:10:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08425 for ; Thu, 15 Apr 2004 19:10:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFvH-0007R0-4o for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 19:05:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FN5VDd028578 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 19:05:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFlB-0004yp-0a for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 18:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07190 for ; Thu, 15 Apr 2004 18:55:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFl7-0003tJ-Vy for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 18:55:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFju-0003nK-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 18:53:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEFj9-0003kD-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 18:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFTm-00008A-9N; Thu, 15 Apr 2004 18:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFLB-00064W-Dk for rddp@optimus.ietf.org; Thu, 15 Apr 2004 18:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04583 for ; Thu, 15 Apr 2004 18:28:08 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFL8-0001oY-7e for rddp@ietf.org; Thu, 15 Apr 2004 18:28:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFCn-0000bl-00 for rddp@ietf.org; Thu, 15 Apr 2004 18:19:34 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BEEyl-0006SM-00 for rddp@ietf.org; Thu, 15 Apr 2004 18:05:03 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Apr 2004 18:04:29 -0400 Message-ID: To: paul.culley@hp.com, rddp@ietf.org Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ Date: Thu, 15 Apr 2004 18:04:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rddp-admin@ietf.org Errors-To: rddp-admin@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , 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 Paul, > > (5) Need to address "protection for shared RQ" problem. > > > > Scenario - server mis-implements resource management, bug in one > > handler drags down others. E.g., a multiprotocol server with busted > > filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP > > should not impose non-uniform controls. > > > It should be noted that some of the authors do not expect shared receive > queues to be shared between applications. Rather, a single application > that must talk to many peers or clients might utilize such a queue. One > reason this is desirable is to limit the scope of "partial mutual trust" > to the application, another is that applications using a shared receive > queue must also have a clear understanding of the size of the buffers on > the queue. Users of the SRQ must agree to the size of the largest > buffer used, or there will be a failure. Disparate applications would > be unlikely to need the same general size of buffers, potentially > leading to an inefficient size of buffers being used. > > If this usage model is agreed upon, I personally believe that the whole > SRQ overrun protection problem is ok as it is. We can certainly put in SHOULD NOT text like that for the RDMA READ queue, but that's not the entire story ... The problem here is that there are Partial Mutual Trust (or whatever we wind up calling it) boundaries among clients of a single application using a shared receive queue. In the absence of any enforcement of resource consumption limits among those clients, any client can mount a DoS attack on the others by exhausting the shared receive buffers, causing termination of connections to other clients who have done nothing wrong. Consider the non-RDDP version of the same application coded to a sockets interface, and suppose the client mounts the same DoS attack (sending faster than the application can deal with the data). The result is that data builds up in socket buffers, and the system will defend its socket buffer resource by shrinking TCP windows and the like; the system is likely to slow down under the load, but it won't start arbitrarily terminating client connections for lack of resources. The proposed requirement is that the Privileged Resource Manager contain code sufficient so that a non-RDDP application can be converted to a Non-Privileged RDDP without enabling a DoS attack that disconnects clients or having to write inter-client receive resource protection code. 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 Thu Apr 15 22:53:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21432 for ; Thu, 15 Apr 2004 22:53:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJMn-0008Ny-9M for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 22:46:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G2k90F032229 for rddp-archive@odin.ietf.org; Thu, 15 Apr 2004 22:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJKT-0007tg-1s for rddp-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 22:43:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21053 for ; Thu, 15 Apr 2004 22:43:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEJKP-0003YZ-Me for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 22:43:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJJU-0003VD-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 22:42:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEJIW-0003Qh-00 for rddp-web-archive@ietf.org; Thu, 15 Apr 2004 22:41:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJGs-00079Z-Mc; Thu, 15 Apr 2004 22:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJEl-0006Ok-2M for rddp@optimus.ietf.org; Thu, 15 Apr 2004 22:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20785 for ; Thu, 15 Apr 2004 22:37:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEJEh-00039h-Jj for rddp@ietf.org; Thu, 15 Apr 2004 22:37:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJDp-00036v-00 for rddp@ietf.org; Thu, 15 Apr 2004 22:36:54 -0400 Received: from gavriel.barak.net.il ([212.150.48.102]) by ietf-mx with esmtp (Exim 4.12) id 1BEJDB-00030u-00 for rddp@ietf.org; Thu, 15 Apr 2004 22:36:13 -0400 Received: from [192.168.122.45] ([82.166.6.94]) by gavriel.barak.net.il (InterMail vK.4.04.00.03 201-232-140-20030416 license e5bc39f1001e7dfa47fa92d56cd12779) with ESMTP id <20040416023448.MZSP554.gavriel@[82.166.6.94]>; Fri, 16 Apr 2004 05:34:48 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: paul.culley@hp.com, rddp@ietf.org From: Caitlin Bestler Subject: Re: [rddp] Security draft issue (5) - Protection for shared RQ Date: Fri, 16 Apr 2004 05:35:42 +0300 To: Black_David@emc.com X-Mailer: Apple Mail (2.613) 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.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Apr 16, 2004, at 1:04 AM, Black_David@emc.com wrote: > The proposed requirement is that the Privileged Resource Manager > contain > code sufficient so that a non-RDDP application can be converted to a > Non-Privileged RDDP without enabling a DoS attack that disconnects > clients or having to write inter-client receive resource protection > code. That disconnects *other* clients. Disconnecting the DoS attacker is something you *want* to do. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Apr 16 08:36:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04337 for ; Fri, 16 Apr 2004 08:36:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESSu-0006Zi-UC for rddp-archive@odin.ietf.org; Fri, 16 Apr 2004 08:29:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GCT4Ss025274 for rddp-archive@odin.ietf.org; Fri, 16 Apr 2004 08:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESLE-0005NL-MI for rddp-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 08:21:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03674 for ; Fri, 16 Apr 2004 08:21:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BESLD-0005UZ-DG for rddp-web-archive@ietf.org; Fri, 16 Apr 2004 08:21:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESKG-0005Mq-00 for rddp-web-archive@ietf.org; Fri, 16 Apr 2004 08:20:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BESJT-0005Fx-00 for rddp-web-archive@ietf.org; Fri, 16 Apr 2004 08:19:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESGH-0003xj-N6; Fri, 16 Apr 2004 08:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESBd-0003TF-F8 for rddp@optimus.ietf.org; Fri, 16 Apr 2004 08:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03276 for ; Fri, 16 Apr 2004 08:11:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BESBc-0004H9-DK for rddp@ietf.org; Fri, 16 Apr 2004 08:11:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BESAd-00049O-00 for rddp@ietf.org; Fri, 16 Apr 2004 08:10:12 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1BESA8-00041S-00 for rddp@ietf.org; Fri, 16 Apr 2004 08:09:40 -0400 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i3GC99Zh013248 for ; Fri, 16 Apr 2004 05:09:09 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i3GC99Nm029235 for ; Fri, 16 Apr 2004 05:09:09 -0700 (PDT) Received: from tmt.netapp.com ([10.97.6.30]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 Apr 2004 08:09:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423AB.9B979980" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: Re: [rddp] Security draft issue (5) - Protection for shared RQ Date: Fri, 16 Apr 2004 05:07:18 -0700 Message-ID: <6.1.0.6.2.20040416071848.01d37438@silver.nane.netapp.com> Thread-Topic: [rddp] Security draft issue (5) - Protection for shared RQ Thread-Index: AcQjq5xG5dCN2NEvRFWQkYqxn8kfHg== From: "Talpey, Thomas" To: 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C423AB.9B979980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 01:55 AM 4/15/2004, Caitlin Bestler wrote: >The security draft should be compatible with what I have termed >"hard" or per-endpoint limits. > >Under this approach, which the RDMAC verbs makes the mistake >of explicitly forbidding, the RNIC maintains the per-endpoint >credit count while still using a shared buffer pool. > >If an untagged message arrives while the endpoint has no credits >it is not allowed to tap the pool, even if the pool has buffers. This >prevents the pool from being drained by a single runaway peer. I agree that a hard limit should be supported, in addition to the notification method. There are many other implementation possibilities, but perhaps adding the following normative statements to rddp-security 7.5.2.1: "The implementation MUST enforce per-endpoint limits on drawing resources from shared receive queues for nonprivileged consumers. The implementation MAY choose to place these resources under the control of another local method." Followed by the informative: "A simple method to implement the limit, is for the PRM to limit the size of receive queues of endpoints which are linked to shared RQs when no suitable local trust is established for the Application. In this simple method, the endpoint will be terminated if and when it overdraws its "allocation", due to overflowing its receive queue. "Implementing this method in the RNIC, however, requires additional state to be tracked on a per-endpoint basis. Therefore, the PRM may choose to implement equivalent resource protection via a default notification method, rather than in the RNIC. "The PRM may then allow an Application which it deems trustworthy, to set up its own notification method for a shared queue, thereby passing control of resource allocation and limits for that queue to the Application." Following, there are bunches of text existing in rddp-security 7.5.2.1 which provide further detail. Note however, that the first preceding paragraph is not compatible with draft-hilland section 6.3.7, in the nonprivileged case. Tom. ------_=_NextPart_001_01C423AB.9B979980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [rddp] Security draft issue (5) - Protection for shared = RQ

At 01:55 AM 4/15/2004, Caitlin Bestler wrote:
>The security draft should be compatible with what = I have termed
>"hard" or per-endpoint limits.
>
>Under this approach, which the RDMAC verbs makes = the mistake
>of explicitly forbidding, the RNIC maintains the = per-endpoint
>credit count while still using a shared buffer = pool.
>
>If an untagged message arrives while the endpoint = has no credits
>it is not allowed to tap the pool, even if the = pool has buffers. This
>prevents the pool from being drained by a single = runaway peer.

I agree that a hard limit should be supported, in = addition to the
notification method.

There are many other implementation possibilities, but = perhaps
adding the following normative statements to = rddp-security 7.5.2.1:

"The implementation MUST enforce per-endpoint = limits on drawing
resources from shared receive queues for = nonprivileged consumers.
The implementation MAY choose to place these = resources under
the control of another local method."

Followed by the informative:

"A simple method to implement the limit, is for = the PRM to limit the
size of receive queues of endpoints which are linked = to shared RQs
when no suitable local trust is established for the = Application. In
this simple method, the endpoint will be terminated = if and when
it overdraws its "allocation", due to = overflowing its receive queue.

"Implementing this method in the RNIC, however, = requires additional
state to be tracked on a per-endpoint basis. = Therefore, the PRM
may choose to implement equivalent resource = protection via a
default notification method, rather than in the = RNIC.

"The PRM may then allow an Application which it = deems trustworthy,
to set up its own notification method for a shared = queue, thereby
passing control of resource allocation and limits for = that queue
to the Application."

Following, there are bunches of text existing in = rddp-security 7.5.2.1
which provide further detail.

Note however, that the first preceding paragraph is = not compatible
with draft-hilland section 6.3.7, in the = nonprivileged case.

Tom.

------_=_NextPart_001_01C423AB.9B979980-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon Apr 19 15:52:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05619 for ; Mon, 19 Apr 2004 15:52:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFenQ-0007X4-QF for rddp-archive@odin.ietf.org; Mon, 19 Apr 2004 15:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JJpCWD028947 for rddp-archive@odin.ietf.org; Mon, 19 Apr 2004 15:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeZ2-0004ky-JW for rddp-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 15:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04556 for ; Mon, 19 Apr 2004 15:36:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeZ1-0001FE-2L for rddp-web-archive@ietf.org; Mon, 19 Apr 2004 15:36:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeY3-00010v-00 for rddp-web-archive@ietf.org; Mon, 19 Apr 2004 15:35:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFeXa-0000ng-00 for rddp-web-archive@ietf.org; Mon, 19 Apr 2004 15:34:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeSy-0003jH-Vk; Mon, 19 Apr 2004 15:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeRJ-000389-1h for rddp@optimus.ietf.org; Mon, 19 Apr 2004 15:28:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04041 for ; Mon, 19 Apr 2004 15:28:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeRH-000742-Ib for rddp@ietf.org; Mon, 19 Apr 2004 15:28:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeQL-0006ov-00 for rddp@ietf.org; Mon, 19 Apr 2004 15:27:22 -0400 Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx with esmtp (Exim 4.12) id 1BFePd-0006Rb-00 for rddp@ietf.org; Mon, 19 Apr 2004 15:26:37 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i3JHQ5g09724; Mon, 19 Apr 2004 10:26:05 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i3JJQ5i18585; Mon, 19 Apr 2004 12:26:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42644.288812FA" Subject: RE: [rddp] MPA issue (3): Rejected Connection bit - Rough Consensus Date: Mon, 19 Apr 2004 12:26:05 -0700 Message-ID: <59C7D667A0EADB45866C62DD1B55A0FD0223F2E3@aime2k02.adaptec.com> Thread-Topic: [rddp] MPA issue (3): Rejected Connection bit - Rough Consensus Thread-Index: AcQi8vRHSVY6x7eATZWckQFS4e6LtQDUHJJA From: "Carrier, John" To: "Talpey, Thomas" Cc: , , "Caitlin Bestler" 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_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42644.288812FA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tom, =20 If by 'idle' mode, you mean that MPA is no longer consuming the TCP = stream (what I think I called 'inactive' mode), then I agree. =20 If we specify a return to this 'idle' mode, as Tom suggests, then after = MPA sends the reply frame with the rejected bit set, the next step is = under ULP control. MPA only actively terminates the connection for an = invalid Request or Reply frame. MPA has no other active role in = connection termination (eg, once in full MPA mode, if there are errors = in the FPDUs, MPA reports the error to DDP and DDP is responsible for = closing the connection). =20 During connection startup, after MPA has sent the Reply frame with the = rejected bit set, the ULP at the MPA Responder can do one of the = following: =20 * keep the connection in TCP only mode,=20 * terminate the connection, or * re-start MPA mode (ie enable MPA to receive another Request frame) =20 To keep the two half-connections symmetrical, the MPA Initiator should = also transition to 'idle' mode after it has received a Reply frame with = the rejected bit set. The ULP at the initiator can then do one of the = following: =20 * keep the connection in TCP only mode * terminate the connection, or * re-start MPA mode by sending another MPA Request frame =20 I don't have a usage model in mind, so does this make sense? =20 --jc -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of = Talpey, Thomas Sent: Thursday, April 15, 2004 7:07 AM To: Caitlin Bestler Cc: Black_David@emc.com; rddp@ietf.org Subject: Re: [rddp] MPA issue (3): Rejected Connection bit - Rough = Consensus At 01:31 AM 4/15/2004, Caitlin Bestler wrote:=20 >However, I believe it has also been shown that the option to return=20 >the TCP connection to the ULP is mostly a theoretical nicety. There=20 >is no identified *need* for such a feature. So if anyone put forward=20 >a scenario where it was difficult to return the TCP connection then=20 >it would probably be agreed to allow the MPA layer to simply=20 >terminate the connection after the Reset bit.=20 The NFS/RDMA mode of the NFSv4/Session protocol supports a mode=20 where RDMA mode is offered by the client via NFS/TCP exchange, but=20 may be declined by the server (for example, inability to support=20 requested RDMA parameters). Currently, this exchange is handled=20 in TCP mode, but we are examining options which may lead us to=20 also perform it via MPA, using private data and reject. In this case,=20 leaving the session in TCP mode will enhance availability and=20 robustness.=20 While we have no current implementation with this requirement, i.e.=20 we have no proof it is compelling, it is trivially easy for the RDMA=20 provider. Therefore I argue for inclusion of the requirement that the=20 MPA layer return to idle mode.=20 Tom.=20 ------_=_NextPart_001_01C42644.288812FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [rddp] MPA issue (3): Rejected Connection bit - Rough = Consensus
Hi Tom,
 
If by 'idle' mode, you mean that MPA is no = longer=20 consuming the TCP stream (what I think I called 'inactive' mode), then I = agree.
 
If we specify a return to = this 'idle'=20 mode, as Tom suggests, then after MPA sends the reply frame with the = rejected=20 bit set, the next step is under ULP control.  MPA only actively = terminates=20 the connection for an invalid Request or Reply frame.  MPA has no = other=20 active role in connection termination (eg, once in full MPA mode, if = there are=20 errors in the FPDUs, MPA reports the error to DDP and DDP is responsible = for=20 closing the connection).
 
During connection startup, after MPA has sent the Reply = frame with=20 the rejected bit set, the ULP at the MPA Responder can do one of the=20 following:
 
* keep the connection in TCP only mode,
* terminate the connection, or
* re-start MPA mode (ie enable MPA to receive another Request=20 frame)
 
To keep the two half-connections = symmetrical, the MPA=20 Initiator should also transition to 'idle' mode after it has received a=20 Reply frame with the rejected bit set.  The ULP at the initiator can then do one of = the=20 following:
 
* keep = the connection=20 in TCP only mode
* = terminate the=20 connection, or
* = re-start MPA mode by=20 sending another MPA Request = frame
 
I don't = have a usage=20 model in mind, so does this make = sense?
 
--jc
-----Original Message-----
From: = rddp-admin@ietf.org=20 [mailto:rddp-admin@ietf.org]On Behalf Of Talpey, = Thomas
Sent:=20 Thursday, April 15, 2004 7:07 AM
To: Caitlin = Bestler
Cc:=20 Black_David@emc.com; rddp@ietf.org
Subject: Re: [rddp] MPA = issue=20 (3): Rejected Connection bit - Rough = Consensus

At 01:31 AM 4/15/2004, Caitlin Bestler wrote: =
>However, I believe it has also been shown that the option = to=20 return
>the TCP connection to the ULP is = mostly a=20 theoretical nicety. There
>is no = identified *need*=20 for such a feature. So if anyone put forward
>a=20 scenario where it was difficult to return the TCP connection = then=20
>it would probably be agreed to allow the MPA = layer to=20 simply
>terminate the connection after = the Reset=20 bit.

The NFS/RDMA mode of the NFSv4/Session protocol = supports a=20 mode
where RDMA mode is offered by the = client via=20 NFS/TCP exchange, but
may be declined by the = server=20 (for example, inability to support
requested = RDMA=20 parameters). Currently, this exchange is handled
in=20 TCP mode, but we are examining options which may lead us to =
also perform it via MPA, using private data and reject. In = this=20 case,
leaving the session in TCP mode will = enhance=20 availability and
robustness.

While we have no current implementation with this = requirement,=20 i.e.
we have no proof it is compelling, it = is=20 trivially easy for the RDMA
provider. = Therefore I=20 argue for inclusion of the requirement that the
MPA=20 layer return to idle mode.

Tom.

------_=_NextPart_001_01C42644.288812FA-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon Apr 19 16:32:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08028 for ; Mon, 19 Apr 2004 16:32:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfKl-0006ed-7p for rddp-archive@odin.ietf.org; Mon, 19 Apr 2004 16:25:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JKPdjv025575 for rddp-archive@odin.ietf.org; Mon, 19 Apr 2004 16:25:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf8z-0003Yj-VR for rddp-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 16:13:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06782 for ; Mon, 19 Apr 2004 16:13:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFf8y-0002Vi-7R for rddp-web-archive@ietf.org; Mon, 19 Apr 2004 16:13:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFf7z-0002FH-00 for rddp-web-archive@ietf.org; Mon, 19 Apr 2004 16:12:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFf7L-00020a-00 for rddp-web-archive@ietf.org; Mon, 19 Apr 2004 16:11:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeoM-0007rq-Lf; Mon, 19 Apr 2004 15:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFemV-0007D7-Id for rddp@optimus.ietf.org; Mon, 19 Apr 2004 15:50:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05380 for ; Mon, 19 Apr 2004 15:50:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFemT-0004d5-SU for rddp@ietf.org; Mon, 19 Apr 2004 15:50:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFelX-0004Jr-00 for rddp@ietf.org; Mon, 19 Apr 2004 15:49:17 -0400 Received: from sphere.barak.net.il ([212.150.48.98]) by ietf-mx with esmtp (Exim 4.12) id 1BFekb-0003sI-00 for rddp@ietf.org; Mon, 19 Apr 2004 15:48:17 -0400 Received: from [192.168.122.45] ([82.166.6.94]) by sphere.barak.net.il (InterMail vK.4.04.00.00 201-232-137 license e5bc39f1001e7dfa47fa92d56cd12779) with ESMTP id <20040419194655.SGJF12661.sphere@[82.166.6.94]>; Mon, 19 Apr 2004 22:46:55 +0300 In-Reply-To: <59C7D667A0EADB45866C62DD1B55A0FD0223F2E3@aime2k02.adaptec.com> References: <59C7D667A0EADB45866C62DD1B55A0FD0223F2E3@aime2k02.adaptec.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1017643881 Message-Id: <69DE3A6E-923A-11D8-829A-000393814604@asomi.com> Cc: , "Talpey, Thomas" , From: Caitlin Bestler Subject: Re: [rddp] MPA issue (3): Rejected Connection bit - Rough Consensus Date: Mon, 19 Apr 2004 22:47:38 +0300 To: "Carrier, John" X-Mailer: Apple Mail (2.613) 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.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 --Apple-Mail-1-1017643881 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Apr 19, 2004, at 10:26 PM, Carrier, John wrote: > > =A0 > If by 'idle' mode, you mean that MPA is no longer consuming the > TCP stream (what I think I called 'inactive' mode), then I agree. > =A0 > If we specify a return to this 'idle' mode, as Tom suggests, then > after MPA sends the reply frame with the rejected bit set, the > next step is under ULP control.=A0 MPA only actively terminates the > connection for an invalid Request or Reply frame.=A0 MPA has no other > active role in connection termination (eg, once in full MPA mode, > if there are errors in the FPDUs, MPA reports the error to DDP and > DDP is responsible for closing the connection). > > =A0 > During connection startup, after=A0MPA has sent the Reply frame with > the rejected bit set, the ULP at the MPA=A0Responder=A0can do one of > the following: > =A0 > * keep the connection in TCP only mode, > * terminate the connection, or > * re-start MPA mode (ie enable MPA to receive another Request frame) > =A0 > To keep the two half-connections symmetrical, the MPA Initiator should > also transition to 'idle' mode after it has received=A0a Reply frame = with > the rejected bit set.=A0=A0The ULP at the initiator can then do one of = the > following: > =A0 > * keep the connection in TCP only mode > * terminate the connection, or > * re-start MPA mode by sending another MPA Request frame > =A0 > I don't have a usage model in mind, so does this make sense? If you add the caveat that the ULP may (and quite frequently will)=20 exercise the local interface to instruct the MPA mode to terminate the TCP=20 connection immediately if MPA mode cannot be entered. It is a purely local matter, but it may save a user/kernel round-trip,=20= so we don't want to imply that the local interface should avoid offering such an option. "RDMA or bust" protocols would use this. "Optional RDMA" protocols=20 currently negotiate RDMA in pure streaming mode, and then hence are "RDMA or bust" once they make that decision. Tom's earlier post essentially said that=20= had a back-out from RDMA entry been present in the MPA Private Data exchange from the=20= very beginning, that the NFS over RDMA draft might well have made use of it=20= -- and presumably future ULPs could find such a capability useful. --Apple-Mail-1-1017643881 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 19, 2004, at 10:26 PM, Carrier, John wrote: =A0 Courier = New8080,0000,8080If by 'idle' mode, you mean that MPA is no longer consuming = the Courier = New8080,0000,8080TCP stream (what I think I called 'inactive' mode), then I = agree. =A0 Courier = New8080,0000,8080If we specify a return to this 'idle' mode, as Tom suggests, = then Courier = New8080,0000,8080after MPA sends the reply frame with the rejected bit set, = the Courier = New8080,0000,8080next step is under ULP control.=A0 MPA only actively terminates = the Courier = New8080,0000,8080connection for an invalid Request or Reply frame.=A0 MPA has no = other Courier = New8080,0000,8080active role in connection termination (eg, once in full MPA = mode, Courier = New8080,0000,8080if there are errors in the FPDUs, MPA reports the error to DDP = and Courier = New8080,0000,8080DDP is responsible for closing the = connection). =A0 Courier = New8080,0000,8080During connection startup, after=A0MPA has sent the Reply frame = with Courier = New8080,0000,8080the rejected bit set, the ULP at the MPA=A0Responder=A0can do one = of Courier = New8080,0000,8080the following: =A0 Courier = New8080,0000,8080* keep the connection in TCP only = mode, Courier = New8080,0000,8080 * terminate the connection, or Courier = New8080,0000,8080* re-start MPA mode (ie enable MPA to receive another Request = frame) =A0 Courier = New8080,0000,8080To keep the two half-connections symmetrical, the MPA Initiator = should Courier = New8080,0000,8080also transition to 'idle' mode after it has received=A0a Reply frame = with Courier = New8080,0000,8080the rejected bit set.=A0=A0The ULP at the initiator can then do one of = the Courier = New8080,0000,8080following: =A0 Courier = New8080,0000,8080* keep the connection in TCP only = mode Courier = New8080,0000,8080* terminate the connection, or Courier = New8080,0000,8080* re-start MPA mode by sending another MPA Request = frame =A0 Courier = New8080,0000,8080I don't have a usage model in mind, so does this make sense? If you add the caveat that the ULP may (and quite frequently will) exercise the local interface to instruct the MPA mode to terminate the TCP connection immediately if MPA mode cannot be entered. It is a purely local matter, but it may save a user/kernel round-trip, so we don't want to imply that the local interface should avoid offering such an option. "RDMA or bust" protocols would use this. "Optional RDMA" protocols currently negotiate RDMA in pure streaming mode, and then hence are "RDMA or bust" once they make that decision. Tom's earlier post essentially said that had a back-out from RDMA entry been present in the MPA Private Data exchange from the very beginning, that the NFS over RDMA draft might well have made use of it --=20 and presumably future ULPs could find such a capability useful. --Apple-Mail-1-1017643881-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 21 19:41:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01190 for ; Wed, 21 Apr 2004 19:41:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRAo-00038r-Kv for rddp-archive@odin.ietf.org; Wed, 21 Apr 2004 19:30:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LNUYmH012073 for rddp-archive@odin.ietf.org; Wed, 21 Apr 2004 19:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQrA-0000Nq-63 for rddp-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 19:10:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28833 for ; Wed, 21 Apr 2004 19:10:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQr6-0002bj-T5 for rddp-web-archive@ietf.org; Wed, 21 Apr 2004 19:10:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQq9-0002OV-00 for rddp-web-archive@ietf.org; Wed, 21 Apr 2004 19:09:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQpA-00029m-00 for rddp-web-archive@ietf.org; Wed, 21 Apr 2004 19:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQXF-0006WO-4k; Wed, 21 Apr 2004 18:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQEd-0004GZ-BJ for rddp@optimus.ietf.org; Wed, 21 Apr 2004 18:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24787 for ; Wed, 21 Apr 2004 18:30:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQEa-0000zs-Bp for rddp@ietf.org; Wed, 21 Apr 2004 18:30:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQA6-0007k9-00 for rddp@ietf.org; Wed, 21 Apr 2004 18:25:47 -0400 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 1BGQ4H-0006Uh-00 for rddp@ietf.org; Wed, 21 Apr 2004 18:19:45 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.35]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 358341D6A for ; Wed, 21 Apr 2004 17:19:11 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Apr 2004 17:19:11 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ Date: Thu, 15 Apr 2004 08:21:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <4D027986353D1341ADA4F2A4F8A170762D913F2B@cceexc18.americas.cpqcorp.net> X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [rddp] Security draft issue (5) - Protection for shared RQ Thread-Index: AcQieMUeJ5uTCT+rTviXLoTlQ59mWgAcehCA From: "Culley, Paul" To: X-OriginalArrivalTime: 21 Apr 2004 22:19:11.0222 (UTC) FILETIME=[ABDBB960:01C427EE] 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,DATE_IN_PAST_96_XX autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > (5) Need to address "protection for shared RQ" problem.=20 >=20 > Scenario - server mis-implements resource management, bug in one > handler drags down others. E.g., a multiprotocol server with busted > filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP > should not impose non-uniform controls.=20 >=20 It should be noted that some of the authors do not expect shared receive queues to be shared between applications. Rather, a single application that must talk to many peers or clients might utilize such a queue. One reason this is desirable is to limit the scope of "partial mutual trust" to the application, another is that applications using a shared receive queue must also have a clear understanding of the size of the buffers on the queue. Users of the SRQ must agree to the size of the largest buffer used, or there will be a failure. Disparate applications would be unlikely to need the same general size of buffers, potentially leading to an inefficient size of buffers being used. If this usage model is agreed upon, I personally believe that the whole SRQ overrun protection problem is ok as it is. Paul R. Culley HP Fellow 281-514-5543=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Apr 22 18:36:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08832 for ; Thu, 22 Apr 2004 18:36:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmeD-0007SG-Ty for rddp-archive@odin.ietf.org; Thu, 22 Apr 2004 18:26:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMQLgi028642 for rddp-archive@odin.ietf.org; Thu, 22 Apr 2004 18:26:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmG2-0008FT-KK for rddp-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05023 for ; Thu, 22 Apr 2004 18:01:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmFx-0004A6-Tt for rddp-web-archive@ietf.org; Thu, 22 Apr 2004 18:01:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmEv-0003pc-00 for rddp-web-archive@ietf.org; Thu, 22 Apr 2004 18:00:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmDr-0003N5-00 for rddp-web-archive@ietf.org; Thu, 22 Apr 2004 17:59:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlvU-0006E2-SA; Thu, 22 Apr 2004 17:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGktm-0005YL-1j for rddp@optimus.ietf.org; Thu, 22 Apr 2004 16:34:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27524 for ; Thu, 22 Apr 2004 16:34:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGkti-0001w9-1t for rddp@ietf.org; Thu, 22 Apr 2004 16:34:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGksv-0001h3-00 for rddp@ietf.org; Thu, 22 Apr 2004 16:33:26 -0400 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BGksH-0001Qs-00 for rddp@ietf.org; Thu, 22 Apr 2004 16:32:45 -0400 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id AC2E26E0072; Thu, 22 Apr 2004 16:33:50 -0400 From: "Barry Reinhold" To: "RDDP" Date: Thu, 22 Apr 2004 16:32:39 -0400 Message-ID: <003301c428a8$f76d51d0$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.1409 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [rddp] Meaning of preceding 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 Questions on DDP receiver Assume a DDP receiver has a set of buffers "associated with" MSN 0,1,2,3,4 and 5. (unexpected association for MSN 0) for a given constant QN. Question 1: If the first DDP segment that arrives has MSN = 0 (no TCP sequence gap, violation of initial MSN rule) does the receiver: (1) Place and deliver, (2) place and hold, (3) signal error to ULP. Question 2: If MSN 1 has been received, and the next MSN is 3 (with no TCP sequence gap, sender protocol error) what is the receiver's expected behavior? The issue here is that the tests of section 9.1 appear to allow placement for the above two situations. Further the delivery conditions of section 7.4 use the word "preceding", which up to this point I have assumed to be understood in TCP sequence number space. If those are the only two conditions then it seems like DDP should "deliver" for both questions 1 and questions 2. However if "preceding", for untagged buffers, is based on MSN number then delivery would not be valid. So, the bottom line question is - does the receiver have to track the first missing MSN to determine message delivery? 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 Apr 22 23:36:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24582 for ; Thu, 22 Apr 2004 23:36:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrNx-0005w6-DI for rddp-archive@odin.ietf.org; Thu, 22 Apr 2004 23:29:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N3TrNi022818 for rddp-archive@odin.ietf.org; Thu, 22 Apr 2004 23:29:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrIC-0004Aj-Oe for rddp-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 23:23:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23925 for ; Thu, 22 Apr 2004 23:23:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGrI8-0006HM-Sh for rddp-web-archive@ietf.org; Thu, 22 Apr 2004 23:23:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGrH1-0005yD-00 for rddp-web-archive@ietf.org; Thu, 22 Apr 2004 23:22:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGrGD-0005gD-00 for rddp-web-archive@ietf.org; Thu, 22 Apr 2004 23:21:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGr16-00076l-0j; Thu, 22 Apr 2004 23:06:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqug-0004wL-LQ for rddp@optimus.ietf.org; Thu, 22 Apr 2004 22:59:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22840 for ; Thu, 22 Apr 2004 22:59:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqub-000021-0n for rddp@ietf.org; Thu, 22 Apr 2004 22:59:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqtd-0007Zu-00 for rddp@ietf.org; Thu, 22 Apr 2004 22:58:34 -0400 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1BGqtB-0007GZ-00 for rddp@ietf.org; Thu, 22 Apr 2004 22:58:05 -0400 Received: from fid4.com (h006097296569.ne.client2.attbi.com[24.128.217.183]) by comcast.net (rwcrmhc11) with SMTP id <20040423025732013004j774e> (Authid: m.cambria); Fri, 23 Apr 2004 02:57:33 +0000 Message-ID: <40888574.1070300@fid4.com> Date: Thu, 22 Apr 2004 22:54:44 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RDDP CC: Barry Reinhold Subject: Re: [rddp] Meaning of preceding References: <003301c428a8$f76d51d0$467fa8c0@i8600> In-Reply-To: <003301c428a8$f76d51d0$467fa8c0@i8600> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: > Questions on DDP receiver > > Assume a DDP receiver has a set of buffers "associated with" MSN > 0,1,2,3,4 and 5. (unexpected association for MSN 0) for a given constant > QN. > > Question 1: > > If the first DDP segment that arrives has MSN = 0 (no TCP sequence gap, > violation of initial MSN rule) does the receiver: (1) Place and deliver, > (2) place and hold, (3) signal error to ULP. Assuming you are referring to the start of a connection (e.g. not wrapping from MSN 0xffffffff to 0), wouldn't this be covered by: 5. The Message Sequence Number falls in the range of legal Message Sequence Numbers, for the queue defined by the QN. The legal range is defined as being between the MSN value assigned to the first available buffer for a specific QN and the MSN value assigned to the last available buffer for a specific QN. A compliant receiver starts their range at MSN=1 for the first buffer, MSN=2 for the next etc., so MSN=0 is out of range. An error should be signaled to ULP since (top of 9.1) "...the DDP Segment MUST be validated before Placement" > Question 2: > > If MSN 1 has been received, and the next MSN is 3 (with no TCP sequence > gap, sender protocol error) what is the receiver's expected behavior? In this case, your questions re placement & delivery make a good point. When looking for text in section 9 regarding what to do, I found nothing re MSN ordering other than that quote above regarding range. I also found no error code for something like "unexpected MSN". Section 7.3 only says: At the Data Source, DDP: * MUST transmit DDP Messages in the order they were submitted to the DDP layer, The MSN definition in section 4.3 does state that the MSN increases with each DDP message. Other than intuition, nothing is explicitly said about the "next" MSN must/should be used by the sender. The receiver will find MSN 3 in your example to be "in range" with available buffers and as I read things, place it, unless there is text I'm (hopefully) missing. If this isn't meant to be allowed, perhaps another test in sec 9 could be added to make this explicit. MikeC _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Apr 23 05:07:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23565 for ; Fri, 23 Apr 2004 05:07:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwcT-0003TP-8v for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 05:05:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N95DfS013349 for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 05:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwVL-0001kT-HI for rddp-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 04:57:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23229 for ; Fri, 23 Apr 2004 04:57:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGwVG-0004Hw-C3 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 04:57:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwUN-00041G-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 04:56:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGwTQ-0003kV-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 04:55:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwQh-0000Pm-6D; Fri, 23 Apr 2004 04:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwNc-0007ml-6s for rddp@optimus.ietf.org; Fri, 23 Apr 2004 04:49:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22766 for ; Fri, 23 Apr 2004 04:49:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGwNX-0001yl-3g for rddp@ietf.org; Fri, 23 Apr 2004 04:49:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwMb-0001jc-00 for rddp@ietf.org; Fri, 23 Apr 2004 04:48:50 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BGwMD-0001TU-00 for rddp@ietf.org; Fri, 23 Apr 2004 04:48:25 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id DDCDE11E78B; Fri, 23 Apr 2004 04:48:05 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85051-07; Fri, 23 Apr 2004 04:48:04 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 034D611E719; Fri, 23 Apr 2004 04:48:04 -0400 (EDT) Received: from webmail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 5CC4311E066; Fri, 23 Apr 2004 04:48:03 -0400 (EDT) Received: from 82.166.251.29 (proxying for 82.166.251.29) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Fri, 23 Apr 2004 03:48:03 -0500 (CDT) Message-ID: <22768.82.166.251.29.1082710083.squirrel@mail52a.simplicato.com> In-Reply-To: <003301c428a8$f76d51d0$467fa8c0@i8600> References: <003301c428a8$f76d51d0$467fa8c0@i8600> Date: Fri, 23 Apr 2004 03:48:03 -0500 (CDT) Subject: Re: [rddp] Meaning of preceding From: "Caitlin Bestler" To: "Barry Reinhold" Cc: "RDDP" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable 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=1.3 required=5.0 tests=AWL,NO_OBLIGATION, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry Reinhold said: > Questions on DDP receiver > > Assume a DDP receiver has a set of buffers "associated with" MSN > 0,1,2,3,4 and 5. (unexpected association for MSN 0) for a given constan= t > QN. > > Question 1: > > If the first DDP segment that arrives has MSN =3D 0 (no TCP sequence ga= p, > violation of initial MSN rule) does the receiver: (1) Place and deliver= , > (2) place and hold, (3) signal error to ULP. > The expected MSN window would be at 1 (since the receiver has completed no prior receive operations). Therefore MSN 0 is 2**32 messages in the future. I do not believe that more than 2**31 messages could be in flight with any known LLP. The SCTP mapping explicitly limits this, and it is implicitly limited by the number of bytes that can be in-flight for TCP. More importantly, it is highly unlikely that the receiving ULP has made anywhere near that many buffers available. The legal range of MSNs is defined by the base and the number of available buffers. What is "available" gets tricky if the local interface uses SRQs, but resolving that is a local issue. > Question 2: > > If MSN 1 has been received, and the next MSN is 3 (with no TCP sequence > gap, sender protocol error) what is the receiver's expected behavior? > I presume you mean that there is no gap in the LLP sequencing between MSN 1 and MSN 3. In that case the receiver should, at some point, determine that MSN 2 will never arrive, and teardown the connection. MSN 3 may have been placed before the error condition can be noted, but obviously not completed. I am not aware of any language that requires the receiver to *promptly* note this condition. As that the only damage is hanging the connection where the mistake was made, simply waiting for things to time-out would strike me as acceptable. The sender is in violation. The receiver MUST protect itself, but is under no obligation to provide prompt courteous diagnostics. Of course it is very nice of it to do so. It should also be noted that when checking for this condition under SCTP that the adaptation layer's stream sequence number (which represents the stream specific order of *submission* to the sending LLP) must be used. Cheking using the TSN, can result in a mistaken ordering. It is legal for the SCTP TSN for the chunk containing MSN n to be earlier than for the chunk containing MSN n+1 because the sending SCTP stack is allowed to re-order chunks to optimize bundling. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Apr 23 13:57:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23495 for ; Fri, 23 Apr 2004 13:57:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4oQ-0000od-2z for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 13:50:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NHo63N003135 for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 13:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4b3-0004fC-8c for rddp-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 13:36:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22443 for ; Fri, 23 Apr 2004 13:36:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4b1-0002HO-2L for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 13:36:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4Zs-00020m-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 13:35:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4Yr-0001cY-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 13:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4U3-0002qK-Pz; Fri, 23 Apr 2004 13:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4PV-0001h8-UR for rddp@optimus.ietf.org; Fri, 23 Apr 2004 13:24:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21680 for ; Fri, 23 Apr 2004 13:24:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4PT-0006z1-SS for rddp@ietf.org; Fri, 23 Apr 2004 13:24:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4OR-0006jV-00 for rddp@ietf.org; Fri, 23 Apr 2004 13:23:16 -0400 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BH4Nu-0006UA-00 for rddp@ietf.org; Fri, 23 Apr 2004 13:22:42 -0400 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A11C16C80108; Fri, 23 Apr 2004 13:23:40 -0400 From: "Barry Reinhold" To: "RDDP" Date: Fri, 23 Apr 2004 13:22:28 -0400 Message-ID: <007501c42957$905f1320$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.1409 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [rddp] Error code returns for DDP tagged buffer messages 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 Clause 9.2 DDP Error Numbers provides the error codes "Invalid STag" and "STag not associated with DDP Stream", but the language of the first paragraph is not clear enough for me to understand the expectation for the following: Is it the intent to require that a receiver delineate between "Invalid STag" and "STag not associated with DDP Stream"? That is, if STag 10 was valid on stream A but not on stream B, MUST the receiver return "STag not associated with DDP Stream?" if a DDP Segment is received on stream B with STag 10, or is "Invalid STag" acceptable. This question also applies to delineating between "Invalid MSN - no buffer available", and "Invalid MSN - MSN range is not valid". However, this is a bit more difficult conceptually as Clause 9.1, item 5 states: The legal range is defined as being between the MSN value assigned to the first available buffer for a specific QN and the MSN value assigned to the last available buffer for a specific QN. Which appears to tie "invalid MSN pretty closely to no buffer available. 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 Apr 23 14:22:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24906 for ; Fri, 23 Apr 2004 14:22:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5CZ-0008Pe-Ae for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 14:15:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NIF39N032334 for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 14:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH51A-0004g9-PC for rddp-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 14:03:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23845 for ; Fri, 23 Apr 2004 14:03:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH518-0001hP-An for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 14:03:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH509-0001P2-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 14:02:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4z2-0000ws-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 14:01:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4pN-0001QP-QN; Fri, 23 Apr 2004 13:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4gu-0006yi-2d for rddp@optimus.ietf.org; Fri, 23 Apr 2004 13:42:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22775 for ; Fri, 23 Apr 2004 13:42:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4gr-0003sp-Tm for rddp@ietf.org; Fri, 23 Apr 2004 13:42:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4fx-0003dY-00 for rddp@ietf.org; Fri, 23 Apr 2004 13:41:22 -0400 Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BH4fU-0003Ne-00 for rddp@ietf.org; Fri, 23 Apr 2004 13:40:52 -0400 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A56418690130; Fri, 23 Apr 2004 13:41:56 -0400 From: "Barry Reinhold" To: "RDDP" Date: Fri, 23 Apr 2004 13:40:43 -0400 Message-ID: <007801c4295a$1d9cb060$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.1409 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [rddp] Potential data corruption in DDP with MSN protocol violation 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 Based on the current wording in ddp draft 02, clause 9 it appears that a receiver can place and deliver a sequence of DDP messages that arrive with sequence number MSN=1, MSN=3, MSN=4 if there is no gap in the LLP stream sequence. This could only be generated by a protocol error on the transmitting side. However, if the transmitter did indeed generate this sequence incorrectly it is conceivable that the receiver would have old data in a buffer associated with MSN=2 and deliver it to the ULP. Although one does not in general like to have the receiver check for protocol errors, this may be an area in which the wording of the standard should be strengthened a bit, such that DDP messages can not be delivered when there are holes in the MSN space. 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 Apr 23 17:05:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11432 for ; Fri, 23 Apr 2004 17:05:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7S6-0003uM-UP for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 16:39:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NKdEZe015017 for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 16:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6mB-0007Bf-01 for rddp-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:55:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05305 for ; Fri, 23 Apr 2004 15:55:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6m9-0002fL-En for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 15:55:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6kd-0002EF-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 15:54:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BH6jZ-0001wi-02 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 15:53:13 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BH6fj-00078x-NR for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 15:49:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6ag-0003s1-8F; Fri, 23 Apr 2004 15:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6SV-0000Tz-MR for rddp@optimus.ietf.org; Fri, 23 Apr 2004 15:35:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03360 for ; Fri, 23 Apr 2004 15:35:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6SU-0004pX-9j for rddp@ietf.org; Fri, 23 Apr 2004 15:35:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6Q2-00046H-00 for rddp@ietf.org; Fri, 23 Apr 2004 15:33:03 -0400 Received: from mail.actcom.co.il ([192.114.47.35] helo=smtp2.actcom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1BH6NL-0003Dg-00 for rddp@ietf.org; Fri, 23 Apr 2004 15:30:16 -0400 Received: from [192.168.122.32] (line134-44.adsl.actcom.co.il [192.115.134.44]) by smtp2.actcom.co.il (8.12.8/8.12.8) with ESMTP id i3NJU3gI016915; Fri, 23 Apr 2004 22:30:09 +0300 In-Reply-To: <007801c4295a$1d9cb060$467fa8c0@i8600> References: <007801c4295a$1d9cb060$467fa8c0@i8600> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93C1C2F0-955C-11D8-89A6-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: "RDDP" From: Caitlin Bestler Subject: Re: [rddp] Potential data corruption in DDP with MSN protocol violation Date: Fri, 23 Apr 2004 22:29:45 +0300 To: "Barry Reinhold" X-Mailer: Apple Mail (2.613) 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 Apr 23, 2004, at 8:40 PM, Barry Reinhold wrote: > Based on the current wording in ddp draft 02, clause 9 it appears that > a > receiver can place and deliver a sequence of DDP messages that arrive > with sequence number MSN=1, MSN=3, MSN=4 if there is no gap in the LLP > stream sequence. This could only be generated by a protocol error on > the > transmitting side. > However, if the transmitter did indeed generate this sequence > incorrectly it is conceivable that the receiver would have old data in > a > buffer associated with MSN=2 and deliver it to the ULP. > The buffer associated with MSN 2 cannot be delivered unless a segment for MSN 2 arrives with the L bit set. It *is* possible for a sender to deliberately deliver undefined data to a peer, by simply not sending the entire message. It is unlikely that the receiver would take the effort to detect this (given that the MAY be out of order even in relation to LLP sequence, they only SHOULD be in order). But since the buffer belonged to the Data Sink ULP anyway I cannot imagine there being an exploit for this. Tricks involving *system* buffers might reveal interesting data if the system fails to zap them when assigning them to a new user. But that's one of the problems that RDMA avoids. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Apr 23 17:37:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14738 for ; Fri, 23 Apr 2004 17:37:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH85W-00068b-FT for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 17:19:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLJw68023586 for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 17:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7td-0000pG-4U for rddp-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:07:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11842 for ; Fri, 23 Apr 2004 17:07:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7ta-0001PZ-SK for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 17:07:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7sD-0000qK-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 17:06:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7qu-0000NO-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 17:04:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7Rt-0003p1-W2; Fri, 23 Apr 2004 16:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6dr-00058O-E2 for rddp@optimus.ietf.org; Fri, 23 Apr 2004 15:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05004 for ; Fri, 23 Apr 2004 15:47:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6dp-0000S0-QR for rddp@ietf.org; Fri, 23 Apr 2004 15:47:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6cx-0000Ca-00 for rddp@ietf.org; Fri, 23 Apr 2004 15:46:24 -0400 Received: from mail.actcom.co.il ([192.114.47.35] helo=smtp2.actcom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1BH6cN-0007ke-00 for rddp@ietf.org; Fri, 23 Apr 2004 15:45:47 -0400 Received: from [192.168.122.32] (line134-44.adsl.actcom.co.il [192.115.134.44]) by smtp2.actcom.co.il (8.12.8/8.12.8) with ESMTP id i3NJjdgI018454; Fri, 23 Apr 2004 22:45:43 +0300 In-Reply-To: <007501c42957$905f1320$467fa8c0@i8600> References: <007501c42957$905f1320$467fa8c0@i8600> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93105C9A-955E-11D8-89A6-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: "RDDP" From: Caitlin Bestler Subject: Re: [rddp] Error code returns for DDP tagged buffer messages Date: Fri, 23 Apr 2004 22:44:03 +0300 To: "Barry Reinhold" X-Mailer: Apple Mail (2.613) 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 Apr 23, 2004, at 8:22 PM, Barry Reinhold wrote: > Clause 9.2 DDP Error Numbers provides the error codes "Invalid STag" > and > "STag not associated with DDP Stream", but the language of the first > paragraph is not clear enough for me to understand the expectation for > the following: > > Is it the intent to require that a receiver delineate between "Invalid > STag" and "STag not associated with DDP Stream"? That is, if STag 10 > was > valid on stream A but not on stream B, MUST the receiver return "STag > not associated with DDP Stream?" if a DDP Segment is received on stream > B with STag 10, or is "Invalid STag" acceptable. I had interpreted it as *allowing* the receiver to make that distinction, but that given a choice of error codes that are both true the receiver is free to choose whichever one it desires. Personally, I see no reason to inform my peer as to whether an STag might be valid on another stream, so I would always return the "STag not associated with DDP Stream" error. In may implementations the STag will indeed have an RNIC scope, and hence 'Invalid STag' means that the first check (for existence of the STag) failed, and the second one is used when the PD check fails. However, it would be totally valid for STags to in fact have the scope of the PD. In which case the receiver would only know that there was no such STag enabled for the endpoint's PD. > > This question also applies to delineating between "Invalid MSN - no > buffer available", and "Invalid MSN - MSN range is not valid". However, > this is a bit more difficult conceptually as Clause 9.1, item 5 states: > > The legal range is defined as being between the MSN value > assigned to > the first available buffer for a specific QN and the MSN value > assigned to the last available buffer for a specific QN. > > Which appears to tie "invalid MSN pretty closely to no buffer > available. A local implementation might interpret a buffer that has been authorized as being "available". In which case the the "no buffer available" might be used very precisely to mean that although the message had been authorized there was through an internal slip-up no buffer available. Generally, however, I think the two are redundant. The term "unauthorized" buffer would be more precise (with the local implementation being free to assume that a buffer must be authorized if there is a buffer for it). There have been numerous discussions on this topic and its implications related to shared receive queues. While it is conceded by all that the ULP must exercise flow control, and hence there is indeed an ultimate distinction between an "authorized" untagged message and an invalid one, there are differing options as to whether this is something the endpoint should or can easily track. My position has always been that failure to track per connection credits creates a security risk where one connection can imperil other connections. For most multiple-connection scenarios that is not acceptable. There are, however, distinct scenarioes where credits are complex and session based. In those cases having the endpoint attempt to enforce credits is indeed a hinderance. In any event, for any endpoint that does not share receive buffers (using plain receive queues) the method of authorizing the reception of a new untagged message is simply posting a new buffer to the receive queue. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Apr 23 17:44:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15177 for ; Fri, 23 Apr 2004 17:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8K3-0002pt-9h for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 17:34:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLYx5U010897 for rddp-archive@odin.ietf.org; Fri, 23 Apr 2004 17:34:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7zn-00049T-E8 for rddp-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:14:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12467 for ; Fri, 23 Apr 2004 17:13:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7zl-00033R-6X for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 17:14:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7w8-0002Gq-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 17:10:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7ur-0001o6-00 for rddp-web-archive@ietf.org; Fri, 23 Apr 2004 17:08:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7dX-00087K-9h; Fri, 23 Apr 2004 16:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7Aj-0007Oo-3K for rddp@optimus.ietf.org; Fri, 23 Apr 2004 16:21:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07726 for ; Fri, 23 Apr 2004 16:21:13 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7Ah-0003CC-Aq for rddp@ietf.org; Fri, 23 Apr 2004 16:21:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH79i-0002sN-00 for rddp@ietf.org; Fri, 23 Apr 2004 16:20:14 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BH78k-0002Le-00 for rddp@ietf.org; Fri, 23 Apr 2004 16:19:14 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Apr 2004 16:18:36 -0400 Message-ID: To: rddp@ietf.org Date: Fri, 23 Apr 2004 16:18:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] issue (5) - Protection for shared RQ - closure attempt 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 discussion on this has died down somewhat, let me attempt to close this issue. Here's how I described the proposed shared RQ protection requirement in my last email, with a word added to acknowledge Caitlin's comment (*innocent*): The proposed requirement is that the Privileged Resource Manager contain code sufficient so that a non-RDDP application can be converted to a Non-Privileged RDDP application without enabling a DoS attack that disconnects *innocent* clients or having to write inter-client receive resource protection code. I'm going to try to close this issue by doing two things: a) With my WG chair hat on, I'm going to say that solving this shared RQ resource protection problem is a requirement on the rddp WG's output. This is a fairly fundamental system robustness issue, even within a single application. b) I'm going to call WG rough consensus on the above proposed requirement as the WG's solution to the problem. This is called over Paul Culley's objections. Further comments (including objections) to these two items should be posted to the list, but please be clear about whether each comment/message is about a) or b) or both. 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 Sat Apr 24 02:19:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24808 for ; Sat, 24 Apr 2004 02:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHGUD-0000oH-29 for rddp-archive@odin.ietf.org; Sat, 24 Apr 2004 02:18:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O6I0b5003110 for rddp-archive@odin.ietf.org; Sat, 24 Apr 2004 02:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHGN5-0005BU-U7 for rddp-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 02:10:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21674 for ; Sat, 24 Apr 2004 02:10:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHGN2-0000Fg-Hf for rddp-web-archive@ietf.org; Sat, 24 Apr 2004 02:10:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHGM3-0007mZ-00 for rddp-web-archive@ietf.org; Sat, 24 Apr 2004 02:09:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHGL1-0007Nk-00 for rddp-web-archive@ietf.org; Sat, 24 Apr 2004 02:08:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHGIe-0002P7-HE; Sat, 24 Apr 2004 02:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHGDO-0006pt-Uj for rddp@optimus.ietf.org; Sat, 24 Apr 2004 02:00:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11196 for ; Sat, 24 Apr 2004 02:00:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHGDL-0005N4-Fh for rddp@ietf.org; Sat, 24 Apr 2004 02:00:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHGCN-00056w-00 for rddp@ietf.org; Sat, 24 Apr 2004 01:59:35 -0400 Received: from mail.actcom.co.il ([192.114.47.35] helo=smtp2.actcom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1BHGBM-0004cx-00 for rddp@ietf.org; Sat, 24 Apr 2004 01:58:32 -0400 Received: from [192.168.122.32] (line134-44.adsl.actcom.co.il [192.115.134.44]) by smtp2.actcom.co.il (8.12.8/8.12.8) with ESMTP id i3O5wAgI001923; Sat, 24 Apr 2004 08:58:12 +0300 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5D0778C8-95B4-11D8-805F-000393814604@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] issue (5) - Protection for shared RQ - "Non-Privileged RDDP application" Date: Sat, 24 Apr 2004 08:58:09 +0300 To: Black_David@emc.com, RDDP X-Mailer: Apple Mail (2.613) 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 Apr 23, 2004, at 11:18 PM, Black_David@emc.com wrote: > Since discussion on this has died down somewhat, let me attempt > to close this issue. Here's how I described the proposed shared > RQ protection requirement in my last email, with a word added > to acknowledge Caitlin's comment (*innocent*): > > The proposed requirement is that the Privileged Resource Manager > contain code sufficient so that a non-RDDP application can be > converted to a Non-Privileged RDDP application without enabling > a DoS attack that disconnects *innocent* clients or having to > write inter-client receive resource protection code. > > I fully agree that applications should not be expected to guarantee deterministic response to shared-resource-overdraft alerts (such as the per-endpoint "over limit" alarm with RDMAC SRQs). However, I am not sure the "Non-Privileged" is the best term, or at the minimum the scope of the privilege needs to be clarified. In my opinion, any application that feels it can provide deterministic responses to shared-resource alerts should have the option of doing so, as long as it is the owner of the shared resource. The essential requirement is that the Privileged Resource Manager (or the RNIC itself) handle these alerts until the owner of the Shared Resource enables a different handler. So the term "Non-privileged" is appropriate if it is clear that it applies relative to the shared resource. What the OS considers to be a non-privileged server could still be the owner of a large shared receive queue. Such an application should have the option of fielding the SRQ alerts itself, or of having the Privileged Resource Manager do so. The tricky terminology problem here is the scope of "privilege" for the Privilege Resource Manager covers all resources the RNIC has access to (typically system wide). Whether by adding language or changing terms, we should be clear that a server does not need to be placed in the kernel or run as root in order to take full control over its SRQ. There are at least some applications where proper control over credits needs to be done on a session-wide basis, as opposed to on a per-stream basis. Such rules are typically very application specific, and should be dealt with by the application itself. I believe the intent is her to ensure that the vast majority of applications, that naturally have per- stream credits, are not also forced to either the extreme of managing everything related to shared resources itself or not using shared resources at all. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat Apr 24 19:05:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12277 for ; Sat, 24 Apr 2004 19:05:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHWAZ-0001wQ-9j for rddp-archive@odin.ietf.org; Sat, 24 Apr 2004 19:02:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ON2lSZ007458 for rddp-archive@odin.ietf.org; Sat, 24 Apr 2004 19:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHW4h-00004w-5b for rddp-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 18:56:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12028 for ; Sat, 24 Apr 2004 18:56:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHW4e-0002MR-3X for rddp-web-archive@ietf.org; Sat, 24 Apr 2004 18:56:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHW2X-00028U-00 for rddp-web-archive@ietf.org; Sat, 24 Apr 2004 18:54:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHW2B-0001uC-00 for rddp-web-archive@ietf.org; Sat, 24 Apr 2004 18:54:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHVtN-0005Al-JZ; Sat, 24 Apr 2004 18:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHVoy-0003eD-Fk for rddp@optimus.ietf.org; Sat, 24 Apr 2004 18:40:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11570 for ; Sat, 24 Apr 2004 18:40:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHVov-0006X3-8Q for rddp@ietf.org; Sat, 24 Apr 2004 18:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHVnv-0006If-00 for rddp@ietf.org; Sat, 24 Apr 2004 18:39:24 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1BHVnh-00064g-00; Sat, 24 Apr 2004 18:39:09 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3OMcc1T304746; Sat, 24 Apr 2004 18:38:38 -0400 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3OMcbOE207424; Sat, 24 Apr 2004 16:38:37 -0600 In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762D913F2B@cceexc18.americas.cpqcorp.net> To: rddp@ietf.org, rddp-admin@ietf.org MIME-Version: 1.0 Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John Hufferd Message-ID: Date: Sat, 24 Apr 2004 15:38:25 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/24/2004 16:38:36, Serialize complete at 04/24/2004 16:38:36 Content-Type: multipart/alternative; boundary="=_alternative 007C517988256E80_=" 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_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 007C517988256E80_= Content-Type: text/plain; charset="US-ASCII" I think that Paul has stated the point very well (in the attached note and his subsequent note), the purpose of Shared RQ was intended to be used by an application server that had a set of similar clients. This was assumed because of the need to post buffers that were of some optimum size for the Client to Server interaction. Because of the probability of very different buffering requirements -- I, for one, had not envisioned a privileged resource manager that Shared an RQ as a general facility for "all comers". However, I guess that having a particular implementation like that is OK, though I am not convinced of its importance. The important item is to permit a specific application to create a Shared RQ for use with it own clients. If a specific application server has 100s-1000s of clients, it should not have to have separate RQ for each Client - Server instance. So as long as this is permitted, I do not have any important feelings about what is done with a generic Shared RQ handler. Having said the above, I guess I do not feel that a Shared RQ needs to be in a privileged application, as long as it is only used by one application. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Culley, Paul" Sent by: rddp-admin@ietf.org 04/15/2004 06:21 AM To cc Subject RE: [rddp] Security draft issue (5) - Protection for shared RQ > > (5) Need to address "protection for shared RQ" problem. > > Scenario - server mis-implements resource management, bug in one > handler drags down others. E.g., a multiprotocol server with busted > filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP > should not impose non-uniform controls. > It should be noted that some of the authors do not expect shared receive queues to be shared between applications. Rather, a single application that must talk to many peers or clients might utilize such a queue. One reason this is desirable is to limit the scope of "partial mutual trust" to the application, another is that applications using a shared receive queue must also have a clear understanding of the size of the buffers on the queue. Users of the SRQ must agree to the size of the largest buffer used, or there will be a failure. Disparate applications would be unlikely to need the same general size of buffers, potentially leading to an inefficient size of buffers being used. If this usage model is agreed upon, I personally believe that the whole SRQ overrun protection problem is ok as it is. Paul R. Culley HP Fellow 281-514-5543 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --=_alternative 007C517988256E80_= Content-Type: text/html; charset="US-ASCII"
I think that Paul has stated the point very well (in the attached note and his subsequent note), the purpose of Shared RQ was intended to be used by an application server that had a set of similar clients.  This was assumed because of the need to post buffers that were of some optimum size for the Client to Server interaction.  Because of the probability of very different buffering requirements --  I, for one, had not envisioned a privileged resource manager that Shared an RQ as a general facility for "all comers".   However, I guess that having a particular implementation like that is OK, though I am not convinced of its importance.  

The important item is to permit a specific application to create a Shared RQ for use with it own clients.  If a specific application server has 100s-1000s of clients, it should not have to have separate RQ for each Client - Server instance.  So as long as this is permitted, I do not have any important feelings about what is done with a generic Shared RQ handler.    

Having said the above, I guess I do not feel that a Shared RQ needs to be in a privileged application, as long as it is only used by one application.  
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Culley, Paul" <paul.culley@hp.com>
Sent by: rddp-admin@ietf.org

04/15/2004 06:21 AM

To
<rddp@ietf.org>
cc
Subject
RE: [rddp] Security draft issue (5) - Protection for shared RQ





>
>   (5) Need to address "protection for shared RQ" problem.
>
>   Scenario - server mis-implements resource management, bug in one
>   handler drags down others. E.g., a multiprotocol server with busted
>   filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP
>   should not impose non-uniform controls.
>
It should be noted that some of the authors do not expect shared receive
queues to be shared between applications.  Rather, a single application
that must talk to many peers or clients might utilize such a queue.  One
reason this is desirable is to limit the scope of "partial mutual trust"
to the application, another is that applications using a shared receive
queue must also have a clear understanding of the size of the buffers on
the queue.  Users of the SRQ must agree to the size of the largest
buffer used, or there will be a failure.  Disparate applications would
be unlikely to need the same general size of buffers, potentially
leading to an inefficient size of buffers being used.

If this usage model is agreed upon, I personally believe that the whole
SRQ overrun protection problem is ok as it is.


Paul R. Culley
HP Fellow
281-514-5543

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
--=_alternative 007C517988256E80_=-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sun Apr 25 02:01:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29784 for ; Sun, 25 Apr 2004 02:01:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcgD-0000d8-9i for rddp-archive@odin.ietf.org; Sun, 25 Apr 2004 01:59:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P5xrUb002417 for rddp-archive@odin.ietf.org; Sun, 25 Apr 2004 01:59:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcf9-0000IG-Uh for rddp-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 01:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28416 for ; Sun, 25 Apr 2004 01:58:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHcf6-0002JS-Lj for rddp-web-archive@ietf.org; Sun, 25 Apr 2004 01:58:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHceE-00022M-00 for rddp-web-archive@ietf.org; Sun, 25 Apr 2004 01:57:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHcdM-0001nA-00 for rddp-web-archive@ietf.org; Sun, 25 Apr 2004 01:56:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcZa-0006ZN-M5; Sun, 25 Apr 2004 01:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcSo-0003w8-9g for rddp@optimus.ietf.org; Sun, 25 Apr 2004 01:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27562 for ; Sun, 25 Apr 2004 01:46:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHcSl-0006j0-1V for rddp@ietf.org; Sun, 25 Apr 2004 01:45:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHcRc-0006Pr-00 for rddp@ietf.org; Sun, 25 Apr 2004 01:44:49 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BHcR2-0006AL-00; Sun, 25 Apr 2004 01:44:12 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 1665B11EB28; Sun, 25 Apr 2004 01:44:13 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55323-08; Sun, 25 Apr 2004 01:44:11 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id B79A311EB25; Sun, 25 Apr 2004 01:44:11 -0400 (EDT) Received: from webmail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 2BC0A11EB12; Sun, 25 Apr 2004 01:44:11 -0400 (EDT) Received: from 82.166.251.29 (proxying for 82.166.251.29) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Sun, 25 Apr 2004 00:44:11 -0500 (CDT) Message-ID: <36754.82.166.251.29.1082871851.squirrel@mail52a.simplicato.com> In-Reply-To: References: <4D027986353D1341ADA4F2A4F8A170762D913F2B@cceexc18.americas.cpqcorp.net> Date: Sun, 25 Apr 2004 00:44:11 -0500 (CDT) Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ From: "Caitlin Bestler" To: "John Hufferd" Cc: rddp@ietf.org, rddp-admin@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable 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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable John Hufferd said: > I think that Paul has stated the point very well (in the attached note = and > his subsequent note), the purpose of Shared RQ was intended to be used = by > an application server that had a set of similar clients. This was assu= med > because of the need to post buffers that were of some optimum size for = the > Client to Server interaction. Because of the probability of very > different buffering requirements -- I, for one, had not envisioned a > privileged resource manager that Shared an RQ as a general facility for > "all comers". However, I guess that having a particular implementatio= n > like that is OK, though I am not convinced of its importance. > I think you are misunderstanding the intent of the requirement David has proposed. There are at least four different scenarios that seem to be behind the assumptions of various statements: 1) A sophisticated server application uses an SRQ rather than setting up an RQ for each connection. While the server specific ULP states a nominal credit level for each connection, the server application actually under-provisions the SRQ to conserve resources. This is totally hidden from the clients, who each believe there are N buffers waiting for them -- much as each customer of a bank believes they can withdraw their funds at any time even though the bank does not actually have that much cash on hand. 2) An SRQ is used over the scope of a multi-connection session, to allow ULP directed failover/load-balancing/striping/whatever across the connections. Flow control is managed at the session layer however, so per-stream credit tracking would not make sense. 3) An SRQ is offered as a general facility for multiple applications that merely share an approximate buffer size. 4) A server application uses an SRQ rather than an RQ for each connection, but is not necessarily sophisticated enough to guarantee deterministic responses to SRQ-alarms. I believe that Paul and John are mostly thinking of the first two scenarios, and think that the proposed change is intended to support the third option. I would agree that the third option is not a viable scenario, but I believe the last one is. Basically it allows a server to use Shared Resources with only the overhead of calculating the degree of under-provisioning that is appropriate. It does not have to develop a real-time guaranteed-response mechanism for dealing with denial-of-service attacks. Requiring such capabilities from any application that wants to use shared resources is not realistic, and will most likely result in the application designer saying "yeah, I've taken care of that" when in fact they haven't. Setting up applications to fail like that is poor security design. What the language clarification needs to be clear on is that for the first two scenarios that there is nothing wrong with an application controlling its own exception handling -- even if it is not have privilege at the same scope as the Privileged Resource Manager. It should also be clear that there is no expectation that an iWarp Provider SHOULD provide a multi-application shared receive queue capability. In fact you could almost state that they SHOULD NOT do so. One of the nice security feautes of RDMA is that it uses application supplied buffering, leaving all the holes associated with system buffers out of the picture. But I believe that SRQs should be enabled in a way that is ULP transparent. That is, the server deals with each session as it always had. It just primes the pump with receive buffers into the SRQ rather than into each RQ. With proper per-stream credit monitoring (or even per-stream credit counting) the application only needs to properly determine how many buffers it needs to place in the SRQ. No special alarm handling is required. I believe this is a far more realistic goal for application developers, and hence will lead to more robust and secure systems. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon Apr 26 17:23:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24240 for ; Mon, 26 Apr 2004 17:23:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDO4-0005w7-9U for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 17:11:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLBaWa022819 for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 17:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDBi-0002DU-Q6 for rddp-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 16:58:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20959 for ; Mon, 26 Apr 2004 16:58:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDBg-0002Em-Lu for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 16:58:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID2y-0000hv-00 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 16:49:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BICsW-0006RS-03 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 16:39:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BICmC-0001Lr-40 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 16:32:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBrE-0000pN-RT; Mon, 26 Apr 2004 15:33:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBl0-0008LF-M0 for rddp@optimus.ietf.org; Mon, 26 Apr 2004 15:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13299 for ; Mon, 26 Apr 2004 15:27:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBkz-000145-7p for rddp@ietf.org; Mon, 26 Apr 2004 15:27:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBkH-00012G-00 for rddp@ietf.org; Mon, 26 Apr 2004 15:26:26 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIBjl-0000zG-00 for rddp@ietf.org; Mon, 26 Apr 2004 15:25:53 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3QJPZoR011945; Mon, 26 Apr 2004 19:25:35 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3QJPX6D018468; Mon, 26 Apr 2004 19:25:33 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.135]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042612252119807 ; Mon, 26 Apr 2004 12:25:21 -0700 Received: from fmsmsx402.amr.corp.intel.com ([132.233.42.200]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 12:25:21 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Error code returns for DDP tagged buffer messages Date: Mon, 26 Apr 2004 12:25:21 -0700 Message-ID: <6315617889C99D4BA7C14687DEC8DB4E05218A8D@fmsmsx402.fm.intel.com> Thread-Topic: [rddp] Error code returns for DDP tagged buffer messages Thread-Index: AcQpWSXOj+8LFUY6R3qfreKiRwgaLwCZdJsQ From: "Shah, Hemal" To: "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 26 Apr 2004 19:25:21.0475 (UTC) FILETIME=[374F6130:01C42BC4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry, See my comments below embedded between and . Hemal -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, April 23, 2004 12:22 PM To: RDDP Subject: [rddp] Error code returns for DDP tagged buffer messages Clause 9.2 DDP Error Numbers provides the error codes "Invalid STag" and "STag not associated with DDP Stream", but the language of the first paragraph is not clear enough for me to understand the expectation for the following: For an "Invalid STag" memory access is not allowed at all. "STag not associated with DDP Stream" means that the STag is valid but is not associated with the DDP Stream on which the DDP Segment was received. In other words, memory access using the STag is not allowed on this DDP Stream.=20 Is it the intent to require that a receiver delineate between "Invalid STag" and "STag not associated with DDP Stream"? That is, if STag 10 was valid on stream A but not on stream B, MUST the receiver return "STag not associated with DDP Stream?" if a DDP Segment is received on stream B with STag 10, or is "Invalid STag" acceptable. No. The receiver MUST return "STag not associated with DDP Stream" in this case. This question also applies to delineating between "Invalid MSN - no buffer available", and "Invalid MSN - MSN range is not valid". However, this is a bit more difficult conceptually as Clause 9.1, item 5 states: The legal range is defined as being between the MSN value assigned to the first available buffer for a specific QN and the MSN value=20 assigned to the last available buffer for a specific QN. Which appears to tie "invalid MSN pretty closely to no buffer available. Let us say QN has a queue length QLEN. So, at any given point [MSN1, MSN2] represents the MSN range of the entries of the queue. Here, MSN2-MSN1 =3D QLEN-1 (in modulo arithmetic). Let us say the number of buffers posted on the queue at any given time is N (0 <=3D N <=3D QLEN). So, for N > 0, if a MSN is not in [MSN1,MSN1+N-1] and MSN1 <=3D MSN <=3D MSN2, then it is the condition "Invalid MSN - no buffer available". For N=3D0, if MSN is in [MSN1, MSN2], then it is the condition ""Invalid MSN = - no buffer available". If MSN is not in [MSN1,MSN2], then it is "Invalid MSN - MSN range not valid" condition. =20 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 Mon Apr 26 17:42:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25791 for ; Mon, 26 Apr 2004 17:42:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDZI-00010r-Lq for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 17:23:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLNCbU003888 for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 17:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDMZ-0005ow-Jc for rddp-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:10:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23170 for ; Mon, 26 Apr 2004 17:09:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDMX-000469-Gf for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 17:10:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDKj-0003sM-00 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 17:08:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDIJ-0003Rw-00 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 17:05:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDB3-0001aJ-6I; Mon, 26 Apr 2004 16:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BICxE-0005gW-L2 for rddp@optimus.ietf.org; Mon, 26 Apr 2004 16:43:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17549 for ; Mon, 26 Apr 2004 16:43:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BICxC-0007Jz-KJ for rddp@ietf.org; Mon, 26 Apr 2004 16:43:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICln-0005KQ-00 for rddp@ietf.org; Mon, 26 Apr 2004 16:32:04 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BICQC-0004Ov-00 for rddp@ietf.org; Mon, 26 Apr 2004 16:09:44 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3QK97FT023569; Mon, 26 Apr 2004 20:09:07 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3QK996D020423; Mon, 26 Apr 2004 20:09:10 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.135]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042613085707122 ; Mon, 26 Apr 2004 13:08:57 -0700 Received: from fmsmsx402.amr.corp.intel.com ([132.233.42.200]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 13:08:41 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Potential data corruption in DDP with MSN protocol violation Date: Mon, 26 Apr 2004 13:08:41 -0700 Message-ID: <6315617889C99D4BA7C14687DEC8DB4E05218A8E@fmsmsx402.fm.intel.com> Thread-Topic: [rddp] Potential data corruption in DDP with MSN protocol violation Thread-Index: AcQpXON2A45WRpXORWCrDSOjJ/mrcwCas1pg From: "Shah, Hemal" To: "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 26 Apr 2004 20:08:41.0647 (UTC) FILETIME=[452223F0:01C42BCA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Barry, The receiver can detect this protocol error by keeping track of the next MSN to be delivered. So, while delivering MSN=3D3, it can identify a = hole in the MSN. I agree with you that this case is not covered in the errors section. I would propose we add an error "Invalid MSN - gap in MSN" (type=3D0x2, code=3D0x00) for Untagged buffer errors. Thoughts? Hemal=20 -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, April 23, 2004 12:41 PM To: RDDP Subject: [rddp] Potential data corruption in DDP with MSN protocol violation Based on the current wording in ddp draft 02, clause 9 it appears that a receiver can place and deliver a sequence of DDP messages that arrive with sequence number MSN=3D1, MSN=3D3, MSN=3D4 if there is no gap in the = LLP stream sequence. This could only be generated by a protocol error on the transmitting side.=20 However, if the transmitter did indeed generate this sequence incorrectly it is conceivable that the receiver would have old data in a buffer associated with MSN=3D2 and deliver it to the ULP. Although one does not in general like to have the receiver check for protocol errors, this may be an area in which the wording of the standard should be strengthened a bit, such that DDP messages can not be delivered when there are holes in the MSN space. 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 Mon Apr 26 18:06:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27796 for ; Mon, 26 Apr 2004 18:06:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEDd-0003uQ-49 for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 18:04:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QM4rjO015021 for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 18:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDzp-0007ar-Tk for rddp-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:50:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26398 for ; Mon, 26 Apr 2004 17:50:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDzn-0007h4-FK for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 17:50:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDyx-0007cm-00 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 17:49:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDyC-0007XI-00 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 17:48:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDtS-00063J-K7; Mon, 26 Apr 2004 17:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDaX-0001E5-Ga for rddp@optimus.ietf.org; Mon, 26 Apr 2004 17:24:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24402 for ; Mon, 26 Apr 2004 17:24:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDaV-0005TJ-1H for rddp@ietf.org; Mon, 26 Apr 2004 17:24:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDYX-000599-00 for rddp@ietf.org; Mon, 26 Apr 2004 17:22:27 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1BIDWA-0004op-00 for rddp@ietf.org; Mon, 26 Apr 2004 17:19:58 -0400 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i3QLJSZh003324; Mon, 26 Apr 2004 14:19:28 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i3QLJRt8014002; Mon, 26 Apr 2004 14:19:28 -0700 (PDT) Received: from tmt.netapp.com ([10.97.6.42]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 26 Apr 2004 17:19:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42BD4.23FC1280" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [rddp] Potential data corruption in DDP with MSN protocol violation Date: Mon, 26 Apr 2004 14:18:21 -0700 Message-ID: <6.1.0.6.2.20040426171523.01d859a8@silver.nane.netapp.com> Thread-Topic: [rddp] Potential data corruption in DDP with MSN protocol violation Thread-Index: AcQr1CSaH1kQk9aRTCCuqIXQrs5byQ== From: "Talpey, Thomas" To: "Shah, Hemal" Cc: "Barry Reinhold" , "RDDP" 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.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42BD4.23FC1280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 04:08 PM 4/26/2004, Shah, Hemal wrote: >Barry, > >The receiver can detect this protocol error by keeping track of the = next >MSN to be delivered. So, while delivering MSN=3D3, it can identify a = hole >in the MSN. I agree with you that this case is not covered in the = errors >section. > >I would propose we add an error "Invalid MSN - gap in MSN" (type=3D0x2, >code=3D0x00) for Untagged buffer errors. Would the receiver then be required to check for such gaps? Because I agree with Caitlin that nothing bad happens if such a gap appears, except that the connection will grind to a halt since MSN=3D3 cannot be delivered. So, I think the error is merely informative, and not required for correctness. Therefore it could be argued it is not needed. Tom. > >Thoughts? > >Hemal=20 > >-----Original Message----- >From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of >Barry Reinhold >Sent: Friday, April 23, 2004 12:41 PM >To: RDDP >Subject: [rddp] Potential data corruption in DDP with MSN protocol >violation > >Based on the current wording in ddp draft 02, clause 9 it appears that = a >receiver can place and deliver a sequence of DDP messages that arrive >with sequence number MSN=3D1, MSN=3D3, MSN=3D4 if there is no gap in = the LLP >stream sequence. This could only be generated by a protocol error on = the >transmitting side.=20 >However, if the transmitter did indeed generate this sequence >incorrectly it is conceivable that the receiver would have old data in = a >buffer associated with MSN=3D2 and deliver it to the ULP. > >Although one does not in general like to have the receiver check for >protocol errors, this may be an area in which the wording of the >standard should be strengthened a bit, such that DDP messages can not = be >delivered when there are holes in the MSN space. > >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 ------_=_NextPart_001_01C42BD4.23FC1280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rddp] Potential data corruption in DDP with MSN protocol = violation

At 04:08 PM 4/26/2004, Shah, Hemal wrote:
>Barry,
>
>The receiver can detect this protocol error by = keeping track of the next
>MSN to be delivered. So, while delivering = MSN=3D3, it can identify a hole
>in the MSN. I agree with you that this case is = not covered in the errors
>section.
>
>I would propose we add an error "Invalid MSN = - gap in MSN" (type=3D0x2,
>code=3D0x00) for Untagged buffer errors.

Would the receiver then be required to check for such = gaps?
Because I agree with Caitlin that nothing bad happens = if such
a gap appears, except that the connection will grind = to a halt
since MSN=3D3 cannot be delivered.

So, I think the error is merely informative, and not = required for
correctness. Therefore it could be argued it is not = needed.

Tom.

>
>Thoughts?
>
>Hemal
>
>-----Original Message-----
>From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On = Behalf Of
>Barry Reinhold
>Sent: Friday, April 23, 2004 12:41 PM
>To: RDDP
>Subject: [rddp] Potential data corruption in DDP = with MSN protocol
>violation
>
>Based on the current wording in ddp draft 02, = clause 9 it appears that a
>receiver can place and deliver a sequence of DDP = messages that arrive
>with sequence number MSN=3D1, MSN=3D3, MSN=3D4 if = there is no gap in the LLP
>stream sequence. This could only be generated by = a protocol error on the
>transmitting side.
>However, if the transmitter did indeed generate = this sequence
>incorrectly it is conceivable that the receiver = would have old data in a
>buffer associated with MSN=3D2 and deliver it to = the ULP.
>
>Although one does not in general like to have the = receiver check for
>protocol errors, this may be an area in which the = wording of the
>standard should be strengthened a bit, such that = DDP messages can not be
>delivered when there are holes in the MSN = space.
>
>Barry Reinhold
>Lamprey Networks
>bbr@lampreynetworks.com
>(603) 868-8411
>
>
>
>
>
>_______________________________________________
>rddp mailing list
>rddp@ietf.org
>https://www1.ietf.or= g/mailman/listinfo/rddp
>
>_______________________________________________
>rddp mailing list
>rddp@ietf.org
>https://www1.ietf.or= g/mailman/listinfo/rddp

------_=_NextPart_001_01C42BD4.23FC1280-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon Apr 26 18:32:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00375 for ; Mon, 26 Apr 2004 18:32:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEZq-0004My-KK for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 18:27:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMRoL3016789 for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 18:27:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIENm-0001Fa-Bx for rddp-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28857 for ; Mon, 26 Apr 2004 18:15:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIENj-0001hY-JX for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 18:15:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEMr-0001d7-00 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 18:14:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIEMH-0001ZY-00 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 18:13:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEDo-000439-Pd; Mon, 26 Apr 2004 18:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE2W-00088F-Et for rddp@optimus.ietf.org; Mon, 26 Apr 2004 17:53:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26544 for ; Mon, 26 Apr 2004 17:53:19 -0400 (EDT) From: pat_thaler@agilent.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIE2T-000056-R5 for rddp@ietf.org; Mon, 26 Apr 2004 17:53:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE1b-00002F-00 for rddp@ietf.org; Mon, 26 Apr 2004 17:52:27 -0400 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1BIE1C-0007mP-00 for rddp@ietf.org; Mon, 26 Apr 2004 17:52:02 -0400 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 9417C24E46; Mon, 26 Apr 2004 15:51:57 -0600 (MDT) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 7186C454; Mon, 26 Apr 2004 15:51:57 -0600 (MDT) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 15:51:57 -0600 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] Error code returns for DDP tagged buffer messages Date: Mon, 26 Apr 2004 15:51:56 -0600 Message-ID: Thread-Topic: [rddp] Error code returns for DDP tagged buffer messages Thread-Index: AcQpWSXOj+8LFUY6R3qfreKiRwgaLwCZdJsQAAXnwhA= To: , , X-OriginalArrivalTime: 26 Apr 2004 21:51:57.0296 (UTC) FILETIME=[B2072700:01C42BD8] 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 Hemal, Your responses seem to depend on assumptions about implementation. Depending implementation, the validity check may allow the = implementation to see that the STag is valid but not associated with = this stream or it may not see anything that distinguishes the two cases. = Also, if the peer has tried to access an STag it shouldn't have access = to, I can't think of any reason to tell the peer that the STag is = possibly valid on another stream. Doing so doesn't convey any useful = information to an honest peer and it potentially reveals informtion to = an attacker. Therefore, STag not associated with DDP Stream should be returned. On the MSN errors, your answer presumes there is a fixed queue size = which there may or may not be. There also isn't a value in = distinguishing between these two errors. A message arrived and there was = no buffer. Also, nothing in the draft makes these distinctions between the errors. = In each case the distinction is not particularly useful and I think we = should consolidate to one error for STag not valid on the stream and one = error for no buffer for the MSN. Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Shah, Hemal Sent: Monday, April 26, 2004 12:25 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] Error code returns for DDP tagged buffer messages Barry, See my comments below embedded between and . Hemal -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, April 23, 2004 12:22 PM To: RDDP Subject: [rddp] Error code returns for DDP tagged buffer messages Clause 9.2 DDP Error Numbers provides the error codes "Invalid STag" and "STag not associated with DDP Stream", but the language of the first paragraph is not clear enough for me to understand the expectation for the following: For an "Invalid STag" memory access is not allowed at all. "STag not associated with DDP Stream" means that the STag is valid but is not associated with the DDP Stream on which the DDP Segment was received. In other words, memory access using the STag is not allowed on this DDP Stream.=20 Is it the intent to require that a receiver delineate between "Invalid STag" and "STag not associated with DDP Stream"? That is, if STag 10 was valid on stream A but not on stream B, MUST the receiver return "STag not associated with DDP Stream?" if a DDP Segment is received on stream B with STag 10, or is "Invalid STag" acceptable. No. The receiver MUST return "STag not associated with DDP Stream" in this case. This question also applies to delineating between "Invalid MSN - no buffer available", and "Invalid MSN - MSN range is not valid". However, this is a bit more difficult conceptually as Clause 9.1, item 5 states: The legal range is defined as being between the MSN value assigned to the first available buffer for a specific QN and the MSN value=20 assigned to the last available buffer for a specific QN. Which appears to tie "invalid MSN pretty closely to no buffer available. Let us say QN has a queue length QLEN. So, at any given point [MSN1, MSN2] represents the MSN range of the entries of the queue. Here, MSN2-MSN1 =3D QLEN-1 (in modulo arithmetic). Let us say the number of buffers posted on the queue at any given time is N (0 <=3D N <=3D QLEN). So, for N > 0, if a MSN is not in [MSN1,MSN1+N-1] and MSN1 <=3D MSN <=3D MSN2, then it is the condition "Invalid MSN - no buffer available". For N=3D0, if MSN is in [MSN1, MSN2], then it is the condition ""Invalid MSN = - no buffer available". If MSN is not in [MSN1,MSN2], then it is "Invalid MSN - MSN range not valid" condition. =20 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 Mon Apr 26 18:55:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01579 for ; Mon, 26 Apr 2004 18:55:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEwg-00083Z-JR for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 18:51:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMpQWa030961 for rddp-archive@odin.ietf.org; Mon, 26 Apr 2004 18:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEqM-0007WJ-Ho for rddp-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:44:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00953 for ; Mon, 26 Apr 2004 18:44:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEqJ-0003ph-Fy for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 18:44:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEpG-0003ei-00 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 18:43:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIEoZ-0003Wn-06 for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 18:43:03 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIEdm-0002lR-Lr for rddp-web-archive@ietf.org; Mon, 26 Apr 2004 18:31:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIESN-0003II-Ic; Mon, 26 Apr 2004 18:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEGx-0005kr-T9 for rddp@optimus.ietf.org; Mon, 26 Apr 2004 18:08:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28091 for ; Mon, 26 Apr 2004 18:08:15 -0400 (EDT) From: pat_thaler@agilent.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEGv-0001Hs-7e for rddp@ietf.org; Mon, 26 Apr 2004 18:08:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEG6-0001ED-00 for rddp@ietf.org; Mon, 26 Apr 2004 18:07:26 -0400 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1BIEFN-00019F-00 for rddp@ietf.org; Mon, 26 Apr 2004 18:06:41 -0400 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 9DEFB253C1; Mon, 26 Apr 2004 16:06:41 -0600 (MDT) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 817342AE; Mon, 26 Apr 2004 16:06:41 -0600 (MDT) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 16:06:41 -0600 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] Potential data corruption in DDP with MSN protocol violation Date: Mon, 26 Apr 2004 16:06:40 -0600 Message-ID: Thread-Topic: [rddp] Potential data corruption in DDP with MSN protocol violation Thread-Index: AcQr1CSaH1kQk9aRTCCuqIXQrs5byQABNUYQ To: , Cc: , X-OriginalArrivalTime: 26 Apr 2004 22:06:41.0420 (UTC) FILETIME=[C101C4C0:01C42BDA] 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 Tom, I think at a minimum there should also be something added to say that if = such a case occurs the receiver MUST not deliver whatever junk is lying = around as message 2. I don't mind the case where the connection grinds to a halt because it = has message 3 complete and no message 2. Something somewhere will time = out eventually and while it may not be as graceful as detecting the = error it is not disastrous.=20 The case that worries me is a designer who did not think about = protecting against this error in the received stream. An implementation = may be built that assumes when the stream receives the completion of MSN = 3 and the stream has no gaps up to that point that the prior messages = are also complete. If we don't want to allow that, then we need to says = something explicit about it.=20 Once we do that, we might as well add the error and at least allow an = implementation the choice of reporting it instead of silently freezing. Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of = Talpey, Thomas Sent: Monday, April 26, 2004 2:18 PM To: Shah, Hemal Cc: Barry Reinhold; RDDP Subject: RE: [rddp] Potential data corruption in DDP with MSN protocol = violation At 04:08 PM 4/26/2004, Shah, Hemal wrote:=20 >Barry,=20 >=20 >The receiver can detect this protocol error by keeping track of the = next=20 >MSN to be delivered. So, while delivering MSN=3D3, it can identify a = hole=20 >in the MSN. I agree with you that this case is not covered in the = errors=20 >section.=20 >=20 >I would propose we add an error "Invalid MSN - gap in MSN" (type=3D0x2, = >code=3D0x00) for Untagged buffer errors.=20 Would the receiver then be required to check for such gaps?=20 Because I agree with Caitlin that nothing bad happens if such=20 a gap appears, except that the connection will grind to a halt=20 since MSN=3D3 cannot be delivered.=20 So, I think the error is merely informative, and not required for=20 correctness. Therefore it could be argued it is not needed.=20 Tom.=20 >=20 >Thoughts?=20 >=20 >Hemal=20 >=20 >-----Original Message-----=20 >From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of=20 >Barry Reinhold=20 >Sent: Friday, April 23, 2004 12:41 PM=20 >To: RDDP=20 >Subject: [rddp] Potential data corruption in DDP with MSN protocol=20 >violation=20 >=20 >Based on the current wording in ddp draft 02, clause 9 it appears that = a=20 >receiver can place and deliver a sequence of DDP messages that arrive=20 >with sequence number MSN=3D1, MSN=3D3, MSN=3D4 if there is no gap in = the LLP=20 >stream sequence. This could only be generated by a protocol error on = the=20 >transmitting side.=20 >However, if the transmitter did indeed generate this sequence=20 >incorrectly it is conceivable that the receiver would have old data in = a=20 >buffer associated with MSN=3D2 and deliver it to the ULP.=20 >=20 >Although one does not in general like to have the receiver check for=20 >protocol errors, this may be an area in which the wording of the=20 >standard should be strengthened a bit, such that DDP messages can not = be=20 >delivered when there are holes in the MSN space.=20 >=20 >Barry Reinhold=20 >Lamprey Networks=20 >bbr@lampreynetworks.com=20 >(603) 868-8411=20 >=20 >=20 >=20 >=20 >=20 >_______________________________________________=20 >rddp mailing list=20 >rddp@ietf.org=20 >https://www1.ietf.org/mailman/listinfo/rddp=20 >=20 >_______________________________________________=20 >rddp mailing list=20 >rddp@ietf.org=20 >https://www1.ietf.org/mailman/listinfo/rddp=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Apr 27 00:42:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18820 for ; Tue, 27 Apr 2004 00:42:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKOY-0002ok-GL for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 00:40:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R4eYfb010825 for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 00:40:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKMt-0002TA-KI for rddp-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 00:38:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18618 for ; Tue, 27 Apr 2004 00:38:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIKMr-0003kM-2o for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 00:38:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKLv-0003b8-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 00:37:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIKLR-0003Rc-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 00:37:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKEM-00019t-Ai; Tue, 27 Apr 2004 00:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIK4W-00084k-O7 for rddp@optimus.ietf.org; Tue, 27 Apr 2004 00:19:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17578 for ; Tue, 27 Apr 2004 00:19:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIK4U-00014o-AQ for rddp@ietf.org; Tue, 27 Apr 2004 00:19:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIK3b-0000tv-00 for rddp@ietf.org; Tue, 27 Apr 2004 00:18:56 -0400 Received: from mail.actcom.net.il ([192.114.47.35] helo=smtp2.actcom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1BIK2U-0000io-00 for rddp@ietf.org; Tue, 27 Apr 2004 00:17:46 -0400 Received: from [192.168.122.46] (line134-44.adsl.actcom.co.il [192.115.134.44]) by smtp2.actcom.co.il (8.12.8/8.12.8) with ESMTP id i3R4HZI4003057; Tue, 27 Apr 2004 07:17:36 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: pat_thaler@agilent.com From: Caitlin Bestler Subject: Re: [rddp] Error code returns for DDP tagged buffer messages Date: Tue, 27 Apr 2004 07:17:23 +0300 To: RDDP X-Mailer: Apple Mail (2.613) 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 Apr 27, 2004, at 12:51 AM, pat_thaler@agilent.com wrote: > > > On the MSN errors, your answer presumes there is a fixed queue size > which there may or may not be. There also isn't a value in > distinguishing between these two errors. A message arrived and there > was no buffer. > > There is a valid distinction between "Invalid MSN: you should not have sent that message" and "Oops I don't have a buffer, sorry about that." As previously discussed while covering the implications of SRQs, for RDMA based ULPs to work, there MUST be a concept of a "valid MSN". But it is possible for an implementation using SRQs to be unaware of this limitation at the DDP layer. It is also highly plausible that the DDP layer will not know how many buffers are available to it, merely whether it can allocate 1 (in the case of arrival order allocation) or n (in case of serial order allocation). But I believe this issue has already been settled in the security discussions. Handling of per-stream credit violations by either the ULP or Privileged Resource Manager implies that the implementation is only required to detect such violations *promptly*, not synchronously. While I remain a strong proponent of catching these violations synchronously, making the existence of an SRQ transparent to the ULP peer, clearly this will not be a protocol mandate. The only requirement is that the deterministic response to such overruns not be forced upon all applications that want to use SRQs. But inherently delayed detection of the condition is legitimate. Therefore we cannot *require* that the generated error distinguish between "Invalid MSN: you should not have sent that message" and "Oops, sorry no buffer, I'm not sure who goofed". The question then becomes whether it is useful for implementations that *can* distinguish (as almost any would when using a plain RQ) to return the separate error for informative purposes. My inclination is that this is valuable, and unlike the "Invalid STag" error, provides virtually no information to an attacker. Theoretically, it allows an attacker to probe how many untagged message credits a stream had, but each probe tears down the stream. It's not terribly important information, and can probably be inferred more simply by just eavesdropping. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Apr 27 00:42:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18886 for ; Tue, 27 Apr 2004 00:42:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKOi-0002us-W1 for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 00:40:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R4eiss011204 for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 00:40:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKNk-0002iW-N4 for rddp-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 00:39:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18670 for ; Tue, 27 Apr 2004 00:39:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIKNi-0003v0-5Q for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 00:39:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKMr-0003kT-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 00:38:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIKLx-0003bF-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 00:37:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKEP-0001BH-Fl; Tue, 27 Apr 2004 00:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIK7Y-0008Kj-Oj for rddp@optimus.ietf.org; Tue, 27 Apr 2004 00:23:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17832 for ; Tue, 27 Apr 2004 00:22:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIK7W-0001Wf-8m for rddp@ietf.org; Tue, 27 Apr 2004 00:22:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIK6e-0001NH-00 for rddp@ietf.org; Tue, 27 Apr 2004 00:22:04 -0400 Received: from mail.actcom.net.il ([192.114.47.35] helo=smtp2.actcom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1BIK5t-0001DG-00 for rddp@ietf.org; Tue, 27 Apr 2004 00:21:17 -0400 Received: from [192.168.122.46] (line134-44.adsl.actcom.co.il [192.115.134.44]) by smtp2.actcom.co.il (8.12.8/8.12.8) with ESMTP id i3R4LEI4003318; Tue, 27 Apr 2004 07:21:16 +0300 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4EB20814-9802-11D8-9362-000393814604@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [rddp] Potential data corruption in DDP with MSN protocol violation Date: Tue, 27 Apr 2004 07:21:08 +0300 To: pat_thaler@agilent.com, RDDP X-Mailer: Apple Mail (2.613) 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 Apr 27, 2004, at 1:06 AM, pat_thaler@agilent.com wrote: > Tom, > > I think at a minimum there should also be something added to say that > if such a case occurs the receiver MUST not deliver whatever junk is > lying around as message 2. > > I don't mind the case where the connection grinds to a halt because it > has message 3 complete and no message 2. Something somewhere will time > out eventually and while it may not be as graceful as detecting the > error it is not disastrous. > > The case that worries me is a designer who did not think about > protecting against this error in the received stream. An > implementation may be built that assumes when the stream receives the > completion of MSN 3 and the stream has no gaps up to that point that > the prior messages are also complete. If we don't want to allow that, > then we need to says something explicit about it. > > Once we do that, we might as well add the error and at least allow an > implementation the choice of reporting it instead of silently > freezing. > > Pat > Do you agree that such text would be merely informative? My reading is that the existing rules already forbid delivery of message 3 when message 2 has not been delivered, and message 2 can only be delivered when its L segment is deliverable -- which it can never be if it does not exist. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Apr 27 08:58:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28418 for ; Tue, 27 Apr 2004 08:58:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIS7c-0003vr-SF for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 08:55:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RCta6C015113 for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 08:55:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIS4E-00033F-9T for rddp-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 08:52:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28038 for ; Tue, 27 Apr 2004 08:52:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIS49-00068A-61 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 08:52:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIS3D-0005uN-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 08:51:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIS2a-0005gv-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 08:50:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRkr-0007ek-1Q; Tue, 27 Apr 2004 08:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRe6-0005GX-DF for rddp@optimus.ietf.org; Tue, 27 Apr 2004 08:25:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26461 for ; Tue, 27 Apr 2004 08:25:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIRe1-0007Vw-D1 for rddp@ietf.org; Tue, 27 Apr 2004 08:25:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRd5-0007GR-00 for rddp@ietf.org; Tue, 27 Apr 2004 08:24:04 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1BIRc8-0006mE-00 for rddp@ietf.org; Tue, 27 Apr 2004 08:23:04 -0400 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i3RCMYZh000325; Tue, 27 Apr 2004 05:22:34 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i3RCMYNm012139; Tue, 27 Apr 2004 05:22:34 -0700 (PDT) Received: from tmt.netapp.com ([10.97.6.32]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Apr 2004 08:22:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42C52.4F254700" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [rddp] Potential data corruption in DDP with MSN protocol violation Date: Tue, 27 Apr 2004 05:21:07 -0700 Message-ID: <6.1.0.6.2.20040427081508.01d859a8@silver.nane.netapp.com> Thread-Topic: [rddp] Potential data corruption in DDP with MSN protocol violation Thread-Index: AcQsUk+HAWZOER6XRCWSbFujfwUi2A== From: "Talpey, Thomas" To: Cc: 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42C52.4F254700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I find this to be optimizing the error case. The sender has broken the rules in this scenario. And the receiver is not compromised. But if the receiver is not required to detect and report the error synchronously, then I am not against having the error code. Why couldn't the existing DDP "MSN range not valid" error code be used in this case? Definitely the unreceived MSN 2 must not be delivered, nor any MSN 3, etc. Tom. At 06:06 PM 4/26/2004, pat_thaler@agilent.com wrote: >Tom, > >I think at a minimum there should also be something added to say that = if=20 >such a case occurs the receiver MUST not deliver whatever junk is lying = >around as message 2. > >I don't mind the case where the connection grinds to a halt because it = has=20 >message 3 complete and no message 2. Something somewhere will time out=20 >eventually and while it may not be as graceful as detecting the error = it is=20 >not disastrous.=20 > >The case that worries me is a designer who did not think about = protecting=20 >against this error in the received stream. An implementation may be = built=20 >that assumes when the stream receives the completion of MSN 3 and the = stream=20 >has no gaps up to that point that the prior messages are also complete. = If=20 >we don't want to allow that, then we need to says something explicit = about it.=20 > >Once we do that, we might as well add the error and at least allow an=20 >implementation the choice of reporting it instead of silently freezing. > >Pat > >-----Original Message----- >From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of = Talpey,=20 >Thomas >Sent: Monday, April 26, 2004 2:18 PM >To: Shah, Hemal >Cc: Barry Reinhold; RDDP >Subject: RE: [rddp] Potential data corruption in DDP with MSN protocol=20 >violation > > >At 04:08 PM 4/26/2004, Shah, Hemal wrote:=20 >>Barry,=20 >>=20 >>The receiver can detect this protocol error by keeping track of the = next=20 >>MSN to be delivered. So, while delivering MSN=3D3, it can identify a = hole=20 >>in the MSN. I agree with you that this case is not covered in the = errors=20 >>section.=20 >>=20 >>I would propose we add an error "Invalid MSN - gap in MSN" = (type=3D0x2,=20 >>code=3D0x00) for Untagged buffer errors.=20 > >Would the receiver then be required to check for such gaps?=20 >Because I agree with Caitlin that nothing bad happens if such=20 >a gap appears, except that the connection will grind to a halt=20 >since MSN=3D3 cannot be delivered.=20 >So, I think the error is merely informative, and not required for=20 >correctness. Therefore it could be argued it is not needed.=20 > >Tom.=20 >>=20 >>Thoughts?=20 >>=20 >>Hemal=20 >>=20 >>-----Original Message-----=20 >>From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of=20 >>Barry Reinhold=20 >>Sent: Friday, April 23, 2004 12:41 PM=20 >>To: RDDP=20 >>Subject: [rddp] Potential data corruption in DDP with MSN protocol=20 >>violation=20 >>=20 >>Based on the current wording in ddp draft 02, clause 9 it appears that = a=20 >>receiver can place and deliver a sequence of DDP messages that arrive=20 >>with sequence number MSN=3D1, MSN=3D3, MSN=3D4 if there is no gap in = the LLP=20 >>stream sequence. This could only be generated by a protocol error on = the=20 >>transmitting side.=20 >>However, if the transmitter did indeed generate this sequence=20 >>incorrectly it is conceivable that the receiver would have old data in = a=20 >>buffer associated with MSN=3D2 and deliver it to the ULP.=20 >>=20 >>Although one does not in general like to have the receiver check for=20 >>protocol errors, this may be an area in which the wording of the=20 >>standard should be strengthened a bit, such that DDP messages can not = be=20 >>delivered when there are holes in the MSN space.=20 >>=20 >>Barry Reinhold=20 >>Lamprey Networks=20 >>bbr@lampreynetworks.com=20 >>(603) 868-8411=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>_______________________________________________=20 >>rddp mailing list=20 >>rddp@ietf.org=20 >>https://www1.ietf.org/mailman/listinfo/rddp=20 >>=20 >>_______________________________________________=20 >>rddp mailing list=20 >>rddp@ietf.org=20 >>https://www1.ietf.org/mailman/listinfo/rddp=20 ------_=_NextPart_001_01C42C52.4F254700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rddp] Potential data corruption in DDP with MSN protocol = violation

I find this to be optimizing the error case. The = sender has
broken the rules in this scenario. And the receiver = is not
compromised.

But if the receiver is not required to detect and = report the error
synchronously, then I am not against having the error = code.

Why couldn't the existing DDP "MSN range not = valid" error code
be used in this case? Definitely the unreceived MSN 2 = must not
be delivered, nor any MSN 3, etc.

Tom.

At 06:06 PM 4/26/2004, pat_thaler@agilent.com = wrote:
>Tom,
>
>I think at a minimum there should also be = something added to say that if
>such a case occurs the receiver MUST not deliver = whatever junk is lying
>around as message 2.
>
>I don't mind the case where the connection grinds = to a halt because it has
>message 3 complete and no message 2. Something = somewhere will time out
>eventually and while it may not be as graceful as = detecting the error it is
>not disastrous.
>
>The case that worries me is a designer who did = not think about protecting
>against this error in the received stream. An = implementation may be built
>that assumes when the stream receives the = completion of MSN 3 and the stream
>has no gaps up to that point that the prior = messages are also complete. If
>we don't want to allow that, then we need to says = something explicit about it.
>
>Once we do that, we might as well add the error = and at least allow an
>implementation the choice of reporting it instead = of silently freezing.
>
>Pat
>
>-----Original Message-----
>From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On = Behalf Of Talpey,
>Thomas
>Sent: Monday, April 26, 2004 2:18 PM
>To: Shah, Hemal
>Cc: Barry Reinhold; RDDP
>Subject: RE: [rddp] Potential data corruption in = DDP with MSN protocol
>violation
>
>
>At 04:08 PM 4/26/2004, Shah, Hemal wrote:
>>Barry,
>>
>>The receiver can detect this protocol error = by keeping track of the next
>>MSN to be delivered. So, while delivering = MSN=3D3, it can identify a hole
>>in the MSN. I agree with you that this case = is not covered in the errors
>>section.
>>
>>I would propose we add an error "Invalid = MSN - gap in MSN" (type=3D0x2,
>>code=3D0x00) for Untagged buffer errors. =
>
>Would the receiver then be required to check for = such gaps?
>Because I agree with Caitlin that nothing bad = happens if such
>a gap appears, except that the connection will = grind to a halt
>since MSN=3D3 cannot be delivered.
>So, I think the error is merely informative, and = not required for
>correctness. Therefore it could be argued it is = not needed.
>
>Tom.
>>
>>Thoughts?
>>
>>Hemal
>>
>>-----Original Message-----
>>From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On = Behalf Of
>>Barry Reinhold
>>Sent: Friday, April 23, 2004 12:41 PM
>>To: RDDP
>>Subject: [rddp] Potential data corruption in = DDP with MSN protocol
>>violation
>>
>>Based on the current wording in ddp draft 02, = clause 9 it appears that a
>>receiver can place and deliver a sequence of = DDP messages that arrive
>>with sequence number MSN=3D1, MSN=3D3, = MSN=3D4 if there is no gap in the LLP
>>stream sequence. This could only be generated = by a protocol error on the
>>transmitting side.
>>However, if the transmitter did indeed = generate this sequence
>>incorrectly it is conceivable that the = receiver would have old data in a
>>buffer associated with MSN=3D2 and deliver it = to the ULP.
>>
>>Although one does not in general like to have = the receiver check for
>>protocol errors, this may be an area in which = the wording of the
>>standard should be strengthened a bit, such = that DDP messages can not be
>>delivered when there are holes in the MSN = space.
>>
>>Barry Reinhold
>>Lamprey Networks
>>bbr@lampreynetworks.com
>>(603) 868-8411
>>
>>
>>
>>
>>
>>_______________________________________________
>>rddp mailing list
>>rddp@ietf.org
>>https://www1.ietf.or= g/mailman/listinfo/rddp
>>
>>_______________________________________________
>>rddp mailing list
>>rddp@ietf.org
>>https://www1.ietf.or= g/mailman/listinfo/rddp

------_=_NextPart_001_01C42C52.4F254700-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Apr 27 12:25:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10201 for ; Tue, 27 Apr 2004 12:25:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV3l-0004CT-FH for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 12:03:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RG3nbu016141 for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 12:03:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUzG-00039C-7M for rddp-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 11:59:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08899 for ; Tue, 27 Apr 2004 11:59:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUzC-0000G9-W0 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 11:59:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUyN-00009M-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 11:58:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUxE-0007lv-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 11:57:04 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIUxH-0003X7-Ky for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 11:57:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUkb-00082h-RP; Tue, 27 Apr 2004 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUVG-0003hx-4t for rddp@optimus.ietf.org; Tue, 27 Apr 2004 11:28:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07275 for ; Tue, 27 Apr 2004 11:28:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUVD-0005nv-0B for rddp@ietf.org; Tue, 27 Apr 2004 11:28:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUU2-0005ia-00 for rddp@ietf.org; Tue, 27 Apr 2004 11:26:55 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUT8-0005bq-00 for rddp@ietf.org; Tue, 27 Apr 2004 11:25:58 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3RFPeWo017399; Tue, 27 Apr 2004 15:25:40 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3RFPUxe031709; Tue, 27 Apr 2004 15:25:35 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042708252317356 ; Tue, 27 Apr 2004 08:25:23 -0700 Received: from fmsmsx402.amr.corp.intel.com ([132.233.42.200]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 08:25:24 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Error code returns for DDP tagged buffer messages Date: Tue, 27 Apr 2004 08:25:23 -0700 Message-ID: <6315617889C99D4BA7C14687DEC8DB4E05218A97@fmsmsx402.fm.intel.com> Thread-Topic: [rddp] Error code returns for DDP tagged buffer messages Thread-Index: AcQpWSXOj+8LFUY6R3qfreKiRwgaLwCZdJsQAAXnwhAAJQGzoA== From: "Shah, Hemal" To: , , X-OriginalArrivalTime: 27 Apr 2004 15:25:24.0173 (UTC) FILETIME=[DC432FD0:01C42C6B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pat, See my comments below embedded between and . Hemal -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]=20 Sent: Monday, April 26, 2004 4:52 PM To: Shah, Hemal; bbr@lampreynetworks.com; rddp@ietf.org Subject: RE: [rddp] Error code returns for DDP tagged buffer messages Hemal, Your responses seem to depend on assumptions about implementation. Depending implementation, the validity check may allow the implementation to see that the STag is valid but not associated with this stream or it may not see anything that distinguishes the two cases. Also, if the peer has tried to access an STag it shouldn't have access to, I can't think of any reason to tell the peer that the STag is possibly valid on another stream. Doing so doesn't convey any useful information to an honest peer and it potentially reveals informtion to an attacker. Therefore, STag not associated with DDP Stream should be returned. I'm little bit confused here. In my email, I exactly recommended that the above error should be returned in the case Barry described. It seems like we are in agreement here. Please clarify. On the MSN errors, your answer presumes there is a fixed queue size which there may or may not be. There also isn't a value in distinguishing between these two errors. A message arrived and there was no buffer. I am not assuming a fixed queue size. At any give point in time, a queue can have QLEN size which can change dynamically based on the modifications to the queue size. For the errors, the queue size seen at the message arrival time should be used. =20 Also, nothing in the draft makes these distinctions between the errors. In each case the distinction is not particularly useful and I think we should consolidate to one error for STag not valid on the stream and one error for no buffer for the MSN. I believe that the distinction can be useful for the debugging. Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Shah, Hemal Sent: Monday, April 26, 2004 12:25 PM To: Barry Reinhold; RDDP Subject: RE: [rddp] Error code returns for DDP tagged buffer messages Barry, See my comments below embedded between and . Hemal -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Barry Reinhold Sent: Friday, April 23, 2004 12:22 PM To: RDDP Subject: [rddp] Error code returns for DDP tagged buffer messages Clause 9.2 DDP Error Numbers provides the error codes "Invalid STag" and "STag not associated with DDP Stream", but the language of the first paragraph is not clear enough for me to understand the expectation for the following: For an "Invalid STag" memory access is not allowed at all. "STag not associated with DDP Stream" means that the STag is valid but is not associated with the DDP Stream on which the DDP Segment was received. In other words, memory access using the STag is not allowed on this DDP Stream.=20 Is it the intent to require that a receiver delineate between "Invalid STag" and "STag not associated with DDP Stream"? That is, if STag 10 was valid on stream A but not on stream B, MUST the receiver return "STag not associated with DDP Stream?" if a DDP Segment is received on stream B with STag 10, or is "Invalid STag" acceptable. No. The receiver MUST return "STag not associated with DDP Stream" in this case. This question also applies to delineating between "Invalid MSN - no buffer available", and "Invalid MSN - MSN range is not valid". However, this is a bit more difficult conceptually as Clause 9.1, item 5 states: The legal range is defined as being between the MSN value assigned to the first available buffer for a specific QN and the MSN value=20 assigned to the last available buffer for a specific QN. Which appears to tie "invalid MSN pretty closely to no buffer available. Let us say QN has a queue length QLEN. So, at any given point [MSN1, MSN2] represents the MSN range of the entries of the queue. Here, MSN2-MSN1 =3D QLEN-1 (in modulo arithmetic). Let us say the number of buffers posted on the queue at any given time is N (0 <=3D N <=3D QLEN). So, for N > 0, if a MSN is not in [MSN1,MSN1+N-1] and MSN1 <=3D MSN <=3D MSN2, then it is the condition "Invalid MSN - no buffer available". For N=3D0, if MSN is in [MSN1, MSN2], then it is the condition ""Invalid MSN = - no buffer available". If MSN is not in [MSN1,MSN2], then it is "Invalid MSN - MSN range not valid" condition. =20 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 Apr 27 13:23:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15045 for ; Tue, 27 Apr 2004 13:23:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWB3-0006Ap-MD for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 13:15:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RHFPsx023722 for rddp-archive@odin.ietf.org; Tue, 27 Apr 2004 13:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIW4G-0004Hn-Hr for rddp-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 13:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13407 for ; Tue, 27 Apr 2004 13:08:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIW4C-0005l7-O0 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 13:08:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIW1u-0005Kl-00 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 13:05:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVzr-00055Y-02 for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 13:03:51 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIVtR-00053J-Oz for rddp-web-archive@ietf.org; Tue, 27 Apr 2004 12:57:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVmV-0008Ov-6e; Tue, 27 Apr 2004 12:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVar-0004kt-DH for rddp@optimus.ietf.org; Tue, 27 Apr 2004 12:38:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10839 for ; Tue, 27 Apr 2004 12:37:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVan-0002W7-OF for rddp@ietf.org; Tue, 27 Apr 2004 12:37:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVZt-0002Sk-00 for rddp@ietf.org; Tue, 27 Apr 2004 12:37:02 -0400 Received: from mail.actcom.net.il ([192.114.47.35] helo=smtp2.actcom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1BIVZO-0002Py-00 for rddp@ietf.org; Tue, 27 Apr 2004 12:36:30 -0400 Received: from [192.168.122.46] (line134-44.adsl.actcom.co.il [192.115.134.44]) by smtp2.actcom.co.il (8.12.8/8.12.8) with ESMTP id i3RGaOI4012854; Tue, 27 Apr 2004 19:36:24 +0300 In-Reply-To: <6315617889C99D4BA7C14687DEC8DB4E05218A97@fmsmsx402.fm.intel.com> References: <6315617889C99D4BA7C14687DEC8DB4E05218A97@fmsmsx402.fm.intel.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <04C9D83B-9869-11D8-9642-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: , , From: Caitlin Bestler Subject: Re: [rddp] Error code returns for DDP tagged buffer messages Date: Tue, 27 Apr 2004 19:36:22 +0300 To: "Shah, Hemal" X-Mailer: Apple Mail (2.613) 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 Apr 27, 2004, at 6:25 PM, Shah, Hemal wrote: > > I am not assuming a fixed queue size. At any give point in time, a > queue > can have QLEN size which can change dynamically based on the > modifications to the queue size. For the errors, the queue size seen at > the message arrival time should be used. > You are assuming that there is a queue that is specific to the stream, and that it's size is easily determined. That is actually an excellent design. Which is why I was opposed to the definition of SRQs in the RDMAC iWarp verbs. If the local interface implements an RDMAC style SRQ it is obligated to allocate over the nominal per-stream limits if there are buffers available. Such a constraint all but forces a more complex SRQ design that is not anything as simple as an adjustable ring buffer. With that implementation you *might* be able to check the per-stream quota whenever a buffer is not available. If the new MSN minus the stream's base MSN would exceed the stream's quota (that is, if the buffer had been accepted it would have raised the per-stream over-limit alarm) then the implementation could return the "Invalid MSN" error. But if it is within the limit, meaning the remote peer is probably not the party responsible for buffer exhaustion, an "No Available Buffer" error is far more accurate. However, in order to *reliably* distinguish between the two the per-stream quota must be available at the same layer that generates the error. It is entirely plausible to have an implementation where allocations are made from the SRQ on the RNIC, but the alarms are detected by the driver. My preference for deterministic teardown of streams that exceed their quota has been previously noted. But given that the consensus favors allowing asynchronous detection of this condition (with only the caveat that the application not be forced into that asynchronous loop) we have to recognize that valid SRQ implementations may not always be able to distinguish between the two errors. I do not believe we need to disrupt implementations by running around and renumbering the error conditions. But we should note that when multiple error returns are all true then the implementation is free to issue any of them. There is no "correct" choice among the error codes that are true. The only exception is implied by the DDP ordering rules. If there is a DDP layer error, then it MUST take precedence over an RDMAP layer error. After all, evaluating the RDMAP packet before validating the DDP packet would have been speculative. Technically, if there is a DDP layer error then the RDMAP layer should never have gotten the packet for handling. > > Also, nothing in the draft makes these distinctions between the errors. > In each case the distinction is not particularly useful and I think we > should consolidate to one error for STag not valid on the stream and > one > error for no buffer for the MSN. > > > I believe that the distinction can be useful for the debugging. > I agree. When the receiver knows that the MSN is invalid it SHOULD provide that diagnostic information. This should be simple with RQs and with many SRQ designs. And there is a very big difference between "you sent too many messages" and "I ran out of buffers". -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Apr 28 13:57:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03557 for ; Wed, 28 Apr 2004 13:57:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt94-0003MV-4S for rddp-archive@odin.ietf.org; Wed, 28 Apr 2004 13:46:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHksJ1012921 for rddp-archive@odin.ietf.org; Wed, 28 Apr 2004 13:46:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsy5-0000fk-J0 for rddp-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:35:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01857 for ; Wed, 28 Apr 2004 13:35:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsy2-0001qR-7r for rddp-web-archive@ietf.org; Wed, 28 Apr 2004 13:35:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsxF-0001me-00 for rddp-web-archive@ietf.org; Wed, 28 Apr 2004 13:34:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIswW-0001im-00 for rddp-web-archive@ietf.org; Wed, 28 Apr 2004 13:33:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsnw-0006fv-Jw; Wed, 28 Apr 2004 13:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsYj-0002Hh-Hp for rddp@optimus.ietf.org; Wed, 28 Apr 2004 13:09:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29481 for ; Wed, 28 Apr 2004 13:09:17 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsYg-0007U4-7f for rddp@ietf.org; Wed, 28 Apr 2004 13:09:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsXl-0007Qz-00 for rddp@ietf.org; Wed, 28 Apr 2004 13:08:22 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BIsWs-0007L5-00 for rddp@ietf.org; Wed, 28 Apr 2004 13:07:26 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Apr 2004 13:06:53 -0400 Message-ID: To: hufferd@us.ibm.com, rddp@ietf.org Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ Date: Wed, 28 Apr 2004 13:06:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rddp-admin@ietf.org Errors-To: rddp-admin@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , 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 John, > The important item is to permit a specific application to create a Shared RQ > for use with it own clients. If a specific application server has 100s-1000s > of clients, it should not have to have separate RQ for each Client - Server > instance. So as long as this is permitted, I do not have any important > feelings about what is done with a generic Shared RQ handler. I think this is in line with the intent of the proposed requirement The intent is along the lines of what Caitlin wrote: In my opinion, any application that feels it can provide deterministic responses to shared-resource alerts should have the option of doing so, as long as it is the owner of the shared resource. The essential requirement is that the Privileged Resource Manager (or the RNIC itself) handle these alerts until the owner of the Shared Resource enables a different handler. In other words, the proposed requirement for Shared RQ protection in the Privileged Resource Manager is "MUST implement", not "MUST use", not even for Non-Privileged applications. > Having said the above, I guess I do not feel that a Shared RQ needs > to be in a privileged application, as long as it is only used by one > application. I would agree, - this needs to be orthogonal to whether the application is privileged or non-privileged, as there is no realistic way to stop a non-privileged application that has an RQ from sharing it among multiple clients, and no strong rationale that I can see for imposing that sort of restriction. In the other direction, a privileged app might want to take advantage of the Privileged Resource Manager's Shared RQ protection rather than implement it on its own, and there is no good reason to prohibit that app from doing so. NB: This requirement would also apply to shared completion queues. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of John Hufferd Sent: Saturday, April 24, 2004 6:38 PM To: rddp@ietf.org; rddp-admin@ietf.org Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ I think that Paul has stated the point very well (in the attached note and his subsequent note), the purpose of Shared RQ was intended to be used by an application server that had a set of similar clients. This was assumed because of the need to post buffers that were of some optimum size for the Client to Server interaction. Because of the probability of very different buffering requirements -- I, for one, had not envisioned a privileged resource manager that Shared an RQ as a general facility for "all comers". However, I guess that having a particular implementation like that is OK, though I am not convinced of its importance. The important item is to permit a specific application to create a Shared RQ for use with it own clients. If a specific application server has 100s-1000s of clients, it should not have to have separate RQ for each Client - Server instance. So as long as this is permitted, I do not have any important feelings about what is done with a generic Shared RQ handler. Having said the above, I guess I do not feel that a Shared RQ needs to be in a privileged application, as long as it is only used by one application. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Culley, Paul" Sent by: rddp-admin@ietf.org 04/15/2004 06:21 AM To cc SubjectRE: [rddp] Security draft issue (5) - Protection for shared RQ > > (5) Need to address "protection for shared RQ" problem. > > Scenario - server mis-implements resource management, bug in one > handler drags down others. E.g., a multiprotocol server with busted > filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP > should not impose non-uniform controls. > It should be noted that some of the authors do not expect shared receive queues to be shared between applications. Rather, a single application that must talk to many peers or clients might utilize such a queue. One reason this is desirable is to limit the scope of "partial mutual trust" to the application, another is that applications using a shared receive queue must also have a clear understanding of the size of the buffers on the queue. Users of the SRQ must agree to the size of the largest buffer used, or there will be a failure. Disparate applications would be unlikely to need the same general size of buffers, potentially leading to an inefficient size of buffers being used. If this usage model is agreed upon, I personally believe that the whole SRQ overrun protection problem is ok as it is. Paul R. Culley HP Fellow 281-514-5543 _______________________________________________ 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 Apr 30 12:57:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14370 for ; Fri, 30 Apr 2004 12:57:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb8w-0001nT-Ge for rddp-archive@odin.ietf.org; Fri, 30 Apr 2004 12:45:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UGjgUs006904 for rddp-archive@odin.ietf.org; Fri, 30 Apr 2004 12:45:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb0d-0007fQ-N1 for rddp-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 12:37:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13219 for ; Fri, 30 Apr 2004 12:37:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJb0c-0006e9-5S for rddp-web-archive@ietf.org; Fri, 30 Apr 2004 12:37:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaze-0006ZT-00 for rddp-web-archive@ietf.org; Fri, 30 Apr 2004 12:36:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJayj-0006Uq-00 for rddp-web-archive@ietf.org; Fri, 30 Apr 2004 12:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJanw-00055l-UB; Fri, 30 Apr 2004 12:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaXe-0000f0-Cr for rddp@optimus.ietf.org; Fri, 30 Apr 2004 12:07:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11607 for ; Fri, 30 Apr 2004 12:07:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaXd-0004cF-39 for rddp@ietf.org; Fri, 30 Apr 2004 12:07:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaWl-0004Zg-00 for rddp@ietf.org; Fri, 30 Apr 2004 12:06:15 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BJaWF-0004XT-00 for rddp@ietf.org; Fri, 30 Apr 2004 12:05:43 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 4378211E6FD; Fri, 30 Apr 2004 12:05:40 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16880-09; Fri, 30 Apr 2004 12:05:38 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 1E2EC11E829; Fri, 30 Apr 2004 12:05:21 -0400 (EDT) Received: from [192.168.122.32] (unknown [212.143.154.147]) by host52a.simplicato.com (Postfix) with ESMTP id 7E36E11E81A; Fri, 30 Apr 2004 12:05:18 -0400 (EDT) In-Reply-To: <6315617889C99D4BA7C14687DEC8DB4E05218A97@fmsmsx402.fm.intel.com> References: <6315617889C99D4BA7C14687DEC8DB4E05218A97@fmsmsx402.fm.intel.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <04C9D83B-9869-11D8-9642-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: , , From: Caitlin Bestler Subject: Re: [rddp] Error code returns for DDP tagged buffer messages Date: Tue, 27 Apr 2004 19:36:22 +0300 To: "Shah, Hemal" X-Mailer: Apple Mail (2.613) X-Virus-Scanned: by amavisd-new at simplicato.com 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 Apr 27, 2004, at 6:25 PM, Shah, Hemal wrote: > > I am not assuming a fixed queue size. At any give point in time, a > queue > can have QLEN size which can change dynamically based on the > modifications to the queue size. For the errors, the queue size seen at > the message arrival time should be used. > You are assuming that there is a queue that is specific to the stream, and that it's size is easily determined. That is actually an excellent design. Which is why I was opposed to the definition of SRQs in the RDMAC iWarp verbs. If the local interface implements an RDMAC style SRQ it is obligated to allocate over the nominal per-stream limits if there are buffers available. Such a constraint all but forces a more complex SRQ design that is not anything as simple as an adjustable ring buffer. With that implementation you *might* be able to check the per-stream quota whenever a buffer is not available. If the new MSN minus the stream's base MSN would exceed the stream's quota (that is, if the buffer had been accepted it would have raised the per-stream over-limit alarm) then the implementation could return the "Invalid MSN" error. But if it is within the limit, meaning the remote peer is probably not the party responsible for buffer exhaustion, an "No Available Buffer" error is far more accurate. However, in order to *reliably* distinguish between the two the per-stream quota must be available at the same layer that generates the error. It is entirely plausible to have an implementation where allocations are made from the SRQ on the RNIC, but the alarms are detected by the driver. My preference for deterministic teardown of streams that exceed their quota has been previously noted. But given that the consensus favors allowing asynchronous detection of this condition (with only the caveat that the application not be forced into that asynchronous loop) we have to recognize that valid SRQ implementations may not always be able to distinguish between the two errors. I do not believe we need to disrupt implementations by running around and renumbering the error conditions. But we should note that when multiple error returns are all true then the implementation is free to issue any of them. There is no "correct" choice among the error codes that are true. The only exception is implied by the DDP ordering rules. If there is a DDP layer error, then it MUST take precedence over an RDMAP layer error. After all, evaluating the RDMAP packet before validating the DDP packet would have been speculative. Technically, if there is a DDP layer error then the RDMAP layer should never have gotten the packet for handling. > > Also, nothing in the draft makes these distinctions between the errors. > In each case the distinction is not particularly useful and I think we > should consolidate to one error for STag not valid on the stream and > one > error for no buffer for the MSN. > > > I believe that the distinction can be useful for the debugging. > I agree. When the receiver knows that the MSN is invalid it SHOULD provide that diagnostic information. This should be simple with RQs and with many SRQ designs. And there is a very big difference between "you sent too many messages" and "I ran out of buffers". -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp