From ips-bounces@ietf.org Wed Jun 01 08:48:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSe0-00028q-5F; Wed, 01 Jun 2005 08:48:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSdx-00023P-IX for ips@megatron.ietf.org; Wed, 01 Jun 2005 08:48:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13193 for ; Wed, 1 Jun 2005 08:48:17 -0400 (EDT) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdSxl-0001Pk-BD for ips@ietf.org; Wed, 01 Jun 2005 09:08:50 -0400 Received: from localhost.localdomain (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j51Cm39e020682; Wed, 1 Jun 2005 08:48:04 -0400 (EDT) Subject: Re: [Ips] Perfect Hashing for All 23 iSCSI Text Keys From: Ming Zhang To: Faraz Ahmed In-Reply-To: <00be01c56425$e461f640$5f0010ac@screech> References: <00be01c56425$e461f640$5f0010ac@screech> Organization: no-dole-available Date: Wed, 01 Jun 2005 08:48:03 -0400 Message-Id: <1117630083.5507.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: mbrown@cs.uml.edu, ips@ietf.org, linux-iscsi development team X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1389196229==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1389196229== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qxp1recXU2m4O0Pg8BT7" --=-qxp1recXU2m4O0Pg8BT7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable any particular reason for hashing in a space with 23 value? ming On Sun, 2005-05-29 at 01:10 -0700, Faraz Ahmed wrote: > Hi all; > I dont know whether this should be discussed here. As part of > implementing a iSCSI target, we often need to search for a particular Tex= t > key. Here i have discovered a hashing fucntion which perfectly hashes all > the 23 iSCSI text key. > The Bernsteins Hash Function wiht the MAGIC value of 34043539 hashes > all the keys perfectly. >=20 >=20 >=20 > #define FARAZ_HASH_VAL 34043539 > #define PR_COL 0 > #define IDX_COL 1 > char __key_hash[MAX_KEYS][2]; >=20 >=20 >=20 > /* > * Berstein Hash Fucntion for strings. Hashes all the keys uniquely > */ > inline int __djb2_hash(char *str_orig) > { > unsigned long hash =3D FARAZ_HASH_VAL; > char *str =3D str_orig; > int c; > while ((c=3D*str++)!=3D'\0') > hash =3D ((hash << 5) + hash) + c; /* hash * 33 + c */ >=20 > iSCSIDEBUGINFO("__djb2_hash(%s)=3D%d",str_orig,(int)hash%MAX_KEYS); >=20 > return hash%MAX_KEYS; > } >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=-qxp1recXU2m4O0Pg8BT7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCna6DSYbkL5BnVYoRAq1+AJ9J8THyGtzOQSvsgCWWM7qna2JrwQCeJFlo ZxKyr9oGOcevzlhlrtv2bzs= =PMwI -----END PGP SIGNATURE----- --=-qxp1recXU2m4O0Pg8BT7-- --===============1389196229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1389196229==-- From ips-bounces@ietf.org Wed Jun 01 09:36:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTOy-0005DB-8y; Wed, 01 Jun 2005 09:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTOw-0005D6-16 for ips@megatron.ietf.org; Wed, 01 Jun 2005 09:36:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16364 for ; Wed, 1 Jun 2005 09:36:52 -0400 (EDT) Received: from calsoftinc.com ([64.62.215.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DdTij-0003pg-7x for ips@ietf.org; Wed, 01 Jun 2005 09:57:24 -0400 Received: from screech ([220.225.34.78]) by calsoftinc.com for ; Wed, 1 Jun 2005 06:36:46 -0700 Message-ID: <00c301c566b3$e95ad370$5f0010ac@screech> From: "Faraz Ahmed" To: References: <00be01c56425$e461f640$5f0010ac@screech> <1117630083.5507.16.camel@localhost.localdomain> Subject: Re: [linux-iscsi-devel] Re: [Ips] Perfect Hashing for All 23 iSCSI Text Keys Date: Wed, 1 Jun 2005 07:11:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: mbrown@cs.uml.edu, ips@ietf.org, linux-iscsi development team X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Ming; Its just a finding i thought that should be shared. Any ways the optimization may minuscule, since the space being small. But I think its better than if(!strcmp()) elseuif (!strcmp()) my first implementation the lexical sort/search the second one Anyways is there some very easy, very obvious way to do this search, which is better than the hash thing in terms of time. Do let me know. May be i have just overlooked an approach. or tried to optimize something that is in the end going to optimize nothing in the large scheme of work. Regards Faraz ----- Original Message ----- From: "Ming Zhang" To: "Faraz Ahmed" Cc: "Nicholas A. Bellinger" ; ; ; "linux-iscsi development team" Sent: Wednesday, June 01, 2005 5:48 AM Subject: [linux-iscsi-devel] Re: [Ips] Perfect Hashing for All 23 iSCSI Text Keys _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jun 01 09:55:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTgw-0004WK-OQ; Wed, 01 Jun 2005 09:55:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTgv-0004VJ-MJ for ips@megatron.ietf.org; Wed, 01 Jun 2005 09:55:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17722 for ; Wed, 1 Jun 2005 09:55:27 -0400 (EDT) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdU0l-0004lu-GV for ips@ietf.org; Wed, 01 Jun 2005 10:15:59 -0400 Received: from localhost.localdomain (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j51DtJ9e023033; Wed, 1 Jun 2005 09:55:20 -0400 (EDT) Subject: Re: [linux-iscsi-devel] Re: [Ips] Perfect Hashing for All 23 iSCSI Text Keys From: Ming Zhang To: Faraz Ahmed In-Reply-To: <00c301c566b3$e95ad370$5f0010ac@screech> References: <00be01c56425$e461f640$5f0010ac@screech> <1117630083.5507.16.camel@localhost.localdomain> <00c301c566b3$e95ad370$5f0010ac@screech> Organization: no-dole-available Date: Wed, 01 Jun 2005 09:55:19 -0400 Message-Id: <1117634119.5507.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mbrown@cs.uml.edu, ips@ietf.org, linux-iscsi development team X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1512952186==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1512952186== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xG7Okn8l9qcOPYrjAAw4" --=-xG7Okn8l9qcOPYrjAAw4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-06-01 at 07:11 -0700, Faraz Ahmed wrote: > Hi Ming; > Its just a finding i thought that should be shared. Any ways the yes, always thanks on this. > optimization may minuscule, since the space being small. But I think its > better than >=20 > if(!strcmp()) elseuif (!strcmp()) my first implementation my current implementation. :P > the lexical sort/search the second one not even think about this. :P too complex for me. >=20 > Anyways is there some very easy, very obvious way to do this search, whic= h > is better than the hash thing in terms of time. Do let me know. May be i > have just overlooked an approach. or tried to optimize something that is = in > the end going to optimize nothing in the large scheme of work. i donot know why you need to find the text key frequently. i assumed we only do it when setup a connection. so i prefer to spending optimization effort on data transfer path. ming >=20 > Regards > Faraz >=20 > ----- Original Message -----=20 > From: "Ming Zhang" > To: "Faraz Ahmed" > Cc: "Nicholas A. Bellinger" ; ; > ; "linux-iscsi development team" > > Sent: Wednesday, June 01, 2005 5:48 AM > Subject: [linux-iscsi-devel] Re: [Ips] Perfect Hashing for All 23 iSCSI T= ext > Keys >=20 >=20 --=-xG7Okn8l9qcOPYrjAAw4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCnb5HSYbkL5BnVYoRAgOzAJ9seTcCtDHRwOrhlzaHpWxdq/s9ggCfVR2B I2hJT9WwFtaWxKbxL2qR+Ig= =W9Gv -----END PGP SIGNATURE----- --=-xG7Okn8l9qcOPYrjAAw4-- --===============1512952186== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1512952186==-- From ips-bounces@ietf.org Thu Jun 02 10:29:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdqhI-0001CF-Cu; Thu, 02 Jun 2005 10:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdqhG-0001CA-Gt for ips@megatron.ietf.org; Thu, 02 Jun 2005 10:29:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20010 for ; Thu, 2 Jun 2005 10:29:20 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddr1E-0000NL-4x for ips@ietf.org; Thu, 02 Jun 2005 10:50:02 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc13) with SMTP id <20050602142907015009emmqe>; Thu, 2 Jun 2005 14:29:07 +0000 Message-ID: <000c01c5677f$6cec9a40$03031eac@ivivity.com> From: "Eddy Quicksall" To: "Mallikarjun C." , References: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com><427C0BAB.3080006@rose.hp.com> <429CF206.8060001@rose.hp.com> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Thu, 2 Jun 2005 10:29:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > LOGICAL UNIT RESET: All outstanding tasks from all initiators for > the LU identified by the LUN field in the LOGICAL > UNIT RESET task management function. Regarding "all initiators" above. In the context of 10.6.2(b), how would "The initiator" know anything about "all initiators"? Eddy ----- Original Message ----- From: "Mallikarjun C." To: Sent: Tuesday, May 31, 2005 7:23 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > Responding to my own comment (since I seem to have done such a fine job of > "aborting" this email thread)..... > >> I think it'd be a good idea to elaborate on LU Reset, and the two >> flavors of Target Reset in a formal IETF doc. > > I am concerned that the current lack of detailed specification would > allow targets that might even cause silent data corruptions to qualify as > RFC 3720-compliant. > > Here are what I believe to be semantics applicable to all TMF requests > that can potentially terminate multiple tasks. I do not know the IETF > process well enough here, but I suggest that we consider this text > replacing the existing section 10.6.2 in RFC 3720 - so the new text can > cover all the TMFs that can impact multiple tasks. This is basically a > superset of the current 10.6.2 semantics. > > Comments are welcome. > > Mallikarjun > > ----------------------------------------------------------------------- > > > 10.6.2. Task Management Actions on Requests Affecting Multiple Tasks > > The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, > TARGET WARM RESET, and TARGET COLD RESET Task Management function requests > consists of the following sequence of actions in the > specified order on each of the entities. > > The initiator: > a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET > WARM RESET/TARGET COLD RESET request. > b) Continues to respond to each target transfer tag received > for the "affected" (*) tasks. > c) Receives any responses that the target may provide for some > tasks among the affected tasks (may process them as usual > because they are guaranteed to be valid). > d) Receives the task management response, thus concluding > all the tasks in the set of affected tasks. > > > The Target: > > a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT > RESET/TARGET WARM RESET/TARGET COLD RESET request. > b) Waits for all currently valid target transfer tags of the > affected tasks to be responded. > c) Based on the CmdSN ordering, waits (concurrent with the > wait in step (b)) for all commands of the affected tasks > to be received. In the case of target-scoped requests > (i.e. TARGET WARM RESET and TARGET COLD RESET), all the > commands that are not received, as at the end of step (b), > in the command stream however can be considered to have > been received with no command waiting period - i.e. the > entire CmdSN space upto the CmdSN of the task management > function can be "plugged" (refer section 6.9 on how aborting > a specific task can implicitly plug the CmdSN of the task > being aborted) at the end of step (b). > d) Propagates the TMF request to and receives the response > from the target SCSI layer. > e) Takes note of last-sent StatSN on each of the connections > in the iSCSI session(s) (one or more) sharing the affected > tasks, and waits for acknowledgement of each StatSN (may > solicit for acknowledgement by way of a NOP-In). If some > tasks originate from non-iSCSI I_T_L nexi then the means by > which the target insures that all affected tasks have > returned their status to the initiator are defined by the > specific non-iSCSI transport protocol(s). > f) Sends the task set management response to the issuing > initiator. > > [*] "affected" tasks: > ABORT TASK SET: All outstanding tasks for the I_T_L nexus > identified by the LUN field in the ABORT TASK SET > task management function. > CLEAR TASK SET: All outstanding tasks in the task set for the LU > identified by the LUN field in the CLEAR TASK SET > task management function. > LOGICAL UNIT RESET: All outstanding tasks from all initiators for > the LU identified by the LUN field in the LOGICAL > UNIT RESET task management function. > TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from > all initiators across all LUs that the issuing > session has access to on the SCSI target device > hosting the iSCSI session. > > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jun 02 10:33:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdqlL-0003DF-S0; Thu, 02 Jun 2005 10:33:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdqlJ-0003D1-Iw for ips@megatron.ietf.org; Thu, 02 Jun 2005 10:33:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20471 for ; Thu, 2 Jun 2005 10:33:31 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddr5L-0000ZG-SX for ips@ietf.org; Thu, 02 Jun 2005 10:54:16 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc13) with SMTP id <20050602143323015009c36ae>; Thu, 2 Jun 2005 14:33:23 +0000 Message-ID: <001001c56780$0585d960$03031eac@ivivity.com> From: "Eddy Quicksall" To: "Mallikarjun C." , References: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com><427C0BAB.3080006@rose.hp.com> <429CF206.8060001@rose.hp.com> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Thu, 2 Jun 2005 10:33:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org For purposes of understanding this clearly, can you please note the reason for each step? I'm not suggesting this note be added to the RFC but it would be helpful for this email thread. Eddy ----- Original Message ----- From: "Mallikarjun C." To: Sent: Tuesday, May 31, 2005 7:23 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > Responding to my own comment (since I seem to have done such a fine job of > "aborting" this email thread)..... > >> I think it'd be a good idea to elaborate on LU Reset, and the two >> flavors of Target Reset in a formal IETF doc. > > I am concerned that the current lack of detailed specification would > allow targets that might even cause silent data corruptions to qualify as > RFC 3720-compliant. > > Here are what I believe to be semantics applicable to all TMF requests > that can potentially terminate multiple tasks. I do not know the IETF > process well enough here, but I suggest that we consider this text > replacing the existing section 10.6.2 in RFC 3720 - so the new text can > cover all the TMFs that can impact multiple tasks. This is basically a > superset of the current 10.6.2 semantics. > > Comments are welcome. > > Mallikarjun > > ----------------------------------------------------------------------- > > > 10.6.2. Task Management Actions on Requests Affecting Multiple Tasks > > The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, > TARGET WARM RESET, and TARGET COLD RESET Task Management function requests > consists of the following sequence of actions in the > specified order on each of the entities. > > The initiator: > a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET > WARM RESET/TARGET COLD RESET request. > b) Continues to respond to each target transfer tag received > for the "affected" (*) tasks. > c) Receives any responses that the target may provide for some > tasks among the affected tasks (may process them as usual > because they are guaranteed to be valid). > d) Receives the task management response, thus concluding > all the tasks in the set of affected tasks. > > > The Target: > > a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT > RESET/TARGET WARM RESET/TARGET COLD RESET request. > b) Waits for all currently valid target transfer tags of the > affected tasks to be responded. > c) Based on the CmdSN ordering, waits (concurrent with the > wait in step (b)) for all commands of the affected tasks > to be received. In the case of target-scoped requests > (i.e. TARGET WARM RESET and TARGET COLD RESET), all the > commands that are not received, as at the end of step (b), > in the command stream however can be considered to have > been received with no command waiting period - i.e. the > entire CmdSN space upto the CmdSN of the task management > function can be "plugged" (refer section 6.9 on how aborting > a specific task can implicitly plug the CmdSN of the task > being aborted) at the end of step (b). > d) Propagates the TMF request to and receives the response > from the target SCSI layer. > e) Takes note of last-sent StatSN on each of the connections > in the iSCSI session(s) (one or more) sharing the affected > tasks, and waits for acknowledgement of each StatSN (may > solicit for acknowledgement by way of a NOP-In). If some > tasks originate from non-iSCSI I_T_L nexi then the means by > which the target insures that all affected tasks have > returned their status to the initiator are defined by the > specific non-iSCSI transport protocol(s). > f) Sends the task set management response to the issuing > initiator. > > [*] "affected" tasks: > ABORT TASK SET: All outstanding tasks for the I_T_L nexus > identified by the LUN field in the ABORT TASK SET > task management function. > CLEAR TASK SET: All outstanding tasks in the task set for the LU > identified by the LUN field in the CLEAR TASK SET > task management function. > LOGICAL UNIT RESET: All outstanding tasks from all initiators for > the LU identified by the LUN field in the LOGICAL > UNIT RESET task management function. > TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from > all initiators across all LUs that the issuing > session has access to on the SCSI target device > hosting the iSCSI session. > > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jun 02 13:42:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddthg-0001o5-1W; Thu, 02 Jun 2005 13:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddthe-0001o0-RT for ips@megatron.ietf.org; Thu, 02 Jun 2005 13:41:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10626 for ; Thu, 2 Jun 2005 13:41:55 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddu1K-0003A3-HI for ips@ietf.org; Thu, 02 Jun 2005 14:02:41 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 2436F1351 for ; Thu, 2 Jun 2005 10:41:32 -0700 (PDT) Received: from [127.0.0.1] (unknown [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id 65E7981D7 for ; Thu, 2 Jun 2005 10:37:10 -0700 (PDT) Message-ID: <429F44CB.3040500@rose.hp.com> Date: Thu, 02 Jun 2005 10:41:31 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET References: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com><427C0BAB.3080006@rose.hp.com> <429CF206.8060001@rose.hp.com> <001001c56780$0585d960$03031eac@ivivity.com> In-Reply-To: <001001c56780$0585d960$03031eac@ivivity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org As I earlier noted in my response to Gwendal, there are three main goals that motivated us to spec the sequence of steps. Let me elaborate on those. The three are: 1. Maintaining a single ordered command flow I_T nexus abstraction to the target SCSI layer even with multi-connection sessions. Target iSCSI processing of a TMF request must maintain the single flow illusion - steps c & d on the target behavior correspond to this goal. 2. Maintaining a single ordered response flow I_T nexus abstraction to the initiator SCSI layer even with multi-connection sessions. Target must ensure that the initiator does not see "old" task responses (that chronologically preceded the TMF response) after seeing the TMF response - step e on the target behavior corresponds to this goal. 3. Draining all active TTTs corresponding to affected tasks before the TMF is acted on. Targets are better off if the TTTs are deterministically retired before the affected tasks are terminated. No need to worry about large-sized Data-out PDUs with stale TTTs arriving after the tasks are terminated - step b on the target behavior corresponds to this goal. The proposed text caters to these same goals as did the original text - except it now covers all TMFs that can impact multiple tasks. The only other notable thing in step (c) is the "plugging" part - it is just an optimization that says if all tasks on the I_T nexus will be aborted anyway (as with a target reset), there is no need to wait, the target can simply plug all missing CmdSN slots and move on with TMF processing. Goal #1 is still met because target SCSI layer only sees ordered commands. Hope that clarifies it. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Eddy Quicksall wrote: > For purposes of understanding this clearly, can you please note the > reason for each step? I'm not suggesting this note be added to the RFC > but it would be helpful for this email thread. > > Eddy > > ----- Original Message ----- From: "Mallikarjun C." > To: > Sent: Tuesday, May 31, 2005 7:23 PM > Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > > >> Responding to my own comment (since I seem to have done such a fine >> job of "aborting" this email thread)..... >> >>> I think it'd be a good idea to elaborate on LU Reset, and the two >>> flavors of Target Reset in a formal IETF doc. >> >> >> I am concerned that the current lack of detailed specification would >> allow targets that might even cause silent data corruptions to qualify >> as RFC 3720-compliant. >> >> Here are what I believe to be semantics applicable to all TMF requests >> that can potentially terminate multiple tasks. I do not know the IETF >> process well enough here, but I suggest that we consider this text >> replacing the existing section 10.6.2 in RFC 3720 - so the new text >> can cover all the TMFs that can impact multiple tasks. This is >> basically a superset of the current 10.6.2 semantics. >> >> Comments are welcome. >> >> Mallikarjun >> >> ----------------------------------------------------------------------- >> >> >> 10.6.2. Task Management Actions on Requests Affecting Multiple Tasks >> >> The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, >> TARGET WARM RESET, and TARGET COLD RESET Task Management function >> requests consists of the following sequence of actions in the >> specified order on each of the entities. >> >> The initiator: >> a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET >> WARM RESET/TARGET COLD RESET request. >> b) Continues to respond to each target transfer tag received >> for the "affected" (*) tasks. >> c) Receives any responses that the target may provide for some >> tasks among the affected tasks (may process them as usual >> because they are guaranteed to be valid). >> d) Receives the task management response, thus concluding >> all the tasks in the set of affected tasks. >> >> >> The Target: >> >> a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT >> RESET/TARGET WARM RESET/TARGET COLD RESET request. >> b) Waits for all currently valid target transfer tags of the >> affected tasks to be responded. >> c) Based on the CmdSN ordering, waits (concurrent with the >> wait in step (b)) for all commands of the affected tasks >> to be received. In the case of target-scoped requests >> (i.e. TARGET WARM RESET and TARGET COLD RESET), all the >> commands that are not received, as at the end of step (b), >> in the command stream however can be considered to have >> been received with no command waiting period - i.e. the >> entire CmdSN space upto the CmdSN of the task management >> function can be "plugged" (refer section 6.9 on how aborting >> a specific task can implicitly plug the CmdSN of the task >> being aborted) at the end of step (b). >> d) Propagates the TMF request to and receives the response >> from the target SCSI layer. >> e) Takes note of last-sent StatSN on each of the connections >> in the iSCSI session(s) (one or more) sharing the affected >> tasks, and waits for acknowledgement of each StatSN (may >> solicit for acknowledgement by way of a NOP-In). If some >> tasks originate from non-iSCSI I_T_L nexi then the means by >> which the target insures that all affected tasks have >> returned their status to the initiator are defined by the >> specific non-iSCSI transport protocol(s). >> f) Sends the task set management response to the issuing >> initiator. >> >> [*] "affected" tasks: >> ABORT TASK SET: All outstanding tasks for the I_T_L nexus >> identified by the LUN field in the ABORT TASK SET >> task management function. >> CLEAR TASK SET: All outstanding tasks in the task set for the LU >> identified by the LUN field in the CLEAR TASK SET >> task management function. >> LOGICAL UNIT RESET: All outstanding tasks from all initiators for >> the LU identified by the LUN field in the LOGICAL >> UNIT RESET task management function. >> TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from >> all initiators across all LUs that the issuing >> session has access to on the SCSI target device >> hosting the iSCSI session. >> >> >> >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jun 02 20:00:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddzbp-0006l9-Si; Thu, 02 Jun 2005 20:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddzbn-0006l3-9o for ips@megatron.ietf.org; Thu, 02 Jun 2005 20:00:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12900 for ; Thu, 2 Jun 2005 20:00:17 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddzvu-00056A-U3 for ips@ietf.org; Thu, 02 Jun 2005 20:21:07 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc11) with SMTP id <20050603000005013004hfdbe>; Fri, 3 Jun 2005 00:00:09 +0000 Message-ID: <000301c567cf$34d0af70$03031eac@ivivity.com> From: "Eddy Quicksall" To: "Mallikarjun C." , References: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com><427C0BAB.3080006@rose.hp.com><429CF206.8060001@rose.hp.com><001001c56780$0585d960$03031eac@ivivity.com> <429F44CB.3040500@rose.hp.com> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Thu, 2 Jun 2005 20:00:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Thank you. That is a very good explanation. Two things I have always wondered: 1) Is it required (via SAM-2, SPC-2, etc) that the TMF only act on commands with lower CmdSN's? 2) Is it necessary to state when the TMF is passed to the SCSI layer? It would seem that that is an implementation issue and as long as the target can emulate this behavior to the initiator then it should not be specified in this spec. Eddy ----- Original Message ----- From: "Mallikarjun C." To: Sent: Thursday, June 02, 2005 1:41 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > As I earlier noted in my response to Gwendal, there are three main goals > that motivated us to spec the sequence of steps. Let me elaborate on > those. The three are: > > 1. Maintaining a single ordered command flow I_T nexus abstraction to the > target SCSI layer even with multi-connection sessions. > Target iSCSI processing of a TMF request must maintain the > single flow illusion - steps c & d on the target behavior > correspond to this goal. > > 2. Maintaining a single ordered response flow I_T nexus abstraction to the > initiator SCSI layer even with multi-connection sessions. > Target must ensure that the initiator does not see "old" task > responses (that chronologically preceded the TMF response) after > seeing the TMF response - step e on the target behavior corresponds > to this goal. > > 3. Draining all active TTTs corresponding to affected tasks before the TMF > is acted on. > Targets are better off if the TTTs are deterministically retired > before the affected tasks are terminated. No need to worry about > large-sized Data-out PDUs with stale TTTs arriving after the tasks > are terminated - step b on the target behavior corresponds to this > goal. > > > The proposed text caters to these same goals as did the original text - > except it now covers all TMFs that can impact multiple tasks. > > The only other notable thing in step (c) is the "plugging" part - it is > just an optimization that says if all tasks on the I_T nexus will be > aborted anyway (as with a target reset), there is no need to wait, the > target can simply plug all missing CmdSN slots and move on with TMF > processing. Goal #1 is still met because target SCSI layer only sees > ordered commands. > > Hope that clarifies it. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Eddy Quicksall wrote: >> For purposes of understanding this clearly, can you please note the >> reason for each step? I'm not suggesting this note be added to the RFC >> but it would be helpful for this email thread. >> >> Eddy >> >> ----- Original Message ----- From: "Mallikarjun C." >> To: >> Sent: Tuesday, May 31, 2005 7:23 PM >> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET >> >> >>> Responding to my own comment (since I seem to have done such a fine job >>> of "aborting" this email thread)..... >>> >>>> I think it'd be a good idea to elaborate on LU Reset, and the two >>>> flavors of Target Reset in a formal IETF doc. >>> >>> >>> I am concerned that the current lack of detailed specification would >>> allow targets that might even cause silent data corruptions to qualify >>> as RFC 3720-compliant. >>> >>> Here are what I believe to be semantics applicable to all TMF requests >>> that can potentially terminate multiple tasks. I do not know the IETF >>> process well enough here, but I suggest that we consider this text >>> replacing the existing section 10.6.2 in RFC 3720 - so the new text can >>> cover all the TMFs that can impact multiple tasks. This is basically a >>> superset of the current 10.6.2 semantics. >>> >>> Comments are welcome. >>> >>> Mallikarjun >>> >>> ----------------------------------------------------------------------- >>> >>> >>> 10.6.2. Task Management Actions on Requests Affecting Multiple Tasks >>> >>> The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, >>> TARGET WARM RESET, and TARGET COLD RESET Task Management function >>> requests consists of the following sequence of actions in the >>> specified order on each of the entities. >>> >>> The initiator: >>> a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET >>> WARM RESET/TARGET COLD RESET request. >>> b) Continues to respond to each target transfer tag received >>> for the "affected" (*) tasks. >>> c) Receives any responses that the target may provide for some >>> tasks among the affected tasks (may process them as usual >>> because they are guaranteed to be valid). >>> d) Receives the task management response, thus concluding >>> all the tasks in the set of affected tasks. >>> >>> >>> The Target: >>> >>> a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT >>> RESET/TARGET WARM RESET/TARGET COLD RESET request. >>> b) Waits for all currently valid target transfer tags of the >>> affected tasks to be responded. >>> c) Based on the CmdSN ordering, waits (concurrent with the >>> wait in step (b)) for all commands of the affected tasks >>> to be received. In the case of target-scoped requests >>> (i.e. TARGET WARM RESET and TARGET COLD RESET), all the >>> commands that are not received, as at the end of step (b), >>> in the command stream however can be considered to have >>> been received with no command waiting period - i.e. the >>> entire CmdSN space upto the CmdSN of the task management >>> function can be "plugged" (refer section 6.9 on how aborting >>> a specific task can implicitly plug the CmdSN of the task >>> being aborted) at the end of step (b). >>> d) Propagates the TMF request to and receives the response >>> from the target SCSI layer. >>> e) Takes note of last-sent StatSN on each of the connections >>> in the iSCSI session(s) (one or more) sharing the affected >>> tasks, and waits for acknowledgement of each StatSN (may >>> solicit for acknowledgement by way of a NOP-In). If some >>> tasks originate from non-iSCSI I_T_L nexi then the means by >>> which the target insures that all affected tasks have >>> returned their status to the initiator are defined by the >>> specific non-iSCSI transport protocol(s). >>> f) Sends the task set management response to the issuing >>> initiator. >>> >>> [*] "affected" tasks: >>> ABORT TASK SET: All outstanding tasks for the I_T_L nexus >>> identified by the LUN field in the ABORT TASK SET >>> task management function. >>> CLEAR TASK SET: All outstanding tasks in the task set for the LU >>> identified by the LUN field in the CLEAR TASK SET >>> task management function. >>> LOGICAL UNIT RESET: All outstanding tasks from all initiators for >>> the LU identified by the LUN field in the LOGICAL >>> UNIT RESET task management function. >>> TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from >>> all initiators across all LUs that the issuing >>> session has access to on the SCSI target device >>> hosting the iSCSI session. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jun 03 08:51:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBdv-0001PU-PV; Fri, 03 Jun 2005 08:51:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBdl-0001PL-B6 for ips@megatron.ietf.org; Fri, 03 Jun 2005 08:51:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23887 for ; Fri, 3 Jun 2005 08:51:08 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeBxy-0003Bf-Vp for ips@ietf.org; Fri, 03 Jun 2005 09:12:04 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j53Cp4rN006798; Fri, 3 Jun 2005 08:51:05 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jun 2005 08:51:04 -0400 Message-ID: To: cbm@rose.hp.com, ips@ietf.org Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET Date: Fri, 3 Jun 2005 08:51:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.3.9 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, > I am concerned that the current lack of detailed specification would > allow targets that might even cause silent data corruptions > to qualify as RFC 3720-compliant. > > Here are what I believe to be semantics applicable to all TMF requests > that can potentially terminate multiple tasks. I do not know the IETF > process well enough here, but I suggest that we consider this text > replacing the existing section 10.6.2 in RFC 3720 - so the new text can > cover all the TMFs that can impact multiple tasks. This is basically a > superset of the current 10.6.2 semantics. IETF does have an errata process, but (IMHO) it's not a great venue for something like this that it's important for implementers to pay attention to. What I would suggest is that we start an Internet-Draft that is intended to become an Implementers Guide RFC (standards track) to include both technical corrections like this one, and explanations of subtle points such as how to deal with (what appear to be) REPORT LUNS overruns as discussed here earlier. An available example is that an implementers guide draft is being maintained for SCTP (see draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that an iSCSI implementers guide won't grow to that size. For this task management issue, explaining what the problem is and why the change fixes it in an implementers guide is at least as important as specifying the change. For the REPORT LUNS overruns, the implementers guide text would be an explanation of why no change is needed, including some elaboration on the (less than completely obvious) SPC-2 text that specifies the behavior of REPORT LUNS in this circumstance. Before I go looking for another volunteer, would you be interested in editing an implementers guide Internet Draft? Between Julian and I, we should be able write the REPORT LUNS explanation paragraph or two. 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jun 03 12:45:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFIc-0006B6-9b; Fri, 03 Jun 2005 12:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFIZ-0006B1-Eb for ips@megatron.ietf.org; Fri, 03 Jun 2005 12:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13528 for ; Fri, 3 Jun 2005 12:45:28 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([216.148.227.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeFcp-0000AH-SK for ips@ietf.org; Fri, 03 Jun 2005 13:06:28 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc14) with SMTP id <20050603164520014001nc0ve>; Fri, 3 Jun 2005 16:45:21 +0000 Message-ID: <000301c5685b$a1aeb060$03031eac@ivivity.com> From: "Eddy Quicksall" To: , , References: Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Fri, 3 Jun 2005 12:45:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org If you are going to write this guide, I would like to suggest that a paragraph be added saying something like "the initiator and target are not expected to catch all protocol errors introduced by the other party and it is the implementers option as to which errors may be caught due to internal dynamics, crash dynamics or data corruption". Eddy ----- Original Message ----- From: To: ; Sent: Friday, June 03, 2005 8:51 AM Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET > Mallikarjun, > >> I am concerned that the current lack of detailed specification would >> allow targets that might even cause silent data corruptions >> to qualify as RFC 3720-compliant. >> >> Here are what I believe to be semantics applicable to all TMF requests >> that can potentially terminate multiple tasks. I do not know the IETF >> process well enough here, but I suggest that we consider this text >> replacing the existing section 10.6.2 in RFC 3720 - so the new text can >> cover all the TMFs that can impact multiple tasks. This is basically a >> superset of the current 10.6.2 semantics. > > IETF does have an errata process, but (IMHO) it's not a great venue > for something like this that it's important for implementers to pay > attention to. What I would suggest is that we start an Internet-Draft > that is intended to become an Implementers Guide RFC (standards track) > to include both technical corrections like this one, and explanations > of subtle points such as how to deal with (what appear to be) REPORT > LUNS overruns as discussed here earlier. An available example is that > an implementers guide draft is being maintained for SCTP (see > draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that > an iSCSI implementers guide won't grow to that size. > > For this task management issue, explaining what the problem is and why > the change fixes it in an implementers guide is at least as important as > specifying the change. For the REPORT LUNS overruns, the implementers > guide text would be an explanation of why no change is needed, including > some elaboration on the (less than completely obvious) SPC-2 text that > specifies the behavior of REPORT LUNS in this circumstance. Before I > go looking for another volunteer, would you be interested in editing > an implementers guide Internet Draft? Between Julian and I, we should > be able write the REPORT LUNS explanation paragraph or two. > > 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 > ---------------------------------------------------- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jun 03 19:12:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeLLJ-0004Fh-GX; Fri, 03 Jun 2005 19:12:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeLLH-0004FZ-AC for ips@megatron.ietf.org; Fri, 03 Jun 2005 19:12:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23458 for ; Fri, 3 Jun 2005 19:12:40 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeLfa-0004CU-CP for ips@ietf.org; Fri, 03 Jun 2005 19:33:43 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j53NCdbJ027766 for ; Fri, 3 Jun 2005 19:12:39 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jun 2005 19:12:39 -0400 Message-ID: To: ips@ietf.org Date: Fri, 3 Jun 2005 19:12:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.3.29 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ips] WG Last Call Review: DA X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I have reviewed the DA draft, draft-ietf-ips-iwarp-da-02.txt, and in addition to a number of editorial comments that I will send to Mallikarjun, I have one important technical comment - The Security Considerations section essentially says "there are no new security considerations because DA does not define a wire protocol." That is not correct because DA introduces at least two architectural concepts to iSCSI that do have security implications: - Control/Data separation. The mechanisms for transmission of iSCSI control vs. data are deliberately split by DA, and there is no requirement that they even use the same transport medium. This introduces new opportunities for an attacker to fiddle with things, and may place additional security responsibility on an iSCSI-DA implementation over and above an iSCSI implementation. - Explicit resource management/control. DA introduces explicit management of resources at the DI interface, including data buffers and Datamover connection resources. The latter in particular is likely to be a limited class of resource in some anticipated implementations. Some discussion is needed on the possibility of a denial-of- service attack via resource exhaustion and the functional responsibility of an iSCSI-DA implementation to defend against this. A new Security Considerations section will be needed to address at least these areas. 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jun 03 21:31:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeNVZ-0002gB-HT; Fri, 03 Jun 2005 21:31:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeNVY-0002f8-Hv for ips@megatron.ietf.org; Fri, 03 Jun 2005 21:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02539 for ; Fri, 3 Jun 2005 21:31:26 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeNpr-00070y-SB for ips@ietf.org; Fri, 03 Jun 2005 21:52:30 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j541VNgX016797 for ; Fri, 3 Jun 2005 21:31:23 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jun 2005 21:31:23 -0400 Message-ID: To: ips@ietf.org Date: Fri, 3 Jun 2005 21:31:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.3.34 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CHILD_PORN_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Ips] WG Last Call Review: iSER X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, and in addition to editorial issues that I will send directly to Mike, I found a number of technical issues: (1) Section 3.3 has a structural problem in that the first sentence says "should satisfy" and the remaining sentences to be satisfied are expressed as "MUST" requirements. The net result is that all the requirements in that section are "should" requirements, which is not what was intended. The first sentence needs to be rewritten to say something to the effect of "In order to use iSER, the following MUST be done:" . (2) Section 3.3, item 1. says "MUST negotiate the RDMAExtensions key to "Yes" " Since the key is negotiated (not declared) and it takes two to negotiate, that requirement cannot be achieved by an implementation if the other side doesn't cooperate. This needs to be rewritten to talk about offering the key as "Yes" and replying as "Yes" and that if the result is not "Yes" then iSER is not used (traditional iSCSI is used instead). (3) Section 3.3., item 5. says "MUST successfully negotiate the TargetRecvDataSegmentLength key". Again there's a "takes two to negotiate" problem, and the "failed to successfully negotiate" case needs to be specified. (4) Section 5.1, last two paragraphs have similar problems in that they specify required negotiation behavior without describing what to do when the other side doesn't cooperate or do what it is supposed to. Those failure cases need to be covered. (5) Section 5.1.2, in the Note at the very end of the section about two steps needing to be atomic, "must" should be "MUST". (6) Section 5.1.3 is missing specification and explanation of version negotiation and version numbers in the iSER Hello Exchange. The error case instructions for when version negotiation fails need to be copied here in addition to their current location in Section 10.1.3.2 . (7) Section 7.3.9 - I believe sending of Login Request or Login Response in Datamover mode is always an error. This section should say so and say what to do about it. (8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling does not work because the instruction in 10.2.1 to handle SNACK as per RFC 3720 would require retransmission of non-existent Data and R2T PDUs. I can see a couple of possible corrective approaches: a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK PDUs (instead of the current SHOULD NOT) and change Section 10.2.1 to define reception of any SNACK PDU as an error. b) Put limits on what SNACK PDUs can be used to recover (Status only?) in Section 7.3.11, and modify Section 10.2.1 to say how to recover that and what to do when a prohibited SNACK is received. (9) Section 8.1 uses the phrase "buffer underrun" for an "out of buffers" condition. That should be "buffer exhaustion". (10) Section 8.4 could result in a situation where an iSER Target cannot send a Reject PDU that an iSCSI Target would be able send. It needs to explain what to do in that situation. (11) Section 11 on Security Considerations is weak, but the overall approach of appealing to security considerations in other specifications is probably ok. This section needs to be strengthened by saying that since iSER is still functionally iSCSI, all of the iSCSI security considerations in RFC 3720 apply, and it should also reference the discussion of iSCSI security in RFC 3723. 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Jun 04 12:02:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Deb6d-0000Z5-TZ; Sat, 04 Jun 2005 12:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Deb6a-0000We-4z for ips@megatron.ietf.org; Sat, 04 Jun 2005 12:02:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13317 for ; Sat, 4 Jun 2005 12:02:34 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DebR2-0006zG-2a for ips@ietf.org; Sat, 04 Jun 2005 12:23:45 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc12) with SMTP id <20050604160224014003ihj8e>; Sat, 4 Jun 2005 16:02:25 +0000 Message-ID: <001201c5691e$ce5a0ab0$03031eac@ivivity.com> From: "Eddy Quicksall" To: , "William Studenmund" , "Mallikarjun C." Date: Sat, 4 Jun 2005 12:02:26 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Subject: [Ips] DataACK SNACK immediatly X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0480785204==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0480785204== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C568FD.46027D30" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C568FD.46027D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 10.7.2 says "...the initiator MUST issue a SNACK of type DataACK except = when it is able to acknowledge the status for the task immediately via = ExpStatSN on other outbound PDUs ..." Refering to the below transmission, 1) Has the initiator committed a protocol error by not sending the = DataACK SNACK immeditaly after frame 39? Note that the time between 39 = and 41 is extreemly small. 2) If so, MUST the target detect the protocol error and send a reject = after receiving frame 45? 3) What if the queue depth is only 1, does that change your answer? >From Targets perspective: ln dir cmd S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT Run -- --- --- - - ----- -------- ------ --------- ------ --- --- 38 I->T Read Cap 125 4 F4 39 T->I Data In S A 126 4 0 40 I->T Read 126 4 F5 41 T->I Data In 127 0 0 42 T->I Data In 127 0 1 44 T->I Data In S A 127 5 2 45 I->T Data SNACK 5 F5 1,1 >From Initiators perspective: ln dir cmd S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT Run -- --- --- - - ----- -------- ------ --------- ------ --- --- 38 I->T Read Cap 125 4 F4 40 I->T Read 126 4 F5 39 T->I Data In S A 126 4 0 41 T->I Data In 127 0 0 42 T->I Data In 127 0 1 44 T->I Data In S A 127 5 2 45 I->T Data SNACK 5 F5 1,1 ------=_NextPart_000_000F_01C568FD.46027D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
10.7.2 says "...the = initiator MUST=20 issue a SNACK of type DataACK except when it is able to acknowledge the = status=20 for the task immediately via ExpStatSN on other outbound PDUs=20 ..."
 
Refering to the below=20 transmission,
1) Has the initiator committed = a protocol=20 error by not sending the DataACK SNACK immeditaly after frame 39? Note = that the=20 time between 39 and 41 is extreemly small.
2) If so, MUST the target = detect the=20 protocol error and send a reject after receiving frame 45?
3) What if the queue depth is = only 1, does=20 that change your answer?
 
From Targets=20 perspective:
 
ln dir =20 cmd      S A CmdSN ExpCmdSN StatSN ExpStatSN = DataSN ITT=20 Run
-- ---  ---      - - ----- -------- = ------=20 --------- ------ --- ---
38 I->T Read = Cap     =20 125           &nbs= p;        =20 4            = =20 F4
39 T->I Data In  S=20 A        =20 126     =20 4            =     =20 0
40 I->T = Read         =20 126           &nbs= p;        =20 4            = =20 F5
41 T->I Data=20 In            = ; =20 127     =20 0            =     =20 0
42 T->I Data=20 In            = ; =20 127     =20 0            =     =20 1
44 T->I Data In  S=20 A        =20 127     =20 5            =     =20 2
45 I->T Data=20 SNACK           &n= bsp;           &nb= sp;   =20 5            = =20 F5  1,1
 
From Initiators=20 perspective:
 
ln dir =20 cmd      S A CmdSN ExpCmdSN StatSN ExpStatSN = DataSN ITT=20 Run
-- ---  ---      - - ----- -------- = ------=20 --------- ------ --- ---
38 I->T Read = Cap     =20 125           &nbs= p;        =20 4            = =20 F4
40 I->T = Read         =20 126           &nbs= p;        =20 4            = =20 F5
39 T->I Data In  S=20 A        =20 126     =20 4            =     =20 0
41 T->I Data=20 In            = ; =20 127     =20 0            =     =20 0
42 T->I Data=20 In            = ; =20 127     =20 0            =     =20 1
44 T->I Data In  S=20 A        =20 127     =20 5            =     =20 2
45 I->T Data=20 SNACK           &n= bsp;           &nb= sp;   =20 5            = =20 F5  1,1
 
------=_NextPart_000_000F_01C568FD.46027D30-- --===============0480785204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0480785204==-- From ips-bounces@ietf.org Sun Jun 05 05:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DerVn-0006sy-NC; Sun, 05 Jun 2005 05:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DerVk-0006sn-7w; Sun, 05 Jun 2005 05:33:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24313; Sun, 5 Jun 2005 05:33:38 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DerqL-0003Xh-UW; Sun, 05 Jun 2005 05:54:58 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j559XKa6166256; Sun, 5 Jun 2005 09:33:20 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j559XK0U179358; Sun, 5 Jun 2005 11:33:20 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j559XKKO027842; Sun, 5 Jun 2005 11:33:20 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j559XJXI027835; Sun, 5 Jun 2005 11:33:19 +0200 In-Reply-To: <001201c5691e$ce5a0ab0$03031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] DataACK SNACK immediatly MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05032005NP May 03, 2005 From: Julian Satran Message-ID: Date: Sun, 5 Jun 2005 12:33:19 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 05/06/2005 12:33:19, Serialize complete at 05/06/2005 12:33:19 X-Spam-Score: 2.0 (++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: ips@ietf.org, William Studenmund , ips-bounces@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0385973540==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0385973540== Content-Type: text/html; charset="US-ASCII"
Eddy,

IMHO the initiator has not committed an error since it has acked the status. Queue depth is also not relevant as long as the initiator obeyed the MaxCmdSN as a target may change the queue depth at it's convenience.

However the following initiator sequence woud have been a protocol error.

45 I->T Data SNACK                            4             F5  1,1
46 I->T Read          127                     6 (or 5)      F6
 _______________________________________________

provided that they came on the same connection (as your example seem to indicate).
The rule is there to prevent an initiator from deliberately holding up resources at the target and is based on the assumption that an initiator does not gain anything by processing PDUs out of order (admittedly this is no always true).

Julo



"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

04/06/2005 19:02

To
<ips@ietf.org>, "William Studenmund" <wrstuden@wasabisystems.com>, "Mallikarjun C." <cbm@rose.hp.com>
cc
Subject
[Ips] DataACK SNACK immediatly





10.7.2 says "...the initiator MUST issue a SNACK of type DataACK except when it is able to acknowledge the status for the task immediately via ExpStatSN on other outbound PDUs ..."
 
Refering to the below transmission,
1) Has the initiator committed a protocol error by not sending the DataACK SNACK immeditaly after frame 39? Note that the time between 39 and 41 is extreemly small.
2) If so, MUST the target detect the protocol error and send a reject after receiving frame 45?
3) What if the queue depth is only 1, does that change your answer?
 
From Targets perspective:
 
ln dir  cmd      S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT Run
-- ---  ---      - - ----- -------- ------ --------- ------ --- ---
38 I->T Read Cap      125                     4             F4
39 T->I Data In  S A         126      4                 0
40 I->T Read          126                     4             F5
41 T->I Data In              127      0                 0
42 T->I Data In              127      0                 1
44 T->I Data In  S A         127      5                 2
45 I->T Data SNACK                            5             F5  1,1
 
From Initiators perspective:
 
ln dir  cmd      S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT Run
-- ---  ---      - - ----- -------- ------ --------- ------ --- ---
38 I->T Read Cap      125                     4             F4
40 I->T Read          126                     4             F5
39 T->I Data In  S A         126      4                 0
41 T->I Data In              127      0                 0
42 T->I Data In              127      0                 1
44 T->I Data In  S A         127      5                 2
45 I->T Data SNACK                            5             F5  1,1
 _______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--===============0385973540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0385973540==-- From ips-bounces@ietf.org Sun Jun 05 11:29:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dex43-00021i-La; Sun, 05 Jun 2005 11:29:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dex40-00021T-G8; Sun, 05 Jun 2005 11:29:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13932; Sun, 5 Jun 2005 11:29:22 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([216.148.227.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DexOf-0001Pi-Fz; Sun, 05 Jun 2005 11:50:46 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc14) with SMTP id <20050605152912014001gfppe>; Sun, 5 Jun 2005 15:29:13 +0000 Message-ID: <000401c569e3$54ab43d0$03031eac@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] DataACK SNACK immediatly Date: Sun, 5 Jun 2005 11:29:11 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: ips@ietf.org, William Studenmund , ips-bounces@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088813591==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0088813591== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C569C1.CB817230" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C569C1.CB817230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you very much. Can I assume your answer would be the same if the initiator = sends/receives the PDU's in the same time sequence that the target = sends/receives the PDU's (i.e. with all frames running in numerical = order). Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: Mallikarjun C. ; ips@ietf.org ; ips-bounces@ietf.org ; William = Studenmund=20 Sent: Sunday, June 05, 2005 5:33 AM Subject: Re: [Ips] DataACK SNACK immediatly Eddy,=20 IMHO the initiator has not committed an error since it has acked the = status. Queue depth is also not relevant as long as the initiator obeyed = the MaxCmdSN as a target may change the queue depth at it's convenience. = However the following initiator sequence woud have been a protocol = error.=20 45 I->T Data SNACK 4 F5 1,1=20 46 I->T Read 127 6 (or 5) F6=20 _______________________________________________=20 provided that they came on the same connection (as your example seem = to indicate).=20 The rule is there to prevent an initiator from deliberately holding up = resources at the target and is based on the assumption that an initiator = does not gain anything by processing PDUs out of order (admittedly this = is no always true).=20 Julo=20 "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 04/06/2005 19:02=20 To , "William Studenmund" = , "Mallikarjun C." =20 cc =20 Subject [Ips] DataACK SNACK immediatly=20 =20 =20 10.7.2 says "...the initiator MUST issue a SNACK of type DataACK = except when it is able to acknowledge the status for the task = immediately via ExpStatSN on other outbound PDUs ..."=20 =20 Refering to the below transmission,=20 1) Has the initiator committed a protocol error by not sending the = DataACK SNACK immeditaly after frame 39? Note that the time between 39 = and 41 is extreemly small.=20 2) If so, MUST the target detect the protocol error and send a reject = after receiving frame 45?=20 3) What if the queue depth is only 1, does that change your answer?=20 =20 From Targets perspective:=20 =20 ln dir cmd S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT Run -- --- --- - - ----- -------- ------ --------- ------ --- --- 38 I->T Read Cap 125 4 F4 39 T->I Data In S A 126 4 0 40 I->T Read 126 4 F5 41 T->I Data In 127 0 0 42 T->I Data In 127 0 1 44 T->I Data In S A 127 5 2 45 I->T Data SNACK 5 F5 1,1=20 =20 From Initiators perspective:=20 =20 ln dir cmd S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT Run -- --- --- - - ----- -------- ------ --------- ------ --- --- 38 I->T Read Cap 125 4 F4 40 I->T Read 126 4 F5 39 T->I Data In S A 126 4 0 41 T->I Data In 127 0 0 42 T->I Data In 127 0 1 44 T->I Data In S A 127 5 2 45 I->T Data SNACK 5 F5 1,1=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0001_01C569C1.CB817230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you very much.
 
Can I assume your answer would be the same if the=20 initiator sends/receives the PDU's in the same time sequence that=20 the target sends/receives the PDU's (i.e. with all frames = running in=20 numerical order).
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Cc: Mallikarjun C. ; ips@ietf.org ; ips-bounces@ietf.org ; William Studenmund =
Sent: Sunday, June 05, 2005 = 5:33 AM
Subject: Re: [Ips] DataACK = SNACK=20 immediatly


Eddy, =

IMHO the initiator has not committed an = error since it=20 has acked the status. Queue depth is also not relevant as long as the=20 initiator obeyed the MaxCmdSN as a target may change the queue depth = at it's=20 convenience.

However = the following=20 initiator sequence woud have been a protocol error. =

45 I->T Data SNACK     =    =20                    4 =  =20           F5  1,1
46 I->T Read       =  =20  127                 =  =20   6 (or 5)      F6
 _______________________________________________=20

provided that they came on = the same=20 connection (as your example seem to indicate).
The rule is there to prevent an initiator = from=20 deliberately holding up resources at the target and is based on the = assumption=20 that an initiator does not gain anything by processing PDUs out of = order=20 (admittedly this is no always true).

Julo



"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net> =
Sent by: ips-bounces@ietf.org=20

04/06/2005 19:02

To
<ips@ietf.org>, = "William=20 Studenmund" <wrstuden@wasabisystems.com>, = "Mallikarjun C."=20 <cbm@rose.hp.com>=20
cc
Subject
[Ips] DataACK SNACK=20 immediatly

=




10.7.2 says "...the initiator MUST issue = a SNACK of=20 type DataACK except when it is able to acknowledge the status for the = task=20 immediately via ExpStatSN on other outbound PDUs ..."
 
Refering to the below=20 transmission,
1) Has = the initiator=20 committed a protocol error by not sending the DataACK SNACK immeditaly = after=20 frame 39? Note that the time between 39 and 41 is extreemly = small.=20
2) If so, MUST the target = detect the=20 protocol error and send a reject after receiving frame 45? =
3) What if the queue depth is only 1, = does that=20 change your answer?
 
From Targets perspective: =
 
ln dir =  cmd=20      S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT = Run
--=20 ---  ---      - - ----- -------- ------ --------- = ------=20 --- ---
38 I->T Read Cap      125     =  =20               4     =    =20     F4
39 T->I Data In  S A       =  =20 126      4             =  =20   0
40 I->T Read          126 =  =20                   4 =    =20         F5
41 T->I Data In     =  =20        127      0     =  =20           0
42 T->I Data In   =  =20          127      0   =  =20             1
44 T->I Data In =  S A=20         127      5     =  =20           2
45 I->T Data SNACK   =  =20                     =  =20  5             F5  1,1=20
 
From=20 Initiators perspective:
  =
ln dir  cmd      S A = CmdSN=20 ExpCmdSN StatSN ExpStatSN DataSN ITT Run
-- ---  ---   =  =20  - - ----- -------- ------ --------- ------ --- ---
38 I->T = Read=20 Cap      125             =  =20       4             = F4
40=20 I->T Read          126     =    =20             4       =    =20   F5
39 T->I Data In  S A         = 126=20      4               =  =20 0
41 T->I Data In             =  127=20      0               =  =20 0
42 T->I Data In             =  127=20      0               =  =20 1
44 T->I Data In  S A         127 =  =20    5                 = 2
45=20 I->T Data SNACK               =  =20            5         =  =20   F5  1,1
 _______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0001_01C569C1.CB817230-- --===============0088813591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0088813591==-- From ips-bounces@ietf.org Mon Jun 06 11:33:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJbS-0001Jb-CB; Mon, 06 Jun 2005 11:33:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJbQ-0001JT-2k for ips@megatron.ietf.org; Mon, 06 Jun 2005 11:33:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10992 for ; Mon, 6 Jun 2005 11:33:21 -0400 (EDT) From: dcuddihy@attotech.com Received: from noteserv1.attotech.com ([12.32.232.51]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfJwI-0003it-82 for ips@ietf.org; Mon, 06 Jun 2005 11:54:58 -0400 To: , "Mallikarjun C." MIME-Version: 1.0 Message-ID: Date: Mon, 6 Jun 2005 11:33:16 -0400 X-Spam-Score: 0.9 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Subject: [Ips] CmdSn in login request X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0420597938==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0420597938== Content-Type: multipart/alternative; boundary="=_alternative 005571A285257018_=" This is a multipart message in MIME format. --=_alternative 005571A285257018_= Content-Type: text/plain; charset="US-ASCII" 10.12 says: "Login Requests are always considered as immediate." and 10.12.8 says: "CmdSN is either the initial command sequence number of a session (for ... the "leading" login), or the command sequence number in the command stream if the login is for a new connection in an existing session." So what happens if the last command prior to a multi-connection login was lost? In this example: 3 connections exist between the initiator and the target. Initiator sends CmdSn 0x3F on a connection which fails at the target. (The TCP connection fails, for whatever reason.) After the appropriate timeout, the initiator attempts a recovery login using CmdSN 0x40 -since it doesn't know what happened to the command with CmdSn 0x3F. The target accepts the login, which is handled as an immediate, but responds with ExpCmdSn of 0x3F, since that's the current session-wide ExpCmdSn. This seems to be one of those CmdSn 'holes' which gets talked about. Is (a) the initiator required to send a command with CmdSn of 0x3F to plug the hole? OR (b) is the target expected to recognize the hole due to login and use the new CmdSn (0x40) as it's new ExpCmdSn? OR is there a (c)? As a target implementer I'd like to think (a), but maybe I'm just being selfish. Incidentally, the initiator may try a task reassignment giving the ITT of the task with CmdSn 0x3F, to which the target would reply '01 - task does not exist.' thanks, david David J Cuddihy, Principal Engineer ATTO Technology, Inc. http://www.attotech.com/bridge.html --=_alternative 005571A285257018_= Content-Type: text/html; charset="US-ASCII"
10.12 says:

"Login Requests are always considered as immediate."

and

10.12.8 says:

"CmdSN is either the initial command sequence number of a session (for ... the "leading" login), or the command sequence number in the command stream if the login is for a new connection in an existing session."

So what happens if the last command prior to a multi-connection login was lost?  In this example: 3 connections exist between the initiator and the target.   Initiator sends CmdSn 0x3F on a connection which fails at the target.  (The TCP connection fails, for whatever reason.)  After the appropriate timeout, the initiator attempts a recovery login using CmdSN 0x40 -since it doesn't know what happened to the command with CmdSn 0x3F.  The target accepts the login, which is handled as an immediate, but responds with ExpCmdSn of 0x3F,  since that's the current session-wide ExpCmdSn.

This seems to be one of those CmdSn 'holes' which gets talked about.  

Is (a) the initiator required to send a command with CmdSn of 0x3F to plug the hole?  OR  (b) is the target expected to recognize the hole due to login and use the new CmdSn (0x40) as it's new ExpCmdSn?  OR is there a (c)?

As a target implementer I'd like to think (a), but maybe I'm just being selfish.

Incidentally, the initiator may try a task reassignment giving the ITT of the task with CmdSn 0x3F, to which the target would reply '01 - task does not exist.'

thanks,

david

David J Cuddihy, Principal Engineer
ATTO Technology, Inc.
http://www.attotech.com/bridge.html
--=_alternative 005571A285257018_=-- --===============0420597938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0420597938==-- From ips-bounces@ietf.org Mon Jun 06 11:50:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJrX-0003iF-Se; Mon, 06 Jun 2005 11:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJrW-0003ha-JR for ips@megatron.ietf.org; Mon, 06 Jun 2005 11:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12179 for ; Mon, 6 Jun 2005 11:50:00 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfKCL-00044S-MC for ips@ietf.org; Mon, 06 Jun 2005 12:11:37 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j56FntQH029669 for ; Mon, 6 Jun 2005 11:49:55 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jun 2005 11:49:48 -0400 Message-ID: To: ips@ietf.org Date: Mon, 6 Jun 2005 11:49:17 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.6.16 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Ips] WG Last Call: iSER and DA Concluded X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IPS WG Last Call on these two drafts has concluded. While the technical issues need to be addressed on this list, all of them appear to be straightforward, so there will be no need for either another WG Last Call or for discussion of these drafts in the Paris meeting (I hope to have both the DA and iSER drafts submitted to the ADs/ IESG prior to the Paris meeting). Therefore, these two drafts have completed WG Last Call. Authors should prepare updated versions of both drafts that address the technical comments (on the list), editorial comments (sent directly to authors) and comply with the ID Checklist (http://www.ietf.org/ID-Checklist.html). 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: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Black_David@emc.com Sent: Tuesday, May 10, 2005 6:17 PM To: ips@ietf.org Subject: [Ips] WG Last Call: iSER and DA Importance: High It is my pleasure to announce the IPS Working Group Last Call on the following two drafts: iSCSI Extensions for RDMA Specification [aka iSER] (draft-ietf-ips-iser-03.txt) Datamover Architecture for iSCSI (DA) (draft-ietf-ips-iwarp-da-02.txt) iSER will become a Proposed Standard vs. Informational RFC depending on whether the RDDP MPA draft becomes a Proposed Standard vs. Informational RFC; I have to go work on the latter - stay tuned. DA will become an Informational RFC. This WG Last Call will run until 11:59pm Eastern Time (US) on Friday, June 3rd. That should give anyone who puts off reviewing these drafts until after Memorial Day in the US a few days to get their review done. Technical comments need to be posted to this mailing list. Editorial comments may be sent directly to the primary draft authors: - iSER: Mike Ko - DA: Mallikarjun Chadalapaka Please copy me (as WG co-chair - David Black ) on any editorial comments, just in case something initially thought to be editorial turns out to have technical content. These drafts depend on RDDP WG drafts (all of which have completed WG Last Call) linked to the RDDP WG's web page: http://www.ietf.org/html.charters/rddp-charter.html Many thanks, --David (for David & Elizabeth IPS WG co-chairs) ---------------------------------------------------- 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 06 13:33:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLTE-0007dQ-T0; Mon, 06 Jun 2005 13:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLTD-0007dL-G6 for ips@megatron.ietf.org; Mon, 06 Jun 2005 13:33:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20252 for ; Mon, 6 Jun 2005 13:33:00 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfLo6-0006RT-NZ for ips@ietf.org; Mon, 06 Jun 2005 13:54:39 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 2C82F870A3; Mon, 6 Jun 2005 13:32:56 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <7817660a6bcf04f5af88068c4da96b5a@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] CmdSn in login request Date: Mon, 6 Jun 2005 10:32:48 -0700 To: dcuddihy@attotech.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ips@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0006541866==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0006541866== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-185531585" Content-Transfer-Encoding: 7bit --Apple-Mail-2-185531585 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Jun 6, 2005, at 8:33 AM, dcuddihy@attotech.com wrote: > 10.12 says: > > "Login Requests are always considered as immediate." > > and > > 10.12.8 says: > > "CmdSN is either the initial command sequence number of a session (for=20= > ... the "leading" login), or the command sequence number in the=20 > command stream if the login is for a new connection in an existing=20 > session." > > So what happens if the last command prior to a multi-connection login=20= > was lost? =A0In this example: 3 connections exist between the = initiator=20 > and the target. =A0 Initiator sends CmdSn 0x3F on a connection which=20= > fails at the target. =A0(The TCP connection fails, for whatever = reason.)=20 > =A0After the appropriate timeout, the initiator attempts a recovery=20 > login using CmdSN 0x40 -since it doesn't know what happened to the=20 > command with CmdSn 0x3F. =A0The target accepts the login, which is=20 > handled as an immediate, but responds with ExpCmdSn of 0x3F, =A0since=20= > that's the current session-wide ExpCmdSn. > > This seems to be one of those CmdSn 'holes' which gets talked about. Yep. > Is (a) the initiator required to send a command with CmdSn of 0x3F to=20= > plug the hole? =A0OR =A0(b) is the target expected to recognize the = hole=20 > due to login and use the new CmdSn (0x40) as it's new ExpCmdSn? =A0OR = is=20 > there a (c)? Yes, (a). It's the same thing as if a header digest were bad; the=20 initiator has to plug the hole. > As a target implementer I'd like to think (a), but maybe I'm just=20 > being selfish. > > Incidentally, the initiator may try a task reassignment giving the ITT=20= > of the task with CmdSn 0x3F, to which the target would reply '01 -=20 > task does not exist.' Actually you are not correct in the above. Assuming the CmdSN of 0x3f=20 is still in-window for the session, 10.6.1 section (b) (page 135 of RFC=20= 3720) indicates that the target can consider that CmdSN received and=20 completed. ExpCmdSN now moves on to the next value, and any delayed=20 commands (non-immediate 0x40, non-immediate 0x41, etc.) are processed. Take care. Bill= --Apple-Mail-2-185531585 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCpIjFDJT2Egh26K0RAtASAJ0T4ZlZYFAF3/G8cyn//UPBeTXAAACeKIX3 C25bopCptnbbXK0YnxbqmgI= =JpUI -----END PGP SIGNATURE----- --Apple-Mail-2-185531585-- --===============0006541866== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0006541866==-- From ips-bounces@ietf.org Tue Jun 07 14:31:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfirb-0001wu-6A; Tue, 07 Jun 2005 14:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfirY-0001vL-GW for ips@megatron.ietf.org; Tue, 07 Jun 2005 14:31:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17737 for ; Tue, 7 Jun 2005 14:31:42 -0400 (EDT) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfjCH-0001US-WF for ips@ietf.org; Tue, 07 Jun 2005 14:53:32 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel13.hp.com (Postfix) with ESMTP id C5FBA1C04497 for ; Tue, 7 Jun 2005 11:31:13 -0700 (PDT) Received: from [127.0.0.1] (unknown [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id 155658281 for ; Tue, 7 Jun 2005 11:26:30 -0700 (PDT) Message-ID: <42A5E7F1.1030005@rose.hp.com> Date: Tue, 07 Jun 2005 11:31:13 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET References: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com><427C0BAB.3080006@rose.hp.com><429CF206.8060001@rose.hp.com><001001c56780$0585d960$03031eac@ivivity.com> <429F44CB.3040500@rose.hp.com> <000301c567cf$34d0af70$03031eac@ivivity.com> In-Reply-To: <000301c567cf$34d0af70$03031eac@ivivity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org CmdSNs indicate the chronological ordering relationship of a TMF to tasks. So, it's natural that a TMF should not be able to impact tasks from the future. The specification of TMF hand-off between iSCSI and SCSI is an important spec detail not so much for the hand-off itself, but to identify the iSCSI protocol actions that must precede the hand-off - in order to maintain the single flow abstraction to SCSI. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Eddy Quicksall wrote: > Thank you. That is a very good explanation. > > Two things I have always wondered: > > 1) Is it required (via SAM-2, SPC-2, etc) that the TMF only act on > commands with lower CmdSN's? > 2) Is it necessary to state when the TMF is passed to the SCSI layer? It > would seem that that is an implementation issue and as long as the > target can emulate this behavior to the initiator then it should not be > specified in this spec. > > Eddy > > ----- Original Message ----- From: "Mallikarjun C." > To: > Sent: Thursday, June 02, 2005 1:41 PM > Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > > >> As I earlier noted in my response to Gwendal, there are three main >> goals that motivated us to spec the sequence of steps. Let me >> elaborate on those. The three are: >> >> 1. Maintaining a single ordered command flow I_T nexus abstraction to >> the target SCSI layer even with multi-connection sessions. >> Target iSCSI processing of a TMF request must maintain the >> single flow illusion - steps c & d on the target behavior >> correspond to this goal. >> >> 2. Maintaining a single ordered response flow I_T nexus abstraction to >> the initiator SCSI layer even with multi-connection sessions. >> Target must ensure that the initiator does not see "old" task >> responses (that chronologically preceded the TMF response) after >> seeing the TMF response - step e on the target behavior corresponds >> to this goal. >> >> 3. Draining all active TTTs corresponding to affected tasks before the >> TMF is acted on. >> Targets are better off if the TTTs are deterministically retired >> before the affected tasks are terminated. No need to worry about >> large-sized Data-out PDUs with stale TTTs arriving after the tasks >> are terminated - step b on the target behavior corresponds to this >> goal. >> >> >> The proposed text caters to these same goals as did the original text >> - except it now covers all TMFs that can impact multiple tasks. >> >> The only other notable thing in step (c) is the "plugging" part - it >> is just an optimization that says if all tasks on the I_T nexus will >> be aborted anyway (as with a target reset), there is no need to wait, >> the target can simply plug all missing CmdSN slots and move on with >> TMF processing. Goal #1 is still met because target SCSI layer only >> sees ordered commands. >> >> Hope that clarifies it. >> >> Mallikarjun >> >> Mallikarjun Chadalapaka >> Networked Storage Architecture >> StorageWorks Division >> Hewlett-Packard MS 5668 >> Roseville CA 95747 >> cbm [at] rose.hp.com >> >> >> Eddy Quicksall wrote: >> >>> For purposes of understanding this clearly, can you please note the >>> reason for each step? I'm not suggesting this note be added to the >>> RFC but it would be helpful for this email thread. >>> >>> Eddy >>> _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 07 14:40:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfj0C-0003PM-3C; Tue, 07 Jun 2005 14:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfj09-0003NU-Sz for ips@megatron.ietf.org; Tue, 07 Jun 2005 14:40:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20124 for ; Tue, 7 Jun 2005 14:40:36 -0400 (EDT) Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfjKv-0001pc-D4 for ips@ietf.org; Tue, 07 Jun 2005 15:02:26 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id B2D7C10F6B; Tue, 7 Jun 2005 14:40:15 -0400 (EDT) Received: from [127.0.0.1] (unknown [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id C319C81DB; Tue, 7 Jun 2005 11:35:31 -0700 (PDT) Message-ID: <42A5EA0E.6070805@rose.hp.com> Date: Tue, 07 Jun 2005 11:40:14 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org David, >What I would suggest is that we start an Internet-Draft > that is intended to become an Implementers Guide RFC (standards track) I am fine with your suggestion. Is there a standard way to make a formal linkage between RFC 3720 and this new draft, e.g. as in "when you implement RFC 3720, you must/should implement the contents of draft foo because foo fills in some intended but unspecified semantics of RFC 3720" >would you be interested in editing > an implementers guide Internet Draft? Yes, I can be talked into doing that.... I assume it has to be submitted as an individual submission to begin with? Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Black_David@emc.com wrote: > Mallikarjun, > > >>I am concerned that the current lack of detailed specification would >>allow targets that might even cause silent data corruptions >>to qualify as RFC 3720-compliant. >> >>Here are what I believe to be semantics applicable to all TMF requests >>that can potentially terminate multiple tasks. I do not know the IETF >>process well enough here, but I suggest that we consider this text >>replacing the existing section 10.6.2 in RFC 3720 - so the new text can >>cover all the TMFs that can impact multiple tasks. This is basically a >>superset of the current 10.6.2 semantics. > > > IETF does have an errata process, but (IMHO) it's not a great venue > for something like this that it's important for implementers to pay > attention to. What I would suggest is that we start an Internet-Draft > that is intended to become an Implementers Guide RFC (standards track) > to include both technical corrections like this one, and explanations > of subtle points such as how to deal with (what appear to be) REPORT > LUNS overruns as discussed here earlier. An available example is that > an implementers guide draft is being maintained for SCTP (see > draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that > an iSCSI implementers guide won't grow to that size. > > For this task management issue, explaining what the problem is and why > the change fixes it in an implementers guide is at least as important as > specifying the change. For the REPORT LUNS overruns, the implementers > guide text would be an explanation of why no change is needed, including > some elaboration on the (less than completely obvious) SPC-2 text that > specifies the behavior of REPORT LUNS in this circumstance. Before I > go looking for another volunteer, would you be interested in editing > an implementers guide Internet Draft? Between Julian and I, we should > be able write the REPORT LUNS explanation paragraph or two. > > 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 > ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 07 15:16:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjZH-0001UV-M3; Tue, 07 Jun 2005 15:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjZF-0001U3-Oe for ips@megatron.ietf.org; Tue, 07 Jun 2005 15:16:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24168 for ; Tue, 7 Jun 2005 15:16:51 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfju2-0002fW-Dh for ips@ietf.org; Tue, 07 Jun 2005 15:38:42 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id BD290255E; Tue, 7 Jun 2005 12:16:31 -0700 (PDT) Received: from [127.0.0.1] (unknown [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id DC99D81E0; Tue, 7 Jun 2005 12:11:47 -0700 (PDT) Message-ID: <42A5F28E.8010401@rose.hp.com> Date: Tue, 07 Jun 2005 12:16:30 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] WG Last Call Review: DA References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org David, Thanks for the review. In clear hindsight, I think not referencing RFC 3723 in this section is a mistake. I will put that in. > - Control/Data separation. The mechanisms for transmission > of iSCSI control vs. data are deliberately split by > DA, and there is no requirement that they even use > the same transport medium. RFC 3720 defines several MUST requirements on ordering relationships across control & data for a given task besides a mandatory deterministic task allegiance model - DA is not changing any of that (DA has a normative reference on RFC 3720), nor allowing any additional flexibility in compliance here. Sending bulk data transfers (prompted by Put/Get_Data Primitives) on a different transport medium would be as ill-advised as sending just the iSCSI-3720 Data-out/Data-in PDUs on a different TCP connection in traditional iSCSI implementations. >DA introduces > explicit management of resources at the DI interface, > including data buffers and Datamover connection resources. > The latter in particular is likely to be a limited class > of resource in some anticipated implementations. By "Datamover connection resources", I assume you mean the logical equivalent of posted receive buffers. The potential for DoS attack, IMHO, is qualitatively not different from the iSCSI-3720 case, and so appealing to RFC 3723 should address this basic concern. Would you agree? Another option is to informationally reference the RDDP security draft to direct the reader's attention to suitable remedies for the case of RDDP-based Datamovers. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Black_David@emc.com wrote: > I have reviewed the DA draft, draft-ietf-ips-iwarp-da-02.txt, > and in addition to a number of editorial comments that I will > send to Mallikarjun, I have one important technical comment - > > The Security Considerations section essentially says "there > are no new security considerations because DA does not define > a wire protocol." That is not correct because DA introduces > at least two architectural concepts to iSCSI that do have > security implications: > - Control/Data separation. The mechanisms for transmission > of iSCSI control vs. data are deliberately split by > DA, and there is no requirement that they even use > the same transport medium. This introduces new > opportunities for an attacker to fiddle with things, > and may place additional security responsibility on > an iSCSI-DA implementation over and above an iSCSI > implementation. > - Explicit resource management/control. DA introduces > explicit management of resources at the DI interface, > including data buffers and Datamover connection resources. > The latter in particular is likely to be a limited class > of resource in some anticipated implementations. Some > discussion is needed on the possibility of a denial-of- > service attack via resource exhaustion and the functional > responsibility of an iSCSI-DA implementation to defend > against this. > A new Security Considerations section will be needed to address > at least these areas. > > 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 > ---------------------------------------------------- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 07 15:54:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfk9J-00088K-2c; Tue, 07 Jun 2005 15:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfk9H-00088F-FY for ips@megatron.ietf.org; Tue, 07 Jun 2005 15:54:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27301 for ; Tue, 7 Jun 2005 15:54:05 -0400 (EDT) Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfkU2-0003cn-Lg for ips@ietf.org; Tue, 07 Jun 2005 16:15:57 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id 2DB9C25CF for ; Tue, 7 Jun 2005 15:53:44 -0400 (EDT) Received: from [127.0.0.1] (unknown [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id 0B95B81DD for ; Tue, 7 Jun 2005 12:49:00 -0700 (PDT) Message-ID: <42A5FB47.7050703@rose.hp.com> Date: Tue, 07 Jun 2005 12:53:43 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] CmdSn in login request References: <7817660a6bcf04f5af88068c4da96b5a@wasabisystems.com> In-Reply-To: <7817660a6bcf04f5af88068c4da96b5a@wasabisystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >> Is (a) the initiator required to send a command with CmdSn of 0x3F to >> plug the hole? As Bill said, (a) is correct - the hole should eventually be plugged due to initiator action (but not necessarily with a new command, an abort task will do just as well). >> Incidentally, the initiator may try a task reassignment giving the ITT >> of the task with CmdSn 0x3F, to which the target would reply '01 - >> task does not exist.' Yes for the task reassignment TMF (although if the initiator was told that the ExpCmdSN is 0x3f, it really shouldn't issue one). I think Bill was assuming abort task in his response. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > On Jun 6, 2005, at 8:33 AM, dcuddihy@attotech.com wrote: > >> 10.12 says: >> >> "Login Requests are always considered as immediate." >> >> and >> >> 10.12.8 says: >> >> "CmdSN is either the initial command sequence number of a session (for >> ... the "leading" login), or the command sequence number in the >> command stream if the login is for a new connection in an existing >> session." >> >> So what happens if the last command prior to a multi-connection login >> was lost? In this example: 3 connections exist between the initiator >> and the target. Initiator sends CmdSn 0x3F on a connection which >> fails at the target. (The TCP connection fails, for whatever reason.) >> After the appropriate timeout, the initiator attempts a recovery >> login using CmdSN 0x40 -since it doesn't know what happened to the >> command with CmdSn 0x3F. The target accepts the login, which is >> handled as an immediate, but responds with ExpCmdSn of 0x3F, since >> that's the current session-wide ExpCmdSn. >> >> This seems to be one of those CmdSn 'holes' which gets talked about. > > > Yep. > >> Is (a) the initiator required to send a command with CmdSn of 0x3F to >> plug the hole? OR (b) is the target expected to recognize the hole >> due to login and use the new CmdSn (0x40) as it's new ExpCmdSn? OR is >> there a (c)? > > > Yes, (a). It's the same thing as if a header digest were bad; the > initiator has to plug the hole. > >> As a target implementer I'd like to think (a), but maybe I'm just >> being selfish. >> >> Incidentally, the initiator may try a task reassignment giving the ITT >> of the task with CmdSn 0x3F, to which the target would reply '01 - >> task does not exist.' > > > Actually you are not correct in the above. Assuming the CmdSN of 0x3f is > still in-window for the session, 10.6.1 section (b) (page 135 of RFC > 3720) indicates that the target can consider that CmdSN received and > completed. ExpCmdSN now moves on to the next value, and any delayed > commands (non-immediate 0x40, non-immediate 0x41, etc.) are processed. > > Take care. > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 07 17:36:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DflkY-0006DI-4I; Tue, 07 Jun 2005 17:36:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DflkU-0006D5-6r for ips@megatron.ietf.org; Tue, 07 Jun 2005 17:36:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15624 for ; Tue, 7 Jun 2005 17:36:35 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfm5b-0001Ko-Aa for ips@ietf.org; Tue, 07 Jun 2005 17:58:28 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j57LaMGo016773; Tue, 7 Jun 2005 17:36:23 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jun 2005 17:36:22 -0400 Message-ID: To: cbm@rose.hp.com Subject: RE: [Ips] WG Last Call Review: DA Date: Tue, 7 Jun 2005 17:36:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.7.26 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, > Thanks for the review. > > In clear hindsight, I think not referencing RFC 3723 in this > section is a mistake. I will put that in. > > > - Control/Data separation. The mechanisms for transmission > > of iSCSI control vs. data are deliberately split by > > DA, and there is no requirement that they even use > > the same transport medium. > > RFC 3720 defines several MUST requirements on ordering relationships > across control & data for a given task besides a mandatory deterministic > task allegiance model - DA is not changing any of that (DA has a > normative reference on RFC 3720), nor allowing any additional > flexibility in compliance here. > > Sending bulk data transfers (prompted by Put/Get_Data Primitives) on a > different transport medium would be as ill-advised as sending just the > iSCSI-3720 Data-out/Data-in PDUs on a different TCP connection in > traditional iSCSI implementations. Both of the above paragraphs are probably good content to add to the DA draft. If memory serves, the people working on iSER for InfiniBand are doing more separation of control/data transfers than realized via iSER/RDDP. The point I'm looking to convey here is that the control/ data separation in DA may provide an attacker more leverage by making it easier to isolate/view/modify one without getting involved in the other. Any use of DA will need to address this in some fashion. > >DA introduces > > explicit management of resources at the DI interface, > > including data buffers and Datamover connection resources. > > The latter in particular is likely to be a limited class > > of resource in some anticipated implementations. > > By "Datamover connection resources", I assume you mean the logical > equivalent of posted receive buffers. The potential for DoS attack, > IMHO, is qualitatively not different from the iSCSI-3720 case, and so > appealing to RFC 3723 should address this basic concern. > Would you agree? For resources that already exist in iSCSI in the absence of DA/iSER and are managed in the same way, RFC 3723 should be fine. What's bothering me is the Allocate_Connection_Resources primitive which is intended to deal with resources that either don't exist, or aren't managed in the same pre-allocation fashion in traditional/vanilla iSCSI ... > Another option is to informationally reference the RDDP security draft > to direct the reader's attention to suitable remedies for the case of > RDDP-based Datamovers. How about referencing that draft as an example *and* generalizing to non-RDDP Datamovers, using that draft as an example of the analysis of resource exhaustion and application of countermeasures that needs to be done? Thanks, --David > Thanks. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Black_David@emc.com wrote: > > I have reviewed the DA draft, draft-ietf-ips-iwarp-da-02.txt, > > and in addition to a number of editorial comments that I will > > send to Mallikarjun, I have one important technical comment - > > > > The Security Considerations section essentially says "there > > are no new security considerations because DA does not define > > a wire protocol." That is not correct because DA introduces > > at least two architectural concepts to iSCSI that do have > > security implications: > > - Control/Data separation. The mechanisms for transmission > > of iSCSI control vs. data are deliberately split by > > DA, and there is no requirement that they even use > > the same transport medium. This introduces new > > opportunities for an attacker to fiddle with things, > > and may place additional security responsibility on > > an iSCSI-DA implementation over and above an iSCSI > > implementation. > > - Explicit resource management/control. DA introduces > > explicit management of resources at the DI interface, > > including data buffers and Datamover connection resources. > > The latter in particular is likely to be a limited class > > of resource in some anticipated implementations. Some > > discussion is needed on the possibility of a denial-of- > > service attack via resource exhaustion and the functional > > responsibility of an iSCSI-DA implementation to defend > > against this. > > A new Security Considerations section will be needed to address > > at least these areas. > > > > 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 > > ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 07 17:50:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DflxX-0001MS-L4; Tue, 07 Jun 2005 17:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DflxV-0001MH-HE for ips@megatron.ietf.org; Tue, 07 Jun 2005 17:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16448 for ; Tue, 7 Jun 2005 17:50:02 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfmId-0001b4-LO for ips@ietf.org; Tue, 07 Jun 2005 18:11:56 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j57Lo2ED014598; Tue, 7 Jun 2005 17:50:02 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jun 2005 17:50:01 -0400 Message-ID: To: cbm@rose.hp.com Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET Date: Tue, 7 Jun 2005 17:50:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.7.27 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, > Is there a standard way to make a > formal linkage between RFC 3720 and this new draft, e.g. as in "when you > implement RFC 3720, you must/should implement the contents of draft foo > because foo fills in some intended but unspecified semantics of RFC 3720" Yes, the draft will be an active IPS WG draft that says on its first page that it "Updates" RFC 3720, and that "Updates" statement will be on it when it (eventually) gets published as an RFC. > Yes, I can be talked into doing that.... Many thanks ... I'll make sure you get useful text on the REPORT LUNS issue. > I assume it has to be submitted as an individual submission to begin > with? Yes, temporarily - I need to go get AD approval for this to be an official WG draft (and will start that process now ...). Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 07, 2005 2:40 PM > To: Black_David@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > > David, > > >What I would suggest is that we start an Internet-Draft > > that is intended to become an Implementers Guide RFC > (standards track) > > I am fine with your suggestion. Is there a standard way to make a > formal linkage between RFC 3720 and this new draft, e.g. as in "when you > implement RFC 3720, you must/should implement the contents of draft foo > because foo fills in some intended but unspecified semantics of RFC 3720" > > >would you be interested in editing > > an implementers guide Internet Draft? > > Yes, I can be talked into doing that.... I assume it has to be > submitted as an individual submission to begin with? > > Thanks. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Black_David@emc.com wrote: > > Mallikarjun, > > > > > >>I am concerned that the current lack of detailed specification would > >>allow targets that might even cause silent data corruptions > >>to qualify as RFC 3720-compliant. > >> > >>Here are what I believe to be semantics applicable to all > TMF requests > >>that can potentially terminate multiple tasks. I do not > know the IETF > >>process well enough here, but I suggest that we consider this text > >>replacing the existing section 10.6.2 in RFC 3720 - so the > new text can > >>cover all the TMFs that can impact multiple tasks. This is > basically a > >>superset of the current 10.6.2 semantics. > > > > > > IETF does have an errata process, but (IMHO) it's not a great venue > > for something like this that it's important for implementers to pay > > attention to. What I would suggest is that we start an > Internet-Draft > > that is intended to become an Implementers Guide RFC > (standards track) > > to include both technical corrections like this one, and > explanations > > of subtle points such as how to deal with (what appear to be) REPORT > > LUNS overruns as discussed here earlier. An available > example is that > > an implementers guide draft is being maintained for SCTP (see > > draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to > believe that > > an iSCSI implementers guide won't grow to that size. > > > > For this task management issue, explaining what the problem > is and why > > the change fixes it in an implementers guide is at least as > important as > > specifying the change. For the REPORT LUNS overruns, the > implementers > > guide text would be an explanation of why no change is > needed, including > > some elaboration on the (less than completely obvious) > SPC-2 text that > > specifies the behavior of REPORT LUNS in this circumstance. > Before I > > go looking for another volunteer, would you be interested in editing > > an implementers guide Internet Draft? Between Julian and > I, we should > > be able write the REPORT LUNS explanation paragraph or two. > > > > 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 > > ---------------------------------------------------- > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 07 19:38:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfneX-0007JO-1k; Tue, 07 Jun 2005 19:38:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfneV-0007JA-Ly for ips@megatron.ietf.org; Tue, 07 Jun 2005 19:38:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26141 for ; Tue, 7 Jun 2005 19:38:31 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfnzb-0003sN-5p for ips@ietf.org; Tue, 07 Jun 2005 20:00:24 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mononoke.wasabisystems.com (Postfix) with ESMTP id B256D8709E; Tue, 7 Jun 2005 19:38:18 -0400 (EDT) In-Reply-To: <42A5FB47.7050703@rose.hp.com> References: <7817660a6bcf04f5af88068c4da96b5a@wasabisystems.com> <42A5FB47.7050703@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <3fa20f60b7b36478ed5f49ecace45e3d@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] CmdSn in login request Date: Tue, 7 Jun 2005 16:38:09 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1104942210==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1104942210== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-293852324" Content-Transfer-Encoding: 7bit --Apple-Mail-2-293852324 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jun 7, 2005, at 12:53 PM, Mallikarjun C. wrote: > >> Incidentally, the initiator may try a task reassignment giving the > ITT > >> of the task with CmdSn 0x3F, to which the target would reply '01 - > >> task does not exist.' > > Yes for the task reassignment TMF (although if the initiator was told > that the ExpCmdSN is 0x3f, it really shouldn't issue one). I think > Bill was assuming abort task in his response. Yes, sorry about that. If it is a reassignment, then it should give the "task does not exist" response. Take care, Bill --Apple-Mail-2-293852324 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCpi/oDJT2Egh26K0RAlTNAKCajozWliXsULaVSSzyJwRbNoPMwwCfcAap SzTE0SSRy1u4zwDfY2OwJAg= =+W7K -----END PGP SIGNATURE----- --Apple-Mail-2-293852324-- --===============1104942210== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1104942210==-- From ips-bounces@ietf.org Tue Jun 07 21:17:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfpC6-0002mt-B9; Tue, 07 Jun 2005 21:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfpC4-0002mj-Jl for ips@megatron.ietf.org; Tue, 07 Jun 2005 21:17:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04895 for ; Tue, 7 Jun 2005 21:17:18 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfpXE-0005sr-Jf for ips@ietf.org; Tue, 07 Jun 2005 21:39:12 -0400 Received: from ivvt2dxrc11 (adsl-217-114-229.asm.bellsouth.net[68.217.114.229]) by comcast.net (sccrmhc13) with SMTP id <2005060801171001600d9ifge>; Wed, 8 Jun 2005 01:17:10 +0000 Message-ID: <000a01c56bc7$cb78c240$6e00470a@ivivity.com> From: "Eddy Quicksall" To: , , References: <000301c5685b$a1aeb060$03031eac@ivivity.com> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Tue, 7 Jun 2005 21:17:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org What do you think about this? I don't remember seeing an answer. Eddy ----- Original Message ----- From: "Eddy Quicksall" To: ; ; Sent: Friday, June 03, 2005 12:45 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > If you are going to write this guide, I would like to suggest that a > paragraph be added saying something like "the initiator and target are not > expected to catch all protocol errors introduced by the other party and it > is the implementers option as to which errors may be caught due to > internal dynamics, crash dynamics or data corruption". > > Eddy > > ----- Original Message ----- > From: > To: ; > Sent: Friday, June 03, 2005 8:51 AM > Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET > > >> Mallikarjun, >> >>> I am concerned that the current lack of detailed specification would >>> allow targets that might even cause silent data corruptions >>> to qualify as RFC 3720-compliant. >>> >>> Here are what I believe to be semantics applicable to all TMF requests >>> that can potentially terminate multiple tasks. I do not know the IETF >>> process well enough here, but I suggest that we consider this text >>> replacing the existing section 10.6.2 in RFC 3720 - so the new text can >>> cover all the TMFs that can impact multiple tasks. This is basically a >>> superset of the current 10.6.2 semantics. >> >> IETF does have an errata process, but (IMHO) it's not a great venue >> for something like this that it's important for implementers to pay >> attention to. What I would suggest is that we start an Internet-Draft >> that is intended to become an Implementers Guide RFC (standards track) >> to include both technical corrections like this one, and explanations >> of subtle points such as how to deal with (what appear to be) REPORT >> LUNS overruns as discussed here earlier. An available example is that >> an implementers guide draft is being maintained for SCTP (see >> draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that >> an iSCSI implementers guide won't grow to that size. >> >> For this task management issue, explaining what the problem is and why >> the change fixes it in an implementers guide is at least as important as >> specifying the change. For the REPORT LUNS overruns, the implementers >> guide text would be an explanation of why no change is needed, including >> some elaboration on the (less than completely obvious) SPC-2 text that >> specifies the behavior of REPORT LUNS in this circumstance. Before I >> go looking for another volunteer, would you be interested in editing >> an implementers guide Internet Draft? Between Julian and I, we should >> be able write the REPORT LUNS explanation paragraph or two. >> >> 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 >> ---------------------------------------------------- >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jun 08 02:23:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dftyk-0004PS-Ej; Wed, 08 Jun 2005 02:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dftyh-0004PK-9k; Wed, 08 Jun 2005 02:23:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20077; Wed, 8 Jun 2005 02:23:47 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfuJq-0003YI-6L; Wed, 08 Jun 2005 02:45:44 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j586NVew156484; Wed, 8 Jun 2005 06:23:31 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j586NVLe186930; Wed, 8 Jun 2005 08:23:31 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j586NVRj015769; Wed, 8 Jun 2005 08:23:31 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j586NUAb015760; Wed, 8 Jun 2005 08:23:30 +0200 In-Reply-To: <000401c569e3$54ab43d0$03031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] DataACK SNACK immediatly MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05032005NP May 03, 2005 From: Julian Satran Message-ID: Date: Wed, 8 Jun 2005 09:23:29 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 08/06/2005 09:23:30, Serialize complete at 08/06/2005 09:23:30 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: ips@ietf.org, William Studenmund , ips-bounces@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0770260173==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0770260173== Content-Type: text/html; charset="US-ASCII"
Yes as long as it does not "skip" both acking and snacking a response (or data with status).
And even if it does a wise target writer may want to "liberal" about it (if it has enough resources to withstand it).

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

05/06/2005 18:29

To
Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org, William Studenmund <wrstuden@wasabisystems.com>, ips-bounces@ietf.org, "Mallikarjun C." <cbm@rose.hp.com>
Subject
Re: [Ips] DataACK SNACK immediatly





Thank you very much.
 
Can I assume your answer would be the same if the initiator sends/receives the PDU's in the same time sequence that the target sends/receives the PDU's (i.e. with all frames running in numerical order).
 
Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: Mallikarjun C. ; ips@ietf.org ; ips-bounces@ietf.org ; William Studenmund
Sent: Sunday, June 05, 2005 5:33 AM
Subject: Re: [Ips] DataACK SNACK immediatly


Eddy,

IMHO the initiator has not committed an error since it has acked the status. Queue depth is also not relevant as long as the initiator obeyed the MaxCmdSN as a target may change the queue depth at it's convenience.

However the following initiator sequence woud have been a protocol error.

45 I->T Data SNACK                            4             F5  1,1
46 I->T Read          127                     6 (or 5)      F6
_______________________________________________

provided that they came on the same connection (as your example seem to indicate).
The rule is there to prevent an initiator from deliberately holding up resources at the target and is based on the assumption that an initiator does not gain anything by processing PDUs out of order (admittedly this is no always true).

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

04/06/2005 19:02


To
<ips@ietf.org>, "William Studenmund" <wrstuden@wasabisystems.com>, "Mallikarjun C." <cbm@rose.hp.com>
cc
Subject
[Ips] DataACK SNACK immediatly







10.7.2 says "...the initiator MUST issue a SNACK of type DataACK except when it is able to acknowledge the status for the task immediately via ExpStatSN on other outbound PDUs ..."
 
Refering to the below transmission,
1) Has the initiator committed a protocol error by not sending the DataACK SNACK immeditaly after frame 39? Note that the time between 39 and 41 is extreemly small.
2) If so, MUST the target detect the protocol error and send a reject after receiving frame 45?
3) What if the queue depth is only 1, does that change your answer?
 
>From Targets perspective:
 
ln dir  cmd      S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT Run
-- ---  ---      - - ----- -------- ------ --------- ------ --- ---
38 I->T Read Cap      125                     4             F4
39 T->I Data In  S A         126      4                 0
40 I->T Read          126                     4             F5
41 T->I Data In              127      0                 0
42 T->I Data In              127      0                 1
44 T->I Data In  S A         127      5                 2
45 I->T Data SNACK                            5             F5  1,1
 
>From Initiators perspective:
 
ln dir  cmd      S A CmdSN ExpCmdSN StatSN ExpStatSN DataSN ITT Run
-- ---  ---      - - ----- -------- ------ --------- ------ --- ---
38 I->T Read Cap      125                     4             F4
40 I->T Read          126                     4             F5
39 T->I Data In  S A         126      4                 0
41 T->I Data In              127      0                 0
42 T->I Data In              127      0                 1
44 T->I Data In  S A         127      5                 2
45 I->T Data SNACK                            5             F5  1,1
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--===============0770260173== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0770260173==-- From ips-bounces@ietf.org Wed Jun 08 22:16:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgCaz-0007mJ-Ju; Wed, 08 Jun 2005 22:16:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgCaw-0007mE-7Z for ips@megatron.ietf.org; Wed, 08 Jun 2005 22:16:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23793 for ; Wed, 8 Jun 2005 22:16:29 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgCvn-0008FM-7C for ips@ietf.org; Wed, 08 Jun 2005 22:38:07 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 5DD19106D; Wed, 8 Jun 2005 19:15:45 -0700 (PDT) Received: from [127.0.0.1] (palnai12-456.corp.hp.com [15.244.193.200]) by rosemail.rose.hp.com (Postfix) with ESMTP id 8FD727FF1; Wed, 8 Jun 2005 19:10:55 -0700 (PDT) Message-ID: <42A7A650.6000504@rose.hp.com> Date: Wed, 08 Jun 2005 19:15:44 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] WG Last Call Review: DA References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org David, Here is the security re-write for the next rev of DA. Please=20 review/comment. Note the new MUST requirement around iSCSI SecurityNegotiation stage wrt=20 resource allocation. I do not believe it requires any changes to the=20 iSER draft, but other co-authors may want to check me on that. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com 12 Security Considerations 12.1 Architectural Considerations DA enables compliant iSCSI implementations to realize a control and data=20 separation in the way they interact with their Datamover protocols.=20 Note however that this separation does not imply a separation in=20 transport mediums between control traffic and data traffic - basic iSCSI=20 architecture with respect to tasks and PDU relationships to tasks=20 remains unchanged. [RFC3720] defines several MUST requirements on=20 ordering relationships across control and data for a given task besides=20 a mandatory deterministic task allegiance model - DA does not change=20 this basic architecture (DA has a normative reference on [RFC3720]) nor=20 allow any additional flexibility in compliance in this area. To=20 summarize, sending bulk data transfers (prompted by Put_Data and=20 Get_Data Primitive invocations) on a different transport medium would be=20 as ill-advised as sending just the Data-out/Data-in PDUs on a different=20 TCP connection in RFC 3720-based iSCSI implementations. Consequently,=20 all the iSCSI-related security text in [RFC3723] is directly applicable=20 to a DA-enabled iSCSI implementation. Another area with security implications is the Datamover connection=20 resource management model which DA defines =96 particularly the=20 Allocate_Connection_Resources Primitive. An inadvertent realization of=20 this model could leave an iSCSI implementation exposed to denial of=20 service attacks. As Figure 2 and Figure 3 in section 17.2 illustrate,=20 the most effective countermeasure to this potential attack consists of=20 performing the Datamover resource allocation when the iSCSI layer is=20 sufficiently far along in the iSCSI Login Phase that it is reasonably=20 certain that the peer side is not an attacker. In particular, if the=20 Login Phase includes a SecurityNegotiation stage, an iSCSI end node MUST=20 defer the Datamover connection resource allocation (i.e. invoking the=20 Allocate_Connection_Resources Primitive) to the=20 LoginOperationalNegotiation stage ([RFC3720]) so that the resource=20 allocation happens post-authentication. This considerably minimizes the=20 potential for a denial of service attack. 12.2 Wire Protocol Considerations In view of the fact that the DA architecture itself does not define any=20 new wire protocol nor propose modifications to the existing protocols,=20 there are no additional wire protocol security considerations in=20 employing DA itself. However, a DA-compliant iSCSI implementation MUST=20 comply with all the iSCSI-related requirements stipulated in [RFC3723]=20 and [RFC3720]. Note further that in realizing DA, each Datamover=20 protocol must define and elaborate as appropriate on any additional=20 security considerations resulting from the use of that Datamover protocol= . All Datamover protocol designers are strongly recommended to refer to=20 [RDDPSEC] for the types of security issues to consider. While [RDDPSEC]=20 elaborates on the security considerations applicable to an RDDP-based=20 Datamover ([iSER]), the document is representative of the type of=20 analysis of resource exhaustion and the application of countermeasures=20 that needs to be done for any Datamover protocol. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jun 10 14:00:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgnoP-0005Hu-8H; Fri, 10 Jun 2005 14:00:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgnoN-0005Hp-Fc for ips@megatron.ietf.org; Fri, 10 Jun 2005 14:00:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15474 for ; Fri, 10 Jun 2005 14:00:53 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgo9l-0007fk-2i for ips@ietf.org; Fri, 10 Jun 2005 14:23:21 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 763D513D9 for ; Fri, 10 Jun 2005 11:00:33 -0700 (PDT) Received: from [127.0.0.1] (unknown [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id B7CB581CC for ; Fri, 10 Jun 2005 10:55:36 -0700 (PDT) Message-ID: <42A9D53E.8010002@rose.hp.com> Date: Fri, 10 Jun 2005 11:00:30 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET References: <000301c5685b$a1aeb060$03031eac@ivivity.com> <000a01c56bc7$cb78c240$6e00470a@ivivity.com> In-Reply-To: <000a01c56bc7$cb78c240$6e00470a@ivivity.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org My comment on this is that such a blanket statement will be a problem. RFC 3720 has a defined notion of protocol errors and their handling, and uses a fair number of MUSTs (sometimes conditional) on Rejects (as PDUs and in negotiation) - e.g., if you support data digests, you must discard a bad digest PDU with a Reject. These actions inherently require protocol validation and catching errors. I don't think we want to weaken any of that. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Eddy Quicksall wrote: > What do you think about this? I don't remember seeing an answer. > > Eddy > > ----- Original Message ----- From: "Eddy Quicksall" > > To: ; ; > Sent: Friday, June 03, 2005 12:45 PM > Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > > >> If you are going to write this guide, I would like to suggest that a >> paragraph be added saying something like "the initiator and target are >> not expected to catch all protocol errors introduced by the other >> party and it is the implementers option as to which errors may be >> caught due to internal dynamics, crash dynamics or data corruption". >> >> Eddy >> >> ----- Original Message ----- From: >> To: ; >> Sent: Friday, June 03, 2005 8:51 AM >> Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET >> >> >>> Mallikarjun, >>> >>>> I am concerned that the current lack of detailed specification would >>>> allow targets that might even cause silent data corruptions >>>> to qualify as RFC 3720-compliant. >>>> >>>> Here are what I believe to be semantics applicable to all TMF requests >>>> that can potentially terminate multiple tasks. I do not know the IETF >>>> process well enough here, but I suggest that we consider this text >>>> replacing the existing section 10.6.2 in RFC 3720 - so the new text can >>>> cover all the TMFs that can impact multiple tasks. This is basically a >>>> superset of the current 10.6.2 semantics. >>> >>> >>> IETF does have an errata process, but (IMHO) it's not a great venue >>> for something like this that it's important for implementers to pay >>> attention to. What I would suggest is that we start an Internet-Draft >>> that is intended to become an Implementers Guide RFC (standards track) >>> to include both technical corrections like this one, and explanations >>> of subtle points such as how to deal with (what appear to be) REPORT >>> LUNS overruns as discussed here earlier. An available example is that >>> an implementers guide draft is being maintained for SCTP (see >>> draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that >>> an iSCSI implementers guide won't grow to that size. >>> >>> For this task management issue, explaining what the problem is and why >>> the change fixes it in an implementers guide is at least as important as >>> specifying the change. For the REPORT LUNS overruns, the implementers >>> guide text would be an explanation of why no change is needed, including >>> some elaboration on the (less than completely obvious) SPC-2 text that >>> specifies the behavior of REPORT LUNS in this circumstance. Before I >>> go looking for another volunteer, would you be interested in editing >>> an implementers guide Internet Draft? Between Julian and I, we should >>> be able write the REPORT LUNS explanation paragraph or two. >>> >>> 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 >>> ---------------------------------------------------- >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >> >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 01:10:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhhDI-0002fb-Ec; Mon, 13 Jun 2005 01:10:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhhDF-0002ee-66 for ips@megatron.ietf.org; Mon, 13 Jun 2005 01:10:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14290 for ; Mon, 13 Jun 2005 01:10:16 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhhZP-00082M-8D for ips@ietf.org; Mon, 13 Jun 2005 01:33:14 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5D59xYj023260 for ; Mon, 13 Jun 2005 01:09:59 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5D59x4P238542 for ; Mon, 13 Jun 2005 01:09:59 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5D59xch001916 for ; Mon, 13 Jun 2005 01:09:59 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5D59xsH001906 for ; Mon, 13 Jun 2005 01:09:59 -0400 In-Reply-To: Importance: Normal Subject: Re: [Ips] WG Last Call Review: iSER To: Black_David@emc.com X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Sun, 12 Jun 2005 22:09:56 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_04122005|April 12, 2005) at 06/13/2005 01:09:58 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org David, Thanks for the review. Please see my comments inline. Mike Black_David@emc.com@ietf.org on 06/03/2005 06:31:21 PM Sent by: ips-bounces@ietf.org To: ips@ietf.org cc: Subject: [Ips] WG Last Call Review: iSER I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, and in addition to editorial issues that I will send directly to Mike, I found a number of technical issues: (1) Section 3.3 has a structural problem in that the first sentence says "should satisfy" and the remaining sentences to be satisfied are expressed as "MUST" requirements. The net result is that all the requirements in that section are "should" requirements, which is not what was intended. The first sentence needs to be rewritten to say something to the effect of "In order to use iSER, the following MUST be done:" . [mk] ok (2) Section 3.3, item 1. says "MUST negotiate the RDMAExtensions key to "Yes" " Since the key is negotiated (not declared) and it takes two to negotiate, that requirement cannot be achieved by an implementation if the other side doesn't cooperate. This needs to be rewritten to talk about offering the key as "Yes" and replying as "Yes" and that if the result is not "Yes" then iSER is not used (traditional iSCSI is used instead). [mk] ok (3) Section 3.3., item 5. says "MUST successfully negotiate the TargetRecvDataSegmentLength key". Again there's a "takes two to negotiate" problem, and the "failed to successfully negotiate" case needs to be specified. [mk] The old items 4 and 5 are now replaced by the new item 4 with the follwowing text: "The iSCSI Layers at both the initiator and the target MUST support the keys as defined in section 6 on Login/Text Operational Keys. If used as specified, these keys MUST NOT be answered with NotUnderstood and the semantics as defined MUST be followed for each iSER-assisted connection." (4) Section 5.1, last two paragraphs have similar problems in that they specify required negotiation behavior without describing what to do when the other side doesn't cooperate or do what it is supposed to. Those failure cases need to be covered. [mk] The new text for comment #3 should address this issue. (5) Section 5.1.2, in the Note at the very end of the section about two steps needing to be atomic, "must" should be "MUST". [mk] ok (6) Section 5.1.3 is missing specification and explanation of version negotiation and version numbers in the iSER Hello Exchange. The error case instructions for when version negotiation fails need to be copied here in addition to their current location in Section 10.1.3.2 . [mk] ok (7) Section 7.3.9 - I believe sending of Login Request or Login Response in Datamover mode is always an error. This section should say so and say what to do about it. [mk] ok (8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling does not work because the instruction in 10.2.1 to handle SNACK as per RFC 3720 would require retransmission of non-existent Data and R2T PDUs. I can see a couple of possible corrective approaches: a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK PDUs (instead of the current SHOULD NOT) and change Section 10.2.1 to define reception of any SNACK PDU as an error. b) Put limits on what SNACK PDUs can be used to recover (Status only?) in Section 7.3.11, and modify Section 10.2.1 to say how to recover that and what to do when a prohibited SNACK is received. [mk] The updated iSER draft will follow the suggestion in 8a. Also updated text in section 3.3 and section 8.3 on SNACK handling. (9) Section 8.1 uses the phrase "buffer underrun" for an "out of buffers" condition. That should be "buffer exhaustion". [mk] ok (10) Section 8.4 could result in a situation where an iSER Target cannot send a Reject PDU that an iSCSI Target would be able send. It needs to explain what to do in that situation. [mk] The following text has been added in section 8.4: (Implementation note: If the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will not be able to send another unexpected control-type PDU until some outstanding ones have been retired. To ensure that the initiator has a means of retiring outstanding PDUs, the target should reserve the last unexpected control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the initiator to return the NOP-out ping response with the current ExpStatSN.) (11) Section 11 on Security Considerations is weak, but the overall approach of appealing to security considerations in other specifications is probably ok. This section needs to be strengthened by saying that since iSER is still functionally iSCSI, all of the iSCSI security considerations in RFC 3720 apply, and it should also reference the discussion of iSCSI security in RFC 3723. [mk] This section now references RFC3723 and the security drafts for RDDP. Both documents have also been added to the list of references. 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 10:43:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhqAR-0001pQ-S2; Mon, 13 Jun 2005 10:43:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhqAP-0001pL-FV for ips@megatron.ietf.org; Mon, 13 Jun 2005 10:43:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18764 for ; Mon, 13 Jun 2005 10:43:55 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhqWh-0000J3-PS for ips@ietf.org; Mon, 13 Jun 2005 11:07:00 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j5DEhd31014394; Mon, 13 Jun 2005 10:43:40 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jun 2005 10:43:39 -0400 Message-ID: To: mako@almaden.ibm.com Subject: RE: [Ips] WG Last Call Review: iSER Date: Mon, 13 Jun 2005 10:43:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.13.12 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CHILD_PORN_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mike, There are a couple of problems in what you propose: > (3) Section 3.3., item 5. says "MUST successfully negotiate > the TargetRecvDataSegmentLength key". Again there's a "takes > two to negotiate" problem, and the "failed to successfully > negotiate" case needs to be specified. > > [mk] The old items 4 and 5 are now replaced by the new item 4 > with the following text: > > "The iSCSI Layers at both the initiator and the target MUST > support the keys as defined in section 6 on Login/Text Operational Keys. > If used as specified, these keys MUST NOT be answered with NotUnderstood > and the semantics as defined MUST be followed for each iSER-assisted > connection." That would be ok for the case where there are iSER systems on both ends of a connection, but your new text indirectly forbids connecting an iSER implementation to a non-iSER one (i.e., Traditional iSCSI), as this would violate the first MUST (at least one of the systems will not support the new keys). This text (and all of the negotiation text) needs to be rephrased to apply to a single system, and specify requirements on that system - if iSER is to be used, then the following keys MUST be offered or responded to in negotiation *and* if this negotiation fails for any reason (e.g., a NotUnderstood response, or lack of an offered key that would be necessary to use iSER), then iSER MUST NOT be used, and traditional iSCSI is used instead. It is important to specify the fallback-to-Traditional-iSCSI cases in the negotiation requirements, as appealing to the covering "in order to use iSER" text is not enough because it doesn't cover what happens when negotiation fails. This needs to be done at least in Section 5.1 also. > (10) Section 8.4 could result in a situation where an iSER Target > cannot send a Reject PDU that an iSCSI Target would be > able send. It needs to explain what to do in that situation. > > [mk] The following text has been added in section 8.4: > (Implementation note: If the number of outstanding unexpected > control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will not > be able to send another unexpected control-type PDU until some outstanding > ones have been retired. To ensure that the initiator has a means of > retiring outstanding PDUs, the target should reserve the last unexpected > control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in > ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the > initiator to return the NOP-out ping response with the > current ExpStatSN.) While that helps, it still doesn't respond to the comment's request to explain what an iSER target should do when it wants to send a Reject PDU but cannot due to this limitation. Is the target required to remember the PDU that caused the reject until it gets enough space to send a Reject? How much effort does it put into obtaining permission to send the Reject before doing something else, and what is that something else? 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: Mike Ko [mailto:mako@almaden.ibm.com] > Sent: Monday, June 13, 2005 1:10 AM > To: Black_David@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] WG Last Call Review: iSER > > David, > > Thanks for the review. Please see my comments inline. > > Mike > Sent by: ips-bounces@ietf.org > To: ips@ietf.org > cc: > Subject: [Ips] WG Last Call Review: iSER > > > I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, > and in addition to editorial issues that I will send > directly to Mike, I found a number of technical issues: > > (1) Section 3.3 has a structural problem in that the first > sentence says "should satisfy" and the remaining sentences > to be satisfied are expressed as "MUST" requirements. The > net result is that all the requirements in that section are > "should" requirements, which is not what was intended. > The first sentence needs to be rewritten to say something > to the effect of "In order to use iSER, the following MUST > be done:" . > > [mk] ok > > (2) Section 3.3, item 1. says "MUST negotiate the > RDMAExtensions key to "Yes" " Since the key is negotiated > (not declared) and it takes two to negotiate, that requirement > cannot be achieved by an implementation if the other side > doesn't cooperate. This needs to be rewritten to talk about > offering the key as "Yes" and replying as "Yes" and that > if the result is not "Yes" then iSER is not used (traditional > iSCSI is used instead). > > [mk] ok > > (3) Section 3.3., item 5. says "MUST successfully negotiate > the TargetRecvDataSegmentLength key". Again there's a "takes > two to negotiate" problem, and the "failed to successfully > negotiate" case needs to be specified. > > [mk] The old items 4 and 5 are now replaced by the new item 4 > with the > follwowing text: > > "The iSCSI Layers at both the initiator and the target MUST > support the > keys as defined in section 6 on Login/Text Operational Keys. > If used as > specified, these keys MUST NOT be answered with NotUnderstood and the > semantics as defined MUST be followed for each iSER-assisted > connection." > > (4) Section 5.1, last two paragraphs have similar problems in > that they specify required negotiation behavior without > describing what to do when the other side doesn't cooperate > or do what it is supposed to. Those failure cases need to > be covered. > > [mk] The new text for comment #3 should address this issue. > > (5) Section 5.1.2, in the Note at the very end of the section > about two steps needing to be atomic, "must" should be "MUST". > > [mk] ok > > (6) Section 5.1.3 is missing specification and explanation of > version negotiation and version numbers in the iSER Hello > Exchange. The error case instructions for when version > negotiation fails need to be copied here in addition to their > current location in Section 10.1.3.2 . > > [mk] ok > > (7) Section 7.3.9 - I believe sending of Login Request or Login > Response in Datamover mode is always an error. This section > should say so and say what to do about it. > > [mk] ok > > (8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling > does not work because the instruction in 10.2.1 to handle SNACK > as per RFC 3720 would require retransmission of non-existent > Data and R2T PDUs. I can see a couple of possible corrective > approaches: > a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK > PDUs (instead of the current SHOULD NOT) and change > Section 10.2.1 to define reception of any SNACK PDU as > an error. > b) Put limits on what SNACK PDUs can be used to recover > (Status only?) in Section 7.3.11, and modify Section > 10.2.1 to say how to recover that and what to do when > a prohibited SNACK is received. > > [mk] The updated iSER draft will follow the suggestion in 8a. Also > updated text in section 3.3 and section 8.3 on SNACK handling. > > (9) Section 8.1 uses the phrase "buffer underrun" for an "out > of buffers" condition. That should be "buffer exhaustion". > > [mk] ok > > (10) Section 8.4 could result in a situation where an iSER Target > cannot send a Reject PDU that an iSCSI Target would be > able send. It needs to explain what to do in that situation. > > [mk] The following text has been added in section 8.4: > (Implementation note: If the number of outstanding unexpected > control-type PDUs equals MaxOutstandingUnexpectedPDUs, the > target will not > be able to send another unexpected control-type PDU until > some outstanding > ones have been retired. To ensure that the initiator has a means of > retiring outstanding PDUs, the target should reserve the last > unexpected > control-type PDU allowable by MaxOutstandingUnexpectedPDUs as > a NOP-in > ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the > initiator to return the NOP-out ping response with the > current ExpStatSN.) > > (11) Section 11 on Security Considerations is weak, but the > overall approach of appealing to security considerations in > other specifications is probably ok. This section needs to > be strengthened by saying that since iSER is still functionally > iSCSI, all of the iSCSI security considerations in RFC 3720 > apply, and it should also reference the discussion of iSCSI > security in RFC 3723. > > [mk] This section now references RFC3723 and the security > drafts for RDDP. > Both documents have also been added to the list of references. > > 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 > ---------------------------------------------------- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 10:58:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhqOA-0004qW-MI; Mon, 13 Jun 2005 10:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhqO7-0004oi-Dr for ips@megatron.ietf.org; Mon, 13 Jun 2005 10:58:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19720 for ; Mon, 13 Jun 2005 10:58:05 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhqkP-0000zB-83 for ips@ietf.org; Mon, 13 Jun 2005 11:21:10 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j5DEvwxN023008; Mon, 13 Jun 2005 10:57:58 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jun 2005 10:57:59 -0400 Message-ID: To: cbm@rose.hp.com, mako@almaden.ibm.com Subject: RE: [Ips] WG Last Call Review: DA Date: Mon, 13 Jun 2005 10:57:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.13.14 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, I think this is ok, although there will probably be quibbles with the wording and requests for further elaboration later on. Mike - Please make sure that the new "MUST" (essentially "MUST complete any security negotiation before allocation of data movement connection resources" is reflected in the iSER draft. 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: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Wednesday, June 08, 2005 10:16 PM > To: Black_David@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] WG Last Call Review: DA > > David, > > Here is the security re-write for the next rev of DA. Please > review/comment. > > Note the new MUST requirement around iSCSI > SecurityNegotiation stage wrt > resource allocation. I do not believe it requires any changes to the > iSER draft, but other co-authors may want to check me on that. > > Thanks. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > 12 Security Considerations > 12.1 Architectural Considerations > DA enables compliant iSCSI implementations to realize a > control and data > separation in the way they interact with their Datamover protocols. > Note however that this separation does not imply a separation in > transport mediums between control traffic and data traffic - > basic iSCSI > architecture with respect to tasks and PDU relationships to tasks > remains unchanged. [RFC3720] defines several MUST requirements on > ordering relationships across control and data for a given > task besides > a mandatory deterministic task allegiance model - DA does not change > this basic architecture (DA has a normative reference on > [RFC3720]) nor > allow any additional flexibility in compliance in this area. To > summarize, sending bulk data transfers (prompted by Put_Data and > Get_Data Primitive invocations) on a different transport > medium would be > as ill-advised as sending just the Data-out/Data-in PDUs on a > different > TCP connection in RFC 3720-based iSCSI implementations. > Consequently, > all the iSCSI-related security text in [RFC3723] is directly > applicable > to a DA-enabled iSCSI implementation. > > Another area with security implications is the Datamover connection > resource management model which DA defines - particularly the > Allocate_Connection_Resources Primitive. An inadvertent > realization of > this model could leave an iSCSI implementation exposed to denial of > service attacks. As Figure 2 and Figure 3 in section 17.2 > illustrate, > the most effective countermeasure to this potential attack > consists of > performing the Datamover resource allocation when the iSCSI layer is > sufficiently far along in the iSCSI Login Phase that it is reasonably > certain that the peer side is not an attacker. In particular, if the > Login Phase includes a SecurityNegotiation stage, an iSCSI > end node MUST > defer the Datamover connection resource allocation (i.e. invoking the > Allocate_Connection_Resources Primitive) to the > LoginOperationalNegotiation stage ([RFC3720]) so that the resource > allocation happens post-authentication. This considerably > minimizes the > potential for a denial of service attack. > > 12.2 Wire Protocol Considerations > In view of the fact that the DA architecture itself does not > define any > new wire protocol nor propose modifications to the existing > protocols, > there are no additional wire protocol security considerations in > employing DA itself. However, a DA-compliant iSCSI > implementation MUST > comply with all the iSCSI-related requirements stipulated in > [RFC3723] > and [RFC3720]. Note further that in realizing DA, each Datamover > protocol must define and elaborate as appropriate on any additional > security considerations resulting from the use of that > Datamover protocol. > > All Datamover protocol designers are strongly recommended to refer to > [RDDPSEC] for the types of security issues to consider. > While [RDDPSEC] > elaborates on the security considerations applicable to an RDDP-based > Datamover ([iSER]), the document is representative of the type of > analysis of resource exhaustion and the application of > countermeasures > that needs to be done for any Datamover protocol. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 14:14:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhtQa-0004Tn-IR; Mon, 13 Jun 2005 14:12:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhtQW-0004TA-9v for ips@megatron.ietf.org; Mon, 13 Jun 2005 14:12:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05066 for ; Mon, 13 Jun 2005 14:12:47 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhtmo-0001BU-QE for ips@ietf.org; Mon, 13 Jun 2005 14:35:53 -0400 Received: from ivvt2dxrc11 (unknown[64.238.111.98]) by comcast.net (sccrmhc13) with SMTP id <2005061318123401600d9fede>; Mon, 13 Jun 2005 18:12:34 +0000 Message-ID: <000301c57043$769dcce0$9101a8c0@ivivity.com> From: "Eddy Quicksall" To: "Mallikarjun C." , References: <000301c5685b$a1aeb060$03031eac@ivivity.com><000a01c56bc7$cb78c240$6e00470a@ivivity.com> <42A9D53E.8010002@rose.hp.com> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Mon, 13 Jun 2005 14:12:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Actually, I was talking about a clarification of what is expected of the target and initiator in the event that the RFC does not cover it with a MUST. The problem is that some people think the target must check for all protocol errors. This is not practical and sometimes not even possible for all cases. Perhaps wording similar to this would be in order: "Except where specifically noted, the initiator and target are not expected to catch all protocol errors introduced by the other party and it is the implementers option as to which errors may be caught due to internal dynamics." Eddy ----- Original Message ----- From: "Mallikarjun C." To: Sent: Friday, June 10, 2005 2:00 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > My comment on this is that such a blanket statement will be a problem. > > RFC 3720 has a defined notion of protocol errors and their handling, and > uses a fair number of MUSTs (sometimes conditional) on Rejects (as PDUs > and in negotiation) - e.g., if you support data digests, you must discard > a bad digest PDU with a Reject. These actions inherently require protocol > validation and catching errors. I don't think we want to weaken any of > that. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Eddy Quicksall wrote: >> What do you think about this? I don't remember seeing an answer. >> >> Eddy >> >> ----- Original Message ----- From: "Eddy Quicksall" >> >> To: ; ; >> Sent: Friday, June 03, 2005 12:45 PM >> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET >> >> >>> If you are going to write this guide, I would like to suggest that a >>> paragraph be added saying something like "the initiator and target are >>> not expected to catch all protocol errors introduced by the other party >>> and it is the implementers option as to which errors may be caught due >>> to internal dynamics, crash dynamics or data corruption". >>> >>> Eddy >>> >>> ----- Original Message ----- From: >>> To: ; >>> Sent: Friday, June 03, 2005 8:51 AM >>> Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET >>> >>> >>>> Mallikarjun, >>>> >>>>> I am concerned that the current lack of detailed specification would >>>>> allow targets that might even cause silent data corruptions >>>>> to qualify as RFC 3720-compliant. >>>>> >>>>> Here are what I believe to be semantics applicable to all TMF requests >>>>> that can potentially terminate multiple tasks. I do not know the IETF >>>>> process well enough here, but I suggest that we consider this text >>>>> replacing the existing section 10.6.2 in RFC 3720 - so the new text >>>>> can >>>>> cover all the TMFs that can impact multiple tasks. This is basically >>>>> a >>>>> superset of the current 10.6.2 semantics. >>>> >>>> >>>> IETF does have an errata process, but (IMHO) it's not a great venue >>>> for something like this that it's important for implementers to pay >>>> attention to. What I would suggest is that we start an Internet-Draft >>>> that is intended to become an Implementers Guide RFC (standards track) >>>> to include both technical corrections like this one, and explanations >>>> of subtle points such as how to deal with (what appear to be) REPORT >>>> LUNS overruns as discussed here earlier. An available example is that >>>> an implementers guide draft is being maintained for SCTP (see >>>> draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that >>>> an iSCSI implementers guide won't grow to that size. >>>> >>>> For this task management issue, explaining what the problem is and why >>>> the change fixes it in an implementers guide is at least as important >>>> as >>>> specifying the change. For the REPORT LUNS overruns, the implementers >>>> guide text would be an explanation of why no change is needed, >>>> including >>>> some elaboration on the (less than completely obvious) SPC-2 text that >>>> specifies the behavior of REPORT LUNS in this circumstance. Before I >>>> go looking for another volunteer, would you be interested in editing >>>> an implementers guide Internet Draft? Between Julian and I, we should >>>> be able write the REPORT LUNS explanation paragraph or two. >>>> >>>> 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 >>>> ---------------------------------------------------- >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>> >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 14:42:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhtt8-0001kY-V1; Mon, 13 Jun 2005 14:42:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhtt5-0001kI-KT for ips@megatron.ietf.org; Mon, 13 Jun 2005 14:42:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07212 for ; Mon, 13 Jun 2005 14:42:18 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhuFP-0002V5-7a for ips@ietf.org; Mon, 13 Jun 2005 15:05:24 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j5DIgEk2024963; Mon, 13 Jun 2005 14:42:14 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jun 2005 14:42:14 -0400 Message-ID: To: eddy_quicksall_iVivity_iSCSI@comcast.net, ips@ietf.org Date: Mon, 13 Jun 2005 14:42:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.13.21 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: Subject: [Ips] Error detection responsibility X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Eddy, I agree with Mallikarjun that a blanket statement, even one like the second one you proposed, is a bad idea. I think a better approach would be to identify the specific cases for which you believe it's unreasonable for a target to make comprehensive error checks, and document what an implementation MAY choose not to check. A blanket statement like the one you proposed still leaves implementers scratching their heads about what they're supposed to do. 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: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Eddy Quicksall > Sent: Monday, June 13, 2005 2:12 PM > To: Mallikarjun C.; ips@ietf.org > Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > > Actually, I was talking about a clarification of what is expected of the > target and initiator in the event that the RFC does not cover it with a > MUST. The problem is that some people think the target must check for all > protocol errors. This is not practical and sometimes not even possible for > all cases. > > Perhaps wording similar to this would be in order: > > "Except where specifically noted, the initiator and target are > not expected to catch all protocol errors introduced by the other > party and it is the implementers option as to which errors may be > caught due to internal dynamics." > > Eddy > > ----- Original Message ----- > From: "Mallikarjun C." > To: > Sent: Friday, June 10, 2005 2:00 PM > Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > > > > My comment on this is that such a blanket statement will be a problem. > > > > RFC 3720 has a defined notion of protocol errors and their handling, and > > uses a fair number of MUSTs (sometimes conditional) on Rejects (as PDUs > > and in negotiation) - e.g., if you support data digests, you must discard > > a bad digest PDU with a Reject. These actions inherently require protocol > > validation and catching errors. I don't think we want to weaken any of > > that. > > > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > StorageWorks Division > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm [at] rose.hp.com > > > > > > Eddy Quicksall wrote: > >> What do you think about this? I don't remember seeing an answer. > >> > >> Eddy > >> > >> ----- Original Message ----- From: "Eddy Quicksall" > >> > >> To: ; ; > >> Sent: Friday, June 03, 2005 12:45 PM > >> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > >> > >> > >>> If you are going to write this guide, I would like to suggest that a > >>> paragraph be added saying something like "the initiator and target are > >>> not expected to catch all protocol errors introduced by the other party > >>> and it is the implementers option as to which errors may be caught due > >>> to internal dynamics, crash dynamics or data corruption". > >>> > >>> Eddy > >>> > >>> ----- Original Message ----- From: > >>> To: ; > >>> Sent: Friday, June 03, 2005 8:51 AM > >>> Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET > >>> > >>> > >>>> Mallikarjun, > >>>> > >>>>> I am concerned that the current lack of detailed specification would > >>>>> allow targets that might even cause silent data corruptions > >>>>> to qualify as RFC 3720-compliant. > >>>>> > >>>>> Here are what I believe to be semantics applicable to all TMF requests > >>>>> that can potentially terminate multiple tasks. I do not know the IETF > >>>>> process well enough here, but I suggest that we consider this text > >>>>> replacing the existing section 10.6.2 in RFC 3720 - so the new text > >>>>> can cover all the TMFs that can impact multiple tasks. This is basically > >>>>> a superset of the current 10.6.2 semantics. > >>>> > >>>> > >>>> IETF does have an errata process, but (IMHO) it's not a great venue > >>>> for something like this that it's important for implementers to pay > >>>> attention to. What I would suggest is that we start an Internet-Draft > >>>> that is intended to become an Implementers Guide RFC (standards track) > >>>> to include both technical corrections like this one, and explanations > >>>> of subtle points such as how to deal with (what appear to be) REPORT > >>>> LUNS overruns as discussed here earlier. An available example is that > >>>> an implementers guide draft is being maintained for SCTP (see > >>>> draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that > >>>> an iSCSI implementers guide won't grow to that size. > >>>> > >>>> For this task management issue, explaining what the problem is and why > >>>> the change fixes it in an implementers guide is at least as important > >>>> as specifying the change. For the REPORT LUNS overruns, the implementers > >>>> guide text would be an explanation of why no change is needed, including > >>>> some elaboration on the (less than completely obvious) SPC-2 text that > >>>> specifies the behavior of REPORT LUNS in this circumstance. Before I > >>>> go looking for another volunteer, would you be interested in editing > >>>> an implementers guide Internet Draft? Between Julian and I, we should > >>>> be able write the REPORT LUNS explanation paragraph or two. > >>>> > >>>> 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 > >>>> ---------------------------------------------------- > >>>> > >>>> _______________________________________________ > >>>> Ips mailing list > >>>> Ips@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/ips > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ips mailing list > >>> Ips@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ips > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 15:44:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhurU-0006rw-8p; Mon, 13 Jun 2005 15:44:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhurT-0006rm-KV for ips@megatron.ietf.org; Mon, 13 Jun 2005 15:44:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17244 for ; Mon, 13 Jun 2005 15:44:41 -0400 (EDT) From: Hutchinson_Adam@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhvDn-0006Rt-Du for ips@ietf.org; Mon, 13 Jun 2005 16:07:49 -0400 Received: from corpusic3.corp.emc.com (corpusic3.corp.emc.com [10.254.64.109]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j5DJibH8029869 for ; Mon, 13 Jun 2005 15:44:37 -0400 (EDT) Received: by corpusic3.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jun 2005 15:44:36 -0400 Message-ID: To: ips@ietf.org Date: Mon, 13 Jun 2005 15:44:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.13.23 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ips] iSCSI Login PDU in FFP X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Is it valid under any circumstances for an initiator to send a Login Request PDU on a TCP connection that belongs to a full-feature iSCSI connection? I believe it is implied by the initiator connection state machine that this cannot happen, however, I don't recall see it clearly stated that Login PDUs should only be sent during the Login phase. Thanks, Adam _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 15:52:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuzC-0002j0-DC; Mon, 13 Jun 2005 15:52:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuzB-0002iZ-69 for ips@megatron.ietf.org; Mon, 13 Jun 2005 15:52:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20401 for ; Mon, 13 Jun 2005 15:52:38 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhvLV-0007fe-1l for ips@ietf.org; Mon, 13 Jun 2005 16:15:45 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j5DJqZ3O017309 for ; Mon, 13 Jun 2005 15:52:36 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jun 2005 15:52:35 -0400 Message-ID: To: ips@ietf.org Date: Mon, 13 Jun 2005 15:52:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.13.23 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CHILD_PORN_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ips] New work item: iSCSI Implementer's Guide X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Everyone, The IPS WG has received Area Director approval to work on an iSCSI Implementers Guide. This will be a standards track draft (will become a Proposed Standard RFC) whose purpose is to clarify and correct any problems in the iSCSI RFC (RFC 3720). It is **not** a license to revisit iSCSI design decisions, make major changes to the iSCSI protocol or add major functionality to iSCSI, although it may be a means to discourage implementation of things that aren't in use (e.g., a sentence saying that iSCSI markers SHOULD NOT be implemented would be within reason). I want to thank Mallikarjun for agreeing to edit this draft. The initial version should be submitted with a name of draft-ietf-ips-iscsi-impl-guide-00.txt or something like that. To a first approximation, the things that belong in the implementers guide are things that an implementer wishes s/he had known after first reading RFC 3720 ... but had to learn/figure out the hard way. So far, we have two topics for this draft: - Update to task management function handling when multiple tasks are to be terminated (Mallikarjun C.). - Explanation of why REPORT LUNS command cannot cause an iSCSI overrun (David B.). If Eddy Q. comes up with a specific proposal to clarify some error conditions that a target should not be REQUIRED to check (and we agree to it), that could be a third topic. Those who would like to see other topics covered should send those suggestions to the list, but be aware than any suggestion to cover a topic will be interpreted as an offer to write text describing it ... My initial intention is to hold this draft open for a while so that we can pick up more issues as they arise - at the moment, my thinking is to hold this open for at least a year. 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 17:50:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhwpO-0007cv-Nk; Mon, 13 Jun 2005 17:50:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhwpM-0007cq-Qs for ips@megatron.ietf.org; Mon, 13 Jun 2005 17:50:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09295 for ; Mon, 13 Jun 2005 17:50:38 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhxBg-0007xi-Bj for ips@ietf.org; Mon, 13 Jun 2005 18:13:47 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id F0F3D87084; Mon, 13 Jun 2005 17:50:25 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <07090d179c469f6b922d95795b2c7bdc@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] iSCSI Login PDU in FFP Date: Mon, 13 Jun 2005 14:50:19 -0700 To: Hutchinson_Adam@emc.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1626670068==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1626670068== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-805782856" Content-Transfer-Encoding: 7bit --Apple-Mail-5-805782856 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jun 13, 2005, at 12:44 PM, Hutchinson_Adam@emc.com wrote: > Is it valid under any circumstances for an initiator to send a Login > Request > PDU on a TCP connection that belongs to a full-feature iSCSI > connection? I > believe it is implied by the initiator connection state machine that > this > cannot happen, however, I don't recall see it clearly stated that > Login PDUs > should only be sent during the Login phase. Section 3.2.3: Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. Login requests and responses MUST be used exclusively during Login. On any connection, the login phase MUST immediately follow TCP connection establishment and a subsequent Login Phase MUST NOT occur before tearing down a connection. Take care, Bill --Apple-Mail-5-805782856 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCrf+hDJT2Egh26K0RAtKSAKCRd2pBk+ZNfMjSY15xfxqJUv0PsgCeLGXX oLVm2HQ63zXfQjoT9KWJ+sU= =AVRY -----END PGP SIGNATURE----- --Apple-Mail-5-805782856-- --===============1626670068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1626670068==-- From ips-bounces@ietf.org Mon Jun 13 19:18:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhyCh-0007xB-9c; Mon, 13 Jun 2005 19:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhyCd-0007vR-UF for ips@megatron.ietf.org; Mon, 13 Jun 2005 19:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19284 for ; Mon, 13 Jun 2005 19:18:44 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhyYy-00047Z-DB for ips@ietf.org; Mon, 13 Jun 2005 19:41:55 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5DNIUvl024434 for ; Mon, 13 Jun 2005 19:18:30 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5DNIUah245666 for ; Mon, 13 Jun 2005 19:18:30 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5DNIUAr031005 for ; Mon, 13 Jun 2005 19:18:30 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5DNIU2b031002; Mon, 13 Jun 2005 19:18:30 -0400 In-Reply-To: Importance: Normal MIME-Version: 1.0 To: Black_David@emc.com Subject: RE: [Ips] WG Last Call Review: iSER X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Mon, 13 Jun 2005 16:18:28 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_04122005|April 12, 2005) at 06/13/2005 19:18:29, Serialize complete at 06/13/2005 19:18:29 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org David, On rereading section 3, bullet 1 should have been separated out from the other bullets. Bullet 1 addressed the issue where an iSER implementation attempts a connection with a non-iSER one, and it mandates that iSER-assisted mode must not be used if RDMAExtensions is negotiated to "No". But the remaining bullets deal with the situation assuming RDMAExtensions have been negotiated to "Yes". If the connection is to operate in iSER-assisted mode, then the rest of the bullets (except bullet 1) must be followed. If any of the other bullets are not followed, then the connection cannot really fall back to traditional iSCSI mode since RDMAExtensions have been negotiated to "Yes". Not implementing those other bullets in an iSER-assisted mode is an error. So here is the proposed new text for section 3.3: --- start of replacement section 3.3 To operate in an iSER-assisted mode, the iSCSI Layers at both the initiator and the target MUST negotiate the RDMAExtensions key (see section 6.3) to "Yes" on the leading connection. If the RDMAExtensions key is not negotiated to "Yes", then iSER-assisted mode MUST NOT be used. If the RDMAExtensons key is negotiated to "Yes" but the invocation of the Allocate_Connection_Resources Operational Primitive to the iSER layer fails, the iSCSI layer MUST fail the iSCSI Login process or terminate the connection as appropriate. See section 10.1.3.1 for details. If the RDMAExtensions key is negotiated to "Yes", the iSCSI Layer MUST satisfy the following protocol usage requirements from the iSER protocol: 1. The iSCSI Layer at the initiator MUST set ExpDataSN = 0 in Task Management Function Requests for Task Allegiance Reassignment for read/bidirectional commands, so as to cause the target to send all unacknowledged read data. 2. The iSCSI Layer at the target MUST always return the SCSI status in a separate SCSI Response PDU for read commands, i.e., there MUST NOT be a "phase collapse" in concluding a SCSI Read Command. 3. The iSCSI Layers at both the initiator and the target MUST support the keys as defined in section 6 on Login/Text Operational Keys. If used as specified, these keys MUST NOT be answered with NotUnderstood and the semantics as defined MUST be followed for each iSER-assisted connection. 4. The iSCSI Layer at the initiator MUST NOT issue proactive (based on time-outs) SNACKs for PDUs that it presumes are lost. --- end of replacement section 3.3 For section 8.4 (now section 8.1.2), if the iSER target wants to send a Reject but couldn't do so because of the limits imposed by MaxOutstandingUnexpectedPDUs, the PDU will be discarded. To the initiator, this is similar to receiving a Reject PDU with a digest error. Section 6.7 of RFC3720 states that "When an initiator receives any iSCSI PDU with a payload digest error, it MUST discard the PDU." Furthermore, "No further action is necessary for initiators if the discarded PDU is an unsolicited PDU (e.g., Async, Reject). Task timeouts as in the initiator waiting for a command completion, or process timeouts, as in the target waiting for a Logout, will ensure that the correct operational behavior will result in these cases despite the discarded PDU." It is incumbent upon the initiator to declare a reasonable limit on MaxOutstandingUnexpectedPDUs to avoid the situation where the target has to discard a PDU due to lack of resources on the initiator's side. As stated in section 8.1, shared buffer pools can always be used to minimize the risk. I can modify the new text in section 8.1.2 as follows: "If the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will not be able to send another unexpected control-type PDU until some outstanding ones have been retired. In this case the unexpected PDU will be discarded and not sent by the target. Task timeouts as in the initiator waiting for a command completion, or process timeouts, as in the target waiting for a Logout, will ensure that the correct operational behavior will result in these cases despite the discarded PDU. (Implementation note: To ensure that the initiator has a means to inform the target that outstanding PDUs have been retired, the target should reserve ... with the current ExpStatSN.)" Mike To: mako@almaden.ibm.com cc: ips@ietf.org Subject: RE: [Ips] WG Last Call Review: iSER Mike, There are a couple of problems in what you propose: > (3) Section 3.3., item 5. says "MUST successfully negotiate > the TargetRecvDataSegmentLength key". Again there's a "takes > two to negotiate" problem, and the "failed to successfully > negotiate" case needs to be specified. > > [mk] The old items 4 and 5 are now replaced by the new item 4 > with the following text: > > "The iSCSI Layers at both the initiator and the target MUST > support the keys as defined in section 6 on Login/Text Operational Keys. > If used as specified, these keys MUST NOT be answered with NotUnderstood > and the semantics as defined MUST be followed for each iSER-assisted > connection." That would be ok for the case where there are iSER systems on both ends of a connection, but your new text indirectly forbids connecting an iSER implementation to a non-iSER one (i.e., Traditional iSCSI), as this would violate the first MUST (at least one of the systems will not support the new keys). This text (and all of the negotiation text) needs to be rephrased to apply to a single system, and specify requirements on that system - if iSER is to be used, then the following keys MUST be offered or responded to in negotiation *and* if this negotiation fails for any reason (e.g., a NotUnderstood response, or lack of an offered key that would be necessary to use iSER), then iSER MUST NOT be used, and traditional iSCSI is used instead. It is important to specify the fallback-to-Traditional-iSCSI cases in the negotiation requirements, as appealing to the covering "in order to use iSER" text is not enough because it doesn't cover what happens when negotiation fails. This needs to be done at least in Section 5.1 also. > (10) Section 8.4 could result in a situation where an iSER Target > cannot send a Reject PDU that an iSCSI Target would be > able send. It needs to explain what to do in that situation. > > [mk] The following text has been added in section 8.4: > (Implementation note: If the number of outstanding unexpected > control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will not > be able to send another unexpected control-type PDU until some outstanding > ones have been retired. To ensure that the initiator has a means of > retiring outstanding PDUs, the target should reserve the last unexpected > control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in > ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the > initiator to return the NOP-out ping response with the > current ExpStatSN.) While that helps, it still doesn't respond to the comment's request to explain what an iSER target should do when it wants to send a Reject PDU but cannot due to this limitation. Is the target required to remember the PDU that caused the reject until it gets enough space to send a Reject? How much effort does it put into obtaining permission to send the Reject before doing something else, and what is that something else? 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: Mike Ko [mailto:mako@almaden.ibm.com] > Sent: Monday, June 13, 2005 1:10 AM > To: Black_David@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] WG Last Call Review: iSER > > David, > > Thanks for the review. Please see my comments inline. > > Mike > Sent by: ips-bounces@ietf.org > To: ips@ietf.org > cc: > Subject: [Ips] WG Last Call Review: iSER > > > I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, > and in addition to editorial issues that I will send > directly to Mike, I found a number of technical issues: > > (1) Section 3.3 has a structural problem in that the first > sentence says "should satisfy" and the remaining sentences > to be satisfied are expressed as "MUST" requirements. The > net result is that all the requirements in that section are > "should" requirements, which is not what was intended. > The first sentence needs to be rewritten to say something > to the effect of "In order to use iSER, the following MUST > be done:" . > > [mk] ok > > (2) Section 3.3, item 1. says "MUST negotiate the > RDMAExtensions key to "Yes" " Since the key is negotiated > (not declared) and it takes two to negotiate, that requirement > cannot be achieved by an implementation if the other side > doesn't cooperate. This needs to be rewritten to talk about > offering the key as "Yes" and replying as "Yes" and that > if the result is not "Yes" then iSER is not used (traditional > iSCSI is used instead). > > [mk] ok > > (3) Section 3.3., item 5. says "MUST successfully negotiate > the TargetRecvDataSegmentLength key". Again there's a "takes > two to negotiate" problem, and the "failed to successfully > negotiate" case needs to be specified. > > [mk] The old items 4 and 5 are now replaced by the new item 4 > with the > follwowing text: > > "The iSCSI Layers at both the initiator and the target MUST > support the > keys as defined in section 6 on Login/Text Operational Keys. > If used as > specified, these keys MUST NOT be answered with NotUnderstood and the > semantics as defined MUST be followed for each iSER-assisted > connection." > > (4) Section 5.1, last two paragraphs have similar problems in > that they specify required negotiation behavior without > describing what to do when the other side doesn't cooperate > or do what it is supposed to. Those failure cases need to > be covered. > > [mk] The new text for comment #3 should address this issue. > > (5) Section 5.1.2, in the Note at the very end of the section > about two steps needing to be atomic, "must" should be "MUST". > > [mk] ok > > (6) Section 5.1.3 is missing specification and explanation of > version negotiation and version numbers in the iSER Hello > Exchange. The error case instructions for when version > negotiation fails need to be copied here in addition to their > current location in Section 10.1.3.2 . > > [mk] ok > > (7) Section 7.3.9 - I believe sending of Login Request or Login > Response in Datamover mode is always an error. This section > should say so and say what to do about it. > > [mk] ok > > (8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling > does not work because the instruction in 10.2.1 to handle SNACK > as per RFC 3720 would require retransmission of non-existent > Data and R2T PDUs. I can see a couple of possible corrective > approaches: > a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK > PDUs (instead of the current SHOULD NOT) and change > Section 10.2.1 to define reception of any SNACK PDU as > an error. > b) Put limits on what SNACK PDUs can be used to recover > (Status only?) in Section 7.3.11, and modify Section > 10.2.1 to say how to recover that and what to do when > a prohibited SNACK is received. > > [mk] The updated iSER draft will follow the suggestion in 8a. Also > updated text in section 3.3 and section 8.3 on SNACK handling. > > (9) Section 8.1 uses the phrase "buffer underrun" for an "out > of buffers" condition. That should be "buffer exhaustion". > > [mk] ok > > (10) Section 8.4 could result in a situation where an iSER Target > cannot send a Reject PDU that an iSCSI Target would be > able send. It needs to explain what to do in that situation. > > [mk] The following text has been added in section 8.4: > (Implementation note: If the number of outstanding unexpected > control-type PDUs equals MaxOutstandingUnexpectedPDUs, the > target will not > be able to send another unexpected control-type PDU until > some outstanding > ones have been retired. To ensure that the initiator has a means of > retiring outstanding PDUs, the target should reserve the last > unexpected > control-type PDU allowable by MaxOutstandingUnexpectedPDUs as > a NOP-in > ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the > initiator to return the NOP-out ping response with the > current ExpStatSN.) > > (11) Section 11 on Security Considerations is weak, but the > overall approach of appealing to security considerations in > other specifications is probably ok. This section needs to > be strengthened by saying that since iSER is still functionally > iSCSI, all of the iSCSI security considerations in RFC 3720 > apply, and it should also reference the discussion of iSCSI > security in RFC 3723. > > [mk] This section now references RFC3723 and the security > drafts for RDDP. > Both documents have also been added to the list of references. > > 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 > ---------------------------------------------------- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 20:07:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhyxe-0004ci-UK; Mon, 13 Jun 2005 20:07:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhyxb-0004cM-AO for ips@megatron.ietf.org; Mon, 13 Jun 2005 20:07:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23281 for ; Mon, 13 Jun 2005 20:07:17 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhzJy-0006Nu-M2 for ips@ietf.org; Mon, 13 Jun 2005 20:30:27 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5E075st026146 for ; Mon, 13 Jun 2005 20:07:05 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5E06oah244922 for ; Mon, 13 Jun 2005 20:07:05 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5E06oXt028973 for ; Mon, 13 Jun 2005 20:06:50 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5E06oK3028962; Mon, 13 Jun 2005 20:06:50 -0400 In-Reply-To: Importance: Normal MIME-Version: 1.0 To: Black_David@emc.com Subject: RE: [Ips] WG Last Call Review: DA X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Mon, 13 Jun 2005 17:06:47 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_04122005|April 12, 2005) at 06/13/2005 20:06:49, Serialize complete at 06/13/2005 20:06:49 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: ips@ietf.org, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org David, The essence of the 2nd paragraph from the Security Considerations section of the DA draft will be added in section 5.1.1 (initiator behavior during iSCSI/iSER connection setup) and section 5.1.2 (target behavior). The "MUST" requirement on completing any security negotiation before allocating connection resources will remove all sentences in both sections that allow the allocation to occur before iSCSI login negotiations. Mike To: cbm@rose.hp.com, mako@almaden.ibm.com cc: ips@ietf.org Subject: RE: [Ips] WG Last Call Review: DA Mallikarjun, I think this is ok, although there will probably be quibbles with the wording and requests for further elaboration later on. Mike - Please make sure that the new "MUST" (essentially "MUST complete any security negotiation before allocation of data movement connection resources" is reflected in the iSER draft. 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: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Wednesday, June 08, 2005 10:16 PM > To: Black_David@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] WG Last Call Review: DA > > David, > > Here is the security re-write for the next rev of DA. Please > review/comment. > > Note the new MUST requirement around iSCSI > SecurityNegotiation stage wrt > resource allocation. I do not believe it requires any changes to the > iSER draft, but other co-authors may want to check me on that. > > Thanks. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > 12 Security Considerations > 12.1 Architectural Considerations > DA enables compliant iSCSI implementations to realize a > control and data > separation in the way they interact with their Datamover protocols. > Note however that this separation does not imply a separation in > transport mediums between control traffic and data traffic - > basic iSCSI > architecture with respect to tasks and PDU relationships to tasks > remains unchanged. [RFC3720] defines several MUST requirements on > ordering relationships across control and data for a given > task besides > a mandatory deterministic task allegiance model - DA does not change > this basic architecture (DA has a normative reference on > [RFC3720]) nor > allow any additional flexibility in compliance in this area. To > summarize, sending bulk data transfers (prompted by Put_Data and > Get_Data Primitive invocations) on a different transport > medium would be > as ill-advised as sending just the Data-out/Data-in PDUs on a > different > TCP connection in RFC 3720-based iSCSI implementations. > Consequently, > all the iSCSI-related security text in [RFC3723] is directly > applicable > to a DA-enabled iSCSI implementation. > > Another area with security implications is the Datamover connection > resource management model which DA defines - particularly the > Allocate_Connection_Resources Primitive. An inadvertent > realization of > this model could leave an iSCSI implementation exposed to denial of > service attacks. As Figure 2 and Figure 3 in section 17.2 > illustrate, > the most effective countermeasure to this potential attack > consists of > performing the Datamover resource allocation when the iSCSI layer is > sufficiently far along in the iSCSI Login Phase that it is reasonably > certain that the peer side is not an attacker. In particular, if the > Login Phase includes a SecurityNegotiation stage, an iSCSI > end node MUST > defer the Datamover connection resource allocation (i.e. invoking the > Allocate_Connection_Resources Primitive) to the > LoginOperationalNegotiation stage ([RFC3720]) so that the resource > allocation happens post-authentication. This considerably > minimizes the > potential for a denial of service attack. > > 12.2 Wire Protocol Considerations > In view of the fact that the DA architecture itself does not > define any > new wire protocol nor propose modifications to the existing > protocols, > there are no additional wire protocol security considerations in > employing DA itself. However, a DA-compliant iSCSI > implementation MUST > comply with all the iSCSI-related requirements stipulated in > [RFC3723] > and [RFC3720]. Note further that in realizing DA, each Datamover > protocol must define and elaborate as appropriate on any additional > security considerations resulting from the use of that > Datamover protocol. > > All Datamover protocol designers are strongly recommended to refer to > [RDDPSEC] for the types of security issues to consider. > While [RDDPSEC] > elaborates on the security considerations applicable to an RDDP-based > Datamover ([iSER]), the document is representative of the type of > analysis of resource exhaustion and the application of > countermeasures > that needs to be done for any Datamover protocol. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 13 21:29:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di0Ej-0000BN-DP; Mon, 13 Jun 2005 21:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di0Eg-0000B6-PI for ips@megatron.ietf.org; Mon, 13 Jun 2005 21:29:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28814 for ; Mon, 13 Jun 2005 21:29:00 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di0b4-0001Sh-5S for ips@ietf.org; Mon, 13 Jun 2005 21:52:11 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id 1978C403484 for ; Mon, 13 Jun 2005 18:29:00 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id DAD7F7FF4 for ; Mon, 13 Jun 2005 18:23:48 -0700 (PDT) Message-ID: <42AE32DE.2070204@rose.hp.com> Date: Mon, 13 Jun 2005 18:29:02 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] WG Last Call Review: iSER References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Mike, Some comments on the text discussed in this thread. 7.3.11 Get rid of " In particular, the Proactive (Time out) SNACK MUST NOT be issued." It is redundant now with the MUST NOT that precedes it. 3.3 (new replacement text) Change bullet 4 to: 4. The iSCSI Layer at the initiator MUST NOT issue SNACKs for PDUs. 8.1.2 (new text) Suggest changing the text to: "If the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target iSCSI layer will not be able to send another unexpected control-type PDU until some outstanding ones have been retired. In this case the the iSCSI layer SHOULD discard the unexpected PDU and allow the initiator iSCSI layer to respond to the resulting error (the discard in the target iSCSI layer manifests as as a lost PDU on the initiator). Task or sequence timeouts - as in the initiator waiting for a command completion - will ensure that the correct operational behavior will result in these cases despite the discarded PDU." 10.2.1 (new text) Suggest changing it to: "As described in section 7.3.11, SNACK PDUs are not used by the iSCSI Layer in the iSER-assisted mode." 11 (new text) Suggest changing it to: Since iSER-asisted iSCSI protocol is still functionally iSCSI from a security considerations perspective, all of the iSCSI security requirements as described in [RFC3720] and [RFC3723] apply. " Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mike Ko wrote: > David, > > On rereading section 3, bullet 1 should have been separated out from the > other bullets. Bullet 1 addressed the issue where an iSER implementation > attempts a connection with a non-iSER one, and it mandates that > iSER-assisted mode must not be used if RDMAExtensions is negotiated to > "No". But the remaining bullets deal with the situation assuming > RDMAExtensions have been negotiated to "Yes". If the connection is to > operate in iSER-assisted mode, then the rest of the bullets (except bullet > 1) must be followed. If any of the other bullets are not followed, then > the connection cannot really fall back to traditional iSCSI mode since > RDMAExtensions have been negotiated to "Yes". Not implementing those > other bullets in an iSER-assisted mode is an error. So here is the > proposed new text for section 3.3: > > --- start of replacement section 3.3 > To operate in an iSER-assisted mode, the iSCSI Layers at both the > initiator and the target MUST negotiate the RDMAExtensions key (see > section 6.3) to "Yes" on the leading connection. If the RDMAExtensions > key is not negotiated to "Yes", then iSER-assisted mode MUST NOT be used. > If the RDMAExtensons key is negotiated to "Yes" but the invocation of the > Allocate_Connection_Resources Operational Primitive to the iSER layer > fails, the iSCSI layer MUST fail the iSCSI Login process or terminate the > connection as appropriate. See section 10.1.3.1 for details. > > If the RDMAExtensions key is negotiated to "Yes", the iSCSI Layer MUST > satisfy the following protocol usage requirements from the iSER protocol: > > 1. The iSCSI Layer at the initiator MUST set ExpDataSN = 0 in Task > Management Function Requests for Task Allegiance Reassignment for > read/bidirectional commands, so as to cause the target to send all > unacknowledged read data. > > 2. The iSCSI Layer at the target MUST always return the SCSI status > in a separate SCSI Response PDU for read commands, i.e., there MUST NOT be > a "phase collapse" in concluding a SCSI Read Command. > > 3. The iSCSI Layers at both the initiator and the target MUST support > the keys as defined in section 6 on Login/Text Operational Keys. If used > as specified, these keys MUST NOT be answered with NotUnderstood and the > semantics as defined MUST be followed for each iSER-assisted connection. > > 4. The iSCSI Layer at the initiator MUST NOT issue proactive (based > on time-outs) SNACKs for PDUs that it presumes are lost. > > --- end of replacement section 3.3 > > For section 8.4 (now section 8.1.2), if the iSER target wants to send a > Reject but couldn't do so because of the limits imposed by > MaxOutstandingUnexpectedPDUs, the PDU will be discarded. To the > initiator, this is similar to receiving a Reject PDU with a digest error. > Section 6.7 of RFC3720 states that "When an initiator receives any iSCSI > PDU with a payload digest error, it MUST discard the PDU." Furthermore, > "No further action is necessary for initiators if the discarded PDU is an > unsolicited PDU (e.g., Async, Reject). Task timeouts as in the initiator > waiting for a command completion, or process > timeouts, as in the target waiting for a Logout, will ensure that the > correct operational behavior will result in these cases despite the > discarded PDU." > > It is incumbent upon the initiator to declare a reasonable limit on > MaxOutstandingUnexpectedPDUs to avoid the situation where the target has > to discard a PDU due to lack of resources on the initiator's side. As > stated in section 8.1, shared buffer pools can always be used to minimize > the risk. I can modify the new text in section 8.1.2 as follows: > > "If the number of outstanding unexpected control-type PDUs equals > MaxOutstandingUnexpectedPDUs, the target will not be able to send another > unexpected control-type PDU until some outstanding ones have been retired. > In this case the unexpected PDU will be discarded and not sent by the > target. Task timeouts as in the initiator waiting for a command > completion, or process timeouts, as in the target waiting for a Logout, > will ensure that the correct operational behavior will result in these > cases despite the discarded PDU. > > (Implementation note: To ensure that the initiator has a means to inform > the target that outstanding PDUs have been retired, the target should > reserve ... with the current ExpStatSN.)" > > Mike > To: mako@almaden.ibm.com > cc: ips@ietf.org > Subject: RE: [Ips] WG Last Call Review: iSER > > > Mike, > > There are a couple of problems in what you propose: > > >>(3) Section 3.3., item 5. says "MUST successfully negotiate >>the TargetRecvDataSegmentLength key". Again there's a "takes >>two to negotiate" problem, and the "failed to successfully >>negotiate" case needs to be specified. >> >>[mk] The old items 4 and 5 are now replaced by the new item 4 >>with the following text: >> >>"The iSCSI Layers at both the initiator and the target MUST >>support the keys as defined in section 6 on Login/Text Operational Keys. >>If used as specified, these keys MUST NOT be answered with NotUnderstood >>and the semantics as defined MUST be followed for each iSER-assisted >>connection." > > > That would be ok for the case where there are iSER systems on both > ends of a connection, but your new text indirectly forbids connecting > an iSER implementation to a non-iSER one (i.e., Traditional iSCSI), > as this would violate the first MUST (at least one of the systems > will not support the new keys). This text (and all of the negotiation > text) needs to be rephrased to apply to a single system, and specify > requirements on that system - if iSER is to be used, then the following > keys MUST be offered or responded to in negotiation *and* if this > negotiation fails for any reason (e.g., a NotUnderstood response, or > lack of an offered key that would be necessary to use iSER), then > iSER MUST NOT be used, and traditional iSCSI is used instead. It > is important to specify the fallback-to-Traditional-iSCSI cases in > the negotiation requirements, as appealing to the covering "in order > to use iSER" text is not enough because it doesn't cover what happens > when negotiation fails. This needs to be done at least in Section 5.1 > also. > > >>(10) Section 8.4 could result in a situation where an iSER Target >>cannot send a Reject PDU that an iSCSI Target would be >>able send. It needs to explain what to do in that situation. >> >>[mk] The following text has been added in section 8.4: >>(Implementation note: If the number of outstanding unexpected >>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will > > not > > >>be able to send another unexpected control-type PDU until some > > outstanding > > >>ones have been retired. To ensure that the initiator has a means of >>retiring outstanding PDUs, the target should reserve the last unexpected >>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in >>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>initiator to return the NOP-out ping response with the >>current ExpStatSN.) > > > While that helps, it still doesn't respond to the comment's request to > explain what an iSER target should do when it wants to send a Reject PDU > but cannot due to this limitation. Is the target required to remember > the PDU that caused the reject until it gets enough space to send a > Reject? How much effort does it put into obtaining permission to send > the Reject before doing something else, and what is that something else? > > 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: Mike Ko [mailto:mako@almaden.ibm.com] >>Sent: Monday, June 13, 2005 1:10 AM >>To: Black_David@emc.com >>Cc: ips@ietf.org >>Subject: Re: [Ips] WG Last Call Review: iSER >> >>David, >> >>Thanks for the review. Please see my comments inline. >> >>Mike >>Sent by: ips-bounces@ietf.org >>To: ips@ietf.org >>cc: >>Subject: [Ips] WG Last Call Review: iSER >> >> >>I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, >>and in addition to editorial issues that I will send >>directly to Mike, I found a number of technical issues: >> >>(1) Section 3.3 has a structural problem in that the first >>sentence says "should satisfy" and the remaining sentences >>to be satisfied are expressed as "MUST" requirements. The >>net result is that all the requirements in that section are >>"should" requirements, which is not what was intended. >>The first sentence needs to be rewritten to say something >>to the effect of "In order to use iSER, the following MUST >>be done:" . >> >>[mk] ok >> >>(2) Section 3.3, item 1. says "MUST negotiate the >>RDMAExtensions key to "Yes" " Since the key is negotiated >>(not declared) and it takes two to negotiate, that requirement >>cannot be achieved by an implementation if the other side >>doesn't cooperate. This needs to be rewritten to talk about >>offering the key as "Yes" and replying as "Yes" and that >>if the result is not "Yes" then iSER is not used (traditional >>iSCSI is used instead). >> >>[mk] ok >> >>(3) Section 3.3., item 5. says "MUST successfully negotiate >>the TargetRecvDataSegmentLength key". Again there's a "takes >>two to negotiate" problem, and the "failed to successfully >>negotiate" case needs to be specified. >> >>[mk] The old items 4 and 5 are now replaced by the new item 4 >>with the >>follwowing text: >> >>"The iSCSI Layers at both the initiator and the target MUST >>support the >>keys as defined in section 6 on Login/Text Operational Keys. >>If used as >>specified, these keys MUST NOT be answered with NotUnderstood and the >>semantics as defined MUST be followed for each iSER-assisted >>connection." >> >>(4) Section 5.1, last two paragraphs have similar problems in >>that they specify required negotiation behavior without >>describing what to do when the other side doesn't cooperate >>or do what it is supposed to. Those failure cases need to >>be covered. >> >>[mk] The new text for comment #3 should address this issue. >> >>(5) Section 5.1.2, in the Note at the very end of the section >>about two steps needing to be atomic, "must" should be "MUST". >> >>[mk] ok >> >>(6) Section 5.1.3 is missing specification and explanation of >>version negotiation and version numbers in the iSER Hello >>Exchange. The error case instructions for when version >>negotiation fails need to be copied here in addition to their >>current location in Section 10.1.3.2 . >> >>[mk] ok >> >>(7) Section 7.3.9 - I believe sending of Login Request or Login >>Response in Datamover mode is always an error. This section >>should say so and say what to do about it. >> >>[mk] ok >> >>(8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling >>does not work because the instruction in 10.2.1 to handle SNACK >>as per RFC 3720 would require retransmission of non-existent >>Data and R2T PDUs. I can see a couple of possible corrective >>approaches: >>a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK >>PDUs (instead of the current SHOULD NOT) and change >>Section 10.2.1 to define reception of any SNACK PDU as >>an error. >>b) Put limits on what SNACK PDUs can be used to recover >>(Status only?) in Section 7.3.11, and modify Section >>10.2.1 to say how to recover that and what to do when >>a prohibited SNACK is received. >> >>[mk] The updated iSER draft will follow the suggestion in 8a. Also >>updated text in section 3.3 and section 8.3 on SNACK handling. >> >>(9) Section 8.1 uses the phrase "buffer underrun" for an "out >>of buffers" condition. That should be "buffer exhaustion". >> >>[mk] ok >> >>(10) Section 8.4 could result in a situation where an iSER Target >>cannot send a Reject PDU that an iSCSI Target would be >>able send. It needs to explain what to do in that situation. >> >>[mk] The following text has been added in section 8.4: >>(Implementation note: If the number of outstanding unexpected >>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the >>target will not >>be able to send another unexpected control-type PDU until >>some outstanding >>ones have been retired. To ensure that the initiator has a means of >>retiring outstanding PDUs, the target should reserve the last >>unexpected >>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as >>a NOP-in >>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>initiator to return the NOP-out ping response with the >>current ExpStatSN.) >> >>(11) Section 11 on Security Considerations is weak, but the >>overall approach of appealing to security considerations in >>other specifications is probably ok. This section needs to >>be strengthened by saying that since iSER is still functionally >>iSCSI, all of the iSCSI security considerations in RFC 3720 >>apply, and it should also reference the discussion of iSCSI >>security in RFC 3723. >> >>[mk] This section now references RFC3723 and the security >>drafts for RDDP. >> Both documents have also been added to the list of references. >> >>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 >>---------------------------------------------------- >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips >> >> > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 14 03:03:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di5Sc-0002mA-PE; Tue, 14 Jun 2005 03:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di5SZ-0002lv-JF; Tue, 14 Jun 2005 03:03:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16005; Tue, 14 Jun 2005 03:03:40 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di5ox-0007V1-GY; Tue, 14 Jun 2005 03:26:53 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5E73Umf192520; Tue, 14 Jun 2005 07:03:30 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5E73UrN185002; Tue, 14 Jun 2005 09:03:30 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5E73TCr017720; Tue, 14 Jun 2005 09:03:29 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j5E73Tfl017717; Tue, 14 Jun 2005 09:03:29 +0200 In-Reply-To: To: Hutchinson_Adam@emc.com Subject: Re: [Ips] iSCSI Login PDU in FFP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05032005NP May 03, 2005 From: Julian Satran Message-ID: Date: Tue, 14 Jun 2005 10:03:28 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 14/06/2005 10:03:28, Serialize complete at 14/06/2005 10:03:28 X-Spam-Score: 2.3 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ips@ietf.org, ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1834361363==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1834361363== Content-Type: text/html; charset="US-ASCII"
At least 2.5.3.2 states that Login Request and Response are used exclusively during login.

Julo


Hutchinson_Adam@emc.com
Sent by: ips-bounces@ietf.org

13/06/2005 22:44

To
ips@ietf.org
cc
Subject
[Ips] iSCSI Login PDU in FFP





Is it valid under any circumstances for an initiator to send a Login Request
PDU on a TCP connection that belongs to a full-feature iSCSI connection? I
believe it is implied by the initiator connection state machine that this
cannot happen, however, I don't recall see it clearly stated that Login PDUs
should only be sent during the Login phase.

Thanks,
Adam

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--===============1834361363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1834361363==-- From ips-bounces@ietf.org Tue Jun 14 11:06:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiD00-0007Ok-J1; Tue, 14 Jun 2005 11:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiCzy-0007Oc-K3 for ips@megatron.ietf.org; Tue, 14 Jun 2005 11:06:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24553 for ; Tue, 14 Jun 2005 11:06:40 -0400 (EDT) Received: from ccerelbas02.cce.hp.com ([161.114.21.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiDMU-0006fL-3l for ips@ietf.org; Tue, 14 Jun 2005 11:29:58 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 2385D2000979 for ; Tue, 14 Jun 2005 10:06:30 -0500 (CDT) Received: from cceexc17.americas.cpqcorp.net ([16.81.1.15]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 10:06:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Ips] New work item: iSCSI Implementer's Guide Date: Tue, 14 Jun 2005 10:06:29 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C60A1B5278@cceexc17.americas.cpqcorp.net> Thread-Topic: [Ips] New work item: iSCSI Implementer's Guide Thread-Index: AcVwU2fqgcU8JDc6StWMRIP+Oq+FIQAmYeDw From: "Elliott, Robert (Server Storage)" To: X-OriginalArrivalTime: 14 Jun 2005 15:06:30.0061 (UTC) FILETIME=[A4E22DD0:01C570F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org T10 has finished SAM-3 (ANSI INCITS 402-2005) and is wrapping up SPC-3. When (and how) should iSCSI be updated from its SAM-2 basis? Some changes to consider: * SCSI Command PDU: add Task Priority field * SCSI Command PDU ATTR field: make Untagged obsolete * Asynchronous Message: make SCSI Asynchronous Event Reporting obsolete * Task Management Function Request PDU: make TARGET RESET obsolete * Task Management Function Request PDU: add QUERY TASK * Task Management Function Response PDU Response field: add FUNCTION SUCCEEDED (for QUERY TASK or any other new function that wants to use it) SAM-4 is still in its early stages, but it includes a new feature that also warrants consideration: * SCSI Response PDU: add a Retry Delay field -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott =20 > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Black_David@emc.com > Sent: Monday, June 13, 2005 2:53 PM > To: ips@ietf.org > Subject: [Ips] New work item: iSCSI Implementer's Guide >=20 > Everyone, >=20 > The IPS WG has received Area Director approval to work on > an iSCSI Implementers Guide. This will be a standards > track draft (will become a Proposed Standard RFC) whose > purpose is to clarify and correct any problems in the > iSCSI RFC (RFC 3720). It is **not** a license to > revisit iSCSI design decisions, make major changes to > the iSCSI protocol or add major functionality to iSCSI, > although it may be a means to discourage implementation > of things that aren't in use (e.g., a sentence saying > that iSCSI markers SHOULD NOT be implemented would be > within reason). >=20 > I want to thank Mallikarjun for agreeing to edit this > draft. The initial version should be submitted with a > name of draft-ietf-ips-iscsi-impl-guide-00.txt or > something like that. >=20 > To a first approximation, the things that belong in > the implementers guide are things that an implementer wishes > s/he had known after first reading RFC 3720 ... but had > to learn/figure out the hard way. So far, we have two > topics for this draft: > - Update to task management function handling when multiple > tasks are to be terminated (Mallikarjun C.). > - Explanation of why REPORT LUNS command cannot cause an > iSCSI overrun (David B.). > If Eddy Q. comes up with a specific proposal to clarify > some error conditions that a target should not be REQUIRED > to check (and we agree to it), that could be a third topic. > Those who would like to see other topics covered should send > those suggestions to the list, but be aware than any suggestion > to cover a topic will be interpreted as an offer to write > text describing it ... >=20 > My initial intention is to hold this draft open for a while > so that we can pick up more issues as they arise - at the > moment, my thinking is to hold this open for at least a year. >=20 > 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 > ---------------------------------------------------- >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 14 13:06:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEsL-00078y-Oq; Tue, 14 Jun 2005 13:06:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEsJ-00078t-UA for ips@megatron.ietf.org; Tue, 14 Jun 2005 13:06:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04270 for ; Tue, 14 Jun 2005 13:06:52 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiFEp-0005zk-QL for ips@ietf.org; Tue, 14 Jun 2005 13:30:12 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5EH6bE3017613 for ; Tue, 14 Jun 2005 13:06:37 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5EH6bhh216370 for ; Tue, 14 Jun 2005 13:06:37 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5EH6bLH031543 for ; Tue, 14 Jun 2005 13:06:37 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5EH6b4k031538; Tue, 14 Jun 2005 13:06:37 -0400 In-Reply-To: <42AE32DE.2070204@rose.hp.com> Importance: Normal MIME-Version: 1.0 To: "Mallikarjun C." Subject: Re: [Ips] WG Last Call Review: iSER X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Tue, 14 Jun 2005 10:06:36 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_04122005|April 12, 2005) at 06/14/2005 13:06:36, Serialize complete at 06/14/2005 13:06:36 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, Thanks for your review. I have incorporated all of your suggestions in the iSER draft except for the revised text for section 8.1.2. I have some problem with the discarded PDU being treated as a lost PDU by the initiator. Since the target can always send the SCSI Response PDU (because it is expected and not bound by the MaxOutstandingUnexpectedPDUs limit), this will appear to the initiator as an out of order StatSN and section 6.8 of RFC3720 requires that "it MUST address the one or more missing status PDUs as described in Section 6.7 Digest Errors." In section 6.7 of RFC3720, if the initiator receives a PDU with a payload digest error, as long as there is no header digest error, the initiator need not take any action if the PDU is an unexpected PDU (e.g., Async, Reject). This is the desired result. But a lost PDU would appear as a header digest error and RFC3720 stipulates that the iSCSI layer can close the connection. This is not the desired result. In other words, the initiator can live with losing a Reject PDU if it knows it is a Reject PDU that is lost. Since the target knows that it is a Reject (or Async) PDU that it wants to send and it is the lack of buffer resources at the initiator that is preventing it from sending the PDU, a less destructive way of handling this corner case is to discard the PDU and NOT advance StatSN. So here is my suggested revised text for section 8.1.2: "If the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the iSCSI layer at the target will not be able to send another unexpected control-type PDU until some outstanding ones have been retired. In this case the the iSCSI layer at the target SHOULD discard the unexpected PDU and if the PDU is discarded, it SHOULD NOT advance StatSN. Task timeouts as in the initiator waiting for a command completion, will ensure that the correct operational behavior will result in these cases despite the discarded PDU." Mike Sent by: ips-bounces@ietf.org To: ips@ietf.org cc: Subject: Re: [Ips] WG Last Call Review: iSER Hi Mike, Some comments on the text discussed in this thread. 7.3.11 Get rid of " In particular, the Proactive (Time out) SNACK MUST NOT be issued." It is redundant now with the MUST NOT that precedes it. 3.3 (new replacement text) Change bullet 4 to: 4. The iSCSI Layer at the initiator MUST NOT issue SNACKs for PDUs. 8.1.2 (new text) Suggest changing the text to: "If the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target iSCSI layer will not be able to send another unexpected control-type PDU until some outstanding ones have been retired. In this case the the iSCSI layer SHOULD discard the unexpected PDU and allow the initiator iSCSI layer to respond to the resulting error (the discard in the target iSCSI layer manifests as as a lost PDU on the initiator). Task or sequence timeouts - as in the initiator waiting for a command completion - will ensure that the correct operational behavior will result in these cases despite the discarded PDU." 10.2.1 (new text) Suggest changing it to: "As described in section 7.3.11, SNACK PDUs are not used by the iSCSI Layer in the iSER-assisted mode." 11 (new text) Suggest changing it to: Since iSER-asisted iSCSI protocol is still functionally iSCSI from a security considerations perspective, all of the iSCSI security requirements as described in [RFC3720] and [RFC3723] apply. " Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mike Ko wrote: > David, > > On rereading section 3, bullet 1 should have been separated out from the > other bullets. Bullet 1 addressed the issue where an iSER implementation > attempts a connection with a non-iSER one, and it mandates that > iSER-assisted mode must not be used if RDMAExtensions is negotiated to > "No". But the remaining bullets deal with the situation assuming > RDMAExtensions have been negotiated to "Yes". If the connection is to > operate in iSER-assisted mode, then the rest of the bullets (except bullet > 1) must be followed. If any of the other bullets are not followed, then > the connection cannot really fall back to traditional iSCSI mode since > RDMAExtensions have been negotiated to "Yes". Not implementing those > other bullets in an iSER-assisted mode is an error. So here is the > proposed new text for section 3.3: > > --- start of replacement section 3.3 > To operate in an iSER-assisted mode, the iSCSI Layers at both the > initiator and the target MUST negotiate the RDMAExtensions key (see > section 6.3) to "Yes" on the leading connection. If the RDMAExtensions > key is not negotiated to "Yes", then iSER-assisted mode MUST NOT be used. > If the RDMAExtensons key is negotiated to "Yes" but the invocation of the > Allocate_Connection_Resources Operational Primitive to the iSER layer > fails, the iSCSI layer MUST fail the iSCSI Login process or terminate the > connection as appropriate. See section 10.1.3.1 for details. > > If the RDMAExtensions key is negotiated to "Yes", the iSCSI Layer MUST > satisfy the following protocol usage requirements from the iSER protocol: > > 1. The iSCSI Layer at the initiator MUST set ExpDataSN = 0 in Task > Management Function Requests for Task Allegiance Reassignment for > read/bidirectional commands, so as to cause the target to send all > unacknowledged read data. > > 2. The iSCSI Layer at the target MUST always return the SCSI status > in a separate SCSI Response PDU for read commands, i.e., there MUST NOT be > a "phase collapse" in concluding a SCSI Read Command. > > 3. The iSCSI Layers at both the initiator and the target MUST support > the keys as defined in section 6 on Login/Text Operational Keys. If used > as specified, these keys MUST NOT be answered with NotUnderstood and the > semantics as defined MUST be followed for each iSER-assisted connection. > > 4. The iSCSI Layer at the initiator MUST NOT issue proactive (based > on time-outs) SNACKs for PDUs that it presumes are lost. > > --- end of replacement section 3.3 > > For section 8.4 (now section 8.1.2), if the iSER target wants to send a > Reject but couldn't do so because of the limits imposed by > MaxOutstandingUnexpectedPDUs, the PDU will be discarded. To the > initiator, this is similar to receiving a Reject PDU with a digest error. > Section 6.7 of RFC3720 states that "When an initiator receives any iSCSI > PDU with a payload digest error, it MUST discard the PDU." Furthermore, > "No further action is necessary for initiators if the discarded PDU is an > unsolicited PDU (e.g., Async, Reject). Task timeouts as in the initiator > waiting for a command completion, or process > timeouts, as in the target waiting for a Logout, will ensure that the > correct operational behavior will result in these cases despite the > discarded PDU." > > It is incumbent upon the initiator to declare a reasonable limit on > MaxOutstandingUnexpectedPDUs to avoid the situation where the target has > to discard a PDU due to lack of resources on the initiator's side. As > stated in section 8.1, shared buffer pools can always be used to minimize > the risk. I can modify the new text in section 8.1.2 as follows: > > "If the number of outstanding unexpected control-type PDUs equals > MaxOutstandingUnexpectedPDUs, the target will not be able to send another > unexpected control-type PDU until some outstanding ones have been retired. > In this case the unexpected PDU will be discarded and not sent by the > target. Task timeouts as in the initiator waiting for a command > completion, or process timeouts, as in the target waiting for a Logout, > will ensure that the correct operational behavior will result in these > cases despite the discarded PDU. > > (Implementation note: To ensure that the initiator has a means to inform > the target that outstanding PDUs have been retired, the target should > reserve ... with the current ExpStatSN.)" > > Mike > To: mako@almaden.ibm.com > cc: ips@ietf.org > Subject: RE: [Ips] WG Last Call Review: iSER > > > Mike, > > There are a couple of problems in what you propose: > > >>(3) Section 3.3., item 5. says "MUST successfully negotiate >>the TargetRecvDataSegmentLength key". Again there's a "takes >>two to negotiate" problem, and the "failed to successfully >>negotiate" case needs to be specified. >> >>[mk] The old items 4 and 5 are now replaced by the new item 4 >>with the following text: >> >>"The iSCSI Layers at both the initiator and the target MUST >>support the keys as defined in section 6 on Login/Text Operational Keys. >>If used as specified, these keys MUST NOT be answered with NotUnderstood >>and the semantics as defined MUST be followed for each iSER-assisted >>connection." > > > That would be ok for the case where there are iSER systems on both > ends of a connection, but your new text indirectly forbids connecting > an iSER implementation to a non-iSER one (i.e., Traditional iSCSI), > as this would violate the first MUST (at least one of the systems > will not support the new keys). This text (and all of the negotiation > text) needs to be rephrased to apply to a single system, and specify > requirements on that system - if iSER is to be used, then the following > keys MUST be offered or responded to in negotiation *and* if this > negotiation fails for any reason (e.g., a NotUnderstood response, or > lack of an offered key that would be necessary to use iSER), then > iSER MUST NOT be used, and traditional iSCSI is used instead. It > is important to specify the fallback-to-Traditional-iSCSI cases in > the negotiation requirements, as appealing to the covering "in order > to use iSER" text is not enough because it doesn't cover what happens > when negotiation fails. This needs to be done at least in Section 5.1 > also. > > >>(10) Section 8.4 could result in a situation where an iSER Target >>cannot send a Reject PDU that an iSCSI Target would be >>able send. It needs to explain what to do in that situation. >> >>[mk] The following text has been added in section 8.4: >>(Implementation note: If the number of outstanding unexpected >>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will > > not > > >>be able to send another unexpected control-type PDU until some > > outstanding > > >>ones have been retired. To ensure that the initiator has a means of >>retiring outstanding PDUs, the target should reserve the last unexpected >>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in >>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>initiator to return the NOP-out ping response with the >>current ExpStatSN.) > > > While that helps, it still doesn't respond to the comment's request to > explain what an iSER target should do when it wants to send a Reject PDU > but cannot due to this limitation. Is the target required to remember > the PDU that caused the reject until it gets enough space to send a > Reject? How much effort does it put into obtaining permission to send > the Reject before doing something else, and what is that something else? > > 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: Mike Ko [mailto:mako@almaden.ibm.com] >>Sent: Monday, June 13, 2005 1:10 AM >>To: Black_David@emc.com >>Cc: ips@ietf.org >>Subject: Re: [Ips] WG Last Call Review: iSER >> >>David, >> >>Thanks for the review. Please see my comments inline. >> >>Mike >>Sent by: ips-bounces@ietf.org >>To: ips@ietf.org >>cc: >>Subject: [Ips] WG Last Call Review: iSER >> >> >>I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, >>and in addition to editorial issues that I will send >>directly to Mike, I found a number of technical issues: >> >>(1) Section 3.3 has a structural problem in that the first >>sentence says "should satisfy" and the remaining sentences >>to be satisfied are expressed as "MUST" requirements. The >>net result is that all the requirements in that section are >>"should" requirements, which is not what was intended. >>The first sentence needs to be rewritten to say something >>to the effect of "In order to use iSER, the following MUST >>be done:" . >> >>[mk] ok >> >>(2) Section 3.3, item 1. says "MUST negotiate the >>RDMAExtensions key to "Yes" " Since the key is negotiated >>(not declared) and it takes two to negotiate, that requirement >>cannot be achieved by an implementation if the other side >>doesn't cooperate. This needs to be rewritten to talk about >>offering the key as "Yes" and replying as "Yes" and that >>if the result is not "Yes" then iSER is not used (traditional >>iSCSI is used instead). >> >>[mk] ok >> >>(3) Section 3.3., item 5. says "MUST successfully negotiate >>the TargetRecvDataSegmentLength key". Again there's a "takes >>two to negotiate" problem, and the "failed to successfully >>negotiate" case needs to be specified. >> >>[mk] The old items 4 and 5 are now replaced by the new item 4 >>with the >>follwowing text: >> >>"The iSCSI Layers at both the initiator and the target MUST >>support the >>keys as defined in section 6 on Login/Text Operational Keys. >>If used as >>specified, these keys MUST NOT be answered with NotUnderstood and the >>semantics as defined MUST be followed for each iSER-assisted >>connection." >> >>(4) Section 5.1, last two paragraphs have similar problems in >>that they specify required negotiation behavior without >>describing what to do when the other side doesn't cooperate >>or do what it is supposed to. Those failure cases need to >>be covered. >> >>[mk] The new text for comment #3 should address this issue. >> >>(5) Section 5.1.2, in the Note at the very end of the section >>about two steps needing to be atomic, "must" should be "MUST". >> >>[mk] ok >> >>(6) Section 5.1.3 is missing specification and explanation of >>version negotiation and version numbers in the iSER Hello >>Exchange. The error case instructions for when version >>negotiation fails need to be copied here in addition to their >>current location in Section 10.1.3.2 . >> >>[mk] ok >> >>(7) Section 7.3.9 - I believe sending of Login Request or Login >>Response in Datamover mode is always an error. This section >>should say so and say what to do about it. >> >>[mk] ok >> >>(8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling >>does not work because the instruction in 10.2.1 to handle SNACK >>as per RFC 3720 would require retransmission of non-existent >>Data and R2T PDUs. I can see a couple of possible corrective >>approaches: >>a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK >>PDUs (instead of the current SHOULD NOT) and change >>Section 10.2.1 to define reception of any SNACK PDU as >>an error. >>b) Put limits on what SNACK PDUs can be used to recover >>(Status only?) in Section 7.3.11, and modify Section >>10.2.1 to say how to recover that and what to do when >>a prohibited SNACK is received. >> >>[mk] The updated iSER draft will follow the suggestion in 8a. Also >>updated text in section 3.3 and section 8.3 on SNACK handling. >> >>(9) Section 8.1 uses the phrase "buffer underrun" for an "out >>of buffers" condition. That should be "buffer exhaustion". >> >>[mk] ok >> >>(10) Section 8.4 could result in a situation where an iSER Target >>cannot send a Reject PDU that an iSCSI Target would be >>able send. It needs to explain what to do in that situation. >> >>[mk] The following text has been added in section 8.4: >>(Implementation note: If the number of outstanding unexpected >>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the >>target will not >>be able to send another unexpected control-type PDU until >>some outstanding >>ones have been retired. To ensure that the initiator has a means of >>retiring outstanding PDUs, the target should reserve the last >>unexpected >>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as >>a NOP-in >>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>initiator to return the NOP-out ping response with the >>current ExpStatSN.) >> >>(11) Section 11 on Security Considerations is weak, but the >>overall approach of appealing to security considerations in >>other specifications is probably ok. This section needs to >>be strengthened by saying that since iSER is still functionally >>iSCSI, all of the iSCSI security considerations in RFC 3720 >>apply, and it should also reference the discussion of iSCSI >>security in RFC 3723. >> >>[mk] This section now references RFC3723 and the security >>drafts for RDDP. >> Both documents have also been added to the list of references. >> >>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 >>---------------------------------------------------- >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips >> >> > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 14 13:15:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiF0X-0000S6-PC; Tue, 14 Jun 2005 13:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiF0W-0000Rf-Lz for ips@megatron.ietf.org; Tue, 14 Jun 2005 13:15:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05291 for ; Tue, 14 Jun 2005 13:15:21 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiFN2-0006bg-U3 for ips@ietf.org; Tue, 14 Jun 2005 13:38:41 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5EHFAFK015747 for ; Tue, 14 Jun 2005 13:15:10 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5EHFAhh226862 for ; Tue, 14 Jun 2005 13:15:10 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5EHFANY028598 for ; Tue, 14 Jun 2005 13:15:10 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5EHFA7T028593; Tue, 14 Jun 2005 13:15:10 -0400 In-Reply-To: Importance: Normal MIME-Version: 1.0 To: Mike Ko Subject: Re: [Ips] WG Last Call Review: iSER X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Tue, 14 Jun 2005 10:15:09 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_04122005|April 12, 2005) at 06/14/2005 13:15:09, Serialize complete at 06/14/2005 13:15:09 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff Cc: ips@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, Should change "SHOULD NOT advance StatSN" to "MUST NOT advance StatSN". Mike Sent by: ips-bounces@ietf.org To: "Mallikarjun C." cc: ips@ietf.org Subject: Re: [Ips] WG Last Call Review: iSER Mallikarjun, Thanks for your review. I have incorporated all of your suggestions in the iSER draft except for the revised text for section 8.1.2. I have some problem with the discarded PDU being treated as a lost PDU by the initiator. Since the target can always send the SCSI Response PDU (because it is expected and not bound by the MaxOutstandingUnexpectedPDUs limit), this will appear to the initiator as an out of order StatSN and section 6.8 of RFC3720 requires that "it MUST address the one or more missing status PDUs as described in Section 6.7 Digest Errors." In section 6.7 of RFC3720, if the initiator receives a PDU with a payload digest error, as long as there is no header digest error, the initiator need not take any action if the PDU is an unexpected PDU (e.g., Async, Reject). This is the desired result. But a lost PDU would appear as a header digest error and RFC3720 stipulates that the iSCSI layer can close the connection. This is not the desired result. In other words, the initiator can live with losing a Reject PDU if it knows it is a Reject PDU that is lost. Since the target knows that it is a Reject (or Async) PDU that it wants to send and it is the lack of buffer resources at the initiator that is preventing it from sending the PDU, a less destructive way of handling this corner case is to discard the PDU and NOT advance StatSN. So here is my suggested revised text for section 8.1.2: "If the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the iSCSI layer at the target will not be able to send another unexpected control-type PDU until some outstanding ones have been retired. In this case the the iSCSI layer at the target SHOULD discard the unexpected PDU and if the PDU is discarded, it SHOULD NOT advance StatSN. Task timeouts as in the initiator waiting for a command completion, will ensure that the correct operational behavior will result in these cases despite the discarded PDU." Mike Sent by: ips-bounces@ietf.org To: ips@ietf.org cc: Subject: Re: [Ips] WG Last Call Review: iSER Hi Mike, Some comments on the text discussed in this thread. 7.3.11 Get rid of " In particular, the Proactive (Time out) SNACK MUST NOT be issued." It is redundant now with the MUST NOT that precedes it. 3.3 (new replacement text) Change bullet 4 to: 4. The iSCSI Layer at the initiator MUST NOT issue SNACKs for PDUs. 8.1.2 (new text) Suggest changing the text to: "If the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target iSCSI layer will not be able to send another unexpected control-type PDU until some outstanding ones have been retired. In this case the the iSCSI layer SHOULD discard the unexpected PDU and allow the initiator iSCSI layer to respond to the resulting error (the discard in the target iSCSI layer manifests as as a lost PDU on the initiator). Task or sequence timeouts - as in the initiator waiting for a command completion - will ensure that the correct operational behavior will result in these cases despite the discarded PDU." 10.2.1 (new text) Suggest changing it to: "As described in section 7.3.11, SNACK PDUs are not used by the iSCSI Layer in the iSER-assisted mode." 11 (new text) Suggest changing it to: Since iSER-asisted iSCSI protocol is still functionally iSCSI from a security considerations perspective, all of the iSCSI security requirements as described in [RFC3720] and [RFC3723] apply. " Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mike Ko wrote: > David, > > On rereading section 3, bullet 1 should have been separated out from the > other bullets. Bullet 1 addressed the issue where an iSER implementation > attempts a connection with a non-iSER one, and it mandates that > iSER-assisted mode must not be used if RDMAExtensions is negotiated to > "No". But the remaining bullets deal with the situation assuming > RDMAExtensions have been negotiated to "Yes". If the connection is to > operate in iSER-assisted mode, then the rest of the bullets (except bullet > 1) must be followed. If any of the other bullets are not followed, then > the connection cannot really fall back to traditional iSCSI mode since > RDMAExtensions have been negotiated to "Yes". Not implementing those > other bullets in an iSER-assisted mode is an error. So here is the > proposed new text for section 3.3: > > --- start of replacement section 3.3 > To operate in an iSER-assisted mode, the iSCSI Layers at both the > initiator and the target MUST negotiate the RDMAExtensions key (see > section 6.3) to "Yes" on the leading connection. If the RDMAExtensions > key is not negotiated to "Yes", then iSER-assisted mode MUST NOT be used. > If the RDMAExtensons key is negotiated to "Yes" but the invocation of the > Allocate_Connection_Resources Operational Primitive to the iSER layer > fails, the iSCSI layer MUST fail the iSCSI Login process or terminate the > connection as appropriate. See section 10.1.3.1 for details. > > If the RDMAExtensions key is negotiated to "Yes", the iSCSI Layer MUST > satisfy the following protocol usage requirements from the iSER protocol: > > 1. The iSCSI Layer at the initiator MUST set ExpDataSN = 0 in Task > Management Function Requests for Task Allegiance Reassignment for > read/bidirectional commands, so as to cause the target to send all > unacknowledged read data. > > 2. The iSCSI Layer at the target MUST always return the SCSI status > in a separate SCSI Response PDU for read commands, i.e., there MUST NOT be > a "phase collapse" in concluding a SCSI Read Command. > > 3. The iSCSI Layers at both the initiator and the target MUST support > the keys as defined in section 6 on Login/Text Operational Keys. If used > as specified, these keys MUST NOT be answered with NotUnderstood and the > semantics as defined MUST be followed for each iSER-assisted connection. > > 4. The iSCSI Layer at the initiator MUST NOT issue proactive (based > on time-outs) SNACKs for PDUs that it presumes are lost. > > --- end of replacement section 3.3 > > For section 8.4 (now section 8.1.2), if the iSER target wants to send a > Reject but couldn't do so because of the limits imposed by > MaxOutstandingUnexpectedPDUs, the PDU will be discarded. To the > initiator, this is similar to receiving a Reject PDU with a digest error. > Section 6.7 of RFC3720 states that "When an initiator receives any iSCSI > PDU with a payload digest error, it MUST discard the PDU." Furthermore, > "No further action is necessary for initiators if the discarded PDU is an > unsolicited PDU (e.g., Async, Reject). Task timeouts as in the initiator > waiting for a command completion, or process > timeouts, as in the target waiting for a Logout, will ensure that the > correct operational behavior will result in these cases despite the > discarded PDU." > > It is incumbent upon the initiator to declare a reasonable limit on > MaxOutstandingUnexpectedPDUs to avoid the situation where the target has > to discard a PDU due to lack of resources on the initiator's side. As > stated in section 8.1, shared buffer pools can always be used to minimize > the risk. I can modify the new text in section 8.1.2 as follows: > > "If the number of outstanding unexpected control-type PDUs equals > MaxOutstandingUnexpectedPDUs, the target will not be able to send another > unexpected control-type PDU until some outstanding ones have been retired. > In this case the unexpected PDU will be discarded and not sent by the > target. Task timeouts as in the initiator waiting for a command > completion, or process timeouts, as in the target waiting for a Logout, > will ensure that the correct operational behavior will result in these > cases despite the discarded PDU. > > (Implementation note: To ensure that the initiator has a means to inform > the target that outstanding PDUs have been retired, the target should > reserve ... with the current ExpStatSN.)" > > Mike > To: mako@almaden.ibm.com > cc: ips@ietf.org > Subject: RE: [Ips] WG Last Call Review: iSER > > > Mike, > > There are a couple of problems in what you propose: > > >>(3) Section 3.3., item 5. says "MUST successfully negotiate >>the TargetRecvDataSegmentLength key". Again there's a "takes >>two to negotiate" problem, and the "failed to successfully >>negotiate" case needs to be specified. >> >>[mk] The old items 4 and 5 are now replaced by the new item 4 >>with the following text: >> >>"The iSCSI Layers at both the initiator and the target MUST >>support the keys as defined in section 6 on Login/Text Operational Keys. >>If used as specified, these keys MUST NOT be answered with NotUnderstood >>and the semantics as defined MUST be followed for each iSER-assisted >>connection." > > > That would be ok for the case where there are iSER systems on both > ends of a connection, but your new text indirectly forbids connecting > an iSER implementation to a non-iSER one (i.e., Traditional iSCSI), > as this would violate the first MUST (at least one of the systems > will not support the new keys). This text (and all of the negotiation > text) needs to be rephrased to apply to a single system, and specify > requirements on that system - if iSER is to be used, then the following > keys MUST be offered or responded to in negotiation *and* if this > negotiation fails for any reason (e.g., a NotUnderstood response, or > lack of an offered key that would be necessary to use iSER), then > iSER MUST NOT be used, and traditional iSCSI is used instead. It > is important to specify the fallback-to-Traditional-iSCSI cases in > the negotiation requirements, as appealing to the covering "in order > to use iSER" text is not enough because it doesn't cover what happens > when negotiation fails. This needs to be done at least in Section 5.1 > also. > > >>(10) Section 8.4 could result in a situation where an iSER Target >>cannot send a Reject PDU that an iSCSI Target would be >>able send. It needs to explain what to do in that situation. >> >>[mk] The following text has been added in section 8.4: >>(Implementation note: If the number of outstanding unexpected >>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will > > not > > >>be able to send another unexpected control-type PDU until some > > outstanding > > >>ones have been retired. To ensure that the initiator has a means of >>retiring outstanding PDUs, the target should reserve the last unexpected >>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in >>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>initiator to return the NOP-out ping response with the >>current ExpStatSN.) > > > While that helps, it still doesn't respond to the comment's request to > explain what an iSER target should do when it wants to send a Reject PDU > but cannot due to this limitation. Is the target required to remember > the PDU that caused the reject until it gets enough space to send a > Reject? How much effort does it put into obtaining permission to send > the Reject before doing something else, and what is that something else? > > 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: Mike Ko [mailto:mako@almaden.ibm.com] >>Sent: Monday, June 13, 2005 1:10 AM >>To: Black_David@emc.com >>Cc: ips@ietf.org >>Subject: Re: [Ips] WG Last Call Review: iSER >> >>David, >> >>Thanks for the review. Please see my comments inline. >> >>Mike >>Sent by: ips-bounces@ietf.org >>To: ips@ietf.org >>cc: >>Subject: [Ips] WG Last Call Review: iSER >> >> >>I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, >>and in addition to editorial issues that I will send >>directly to Mike, I found a number of technical issues: >> >>(1) Section 3.3 has a structural problem in that the first >>sentence says "should satisfy" and the remaining sentences >>to be satisfied are expressed as "MUST" requirements. The >>net result is that all the requirements in that section are >>"should" requirements, which is not what was intended. >>The first sentence needs to be rewritten to say something >>to the effect of "In order to use iSER, the following MUST >>be done:" . >> >>[mk] ok >> >>(2) Section 3.3, item 1. says "MUST negotiate the >>RDMAExtensions key to "Yes" " Since the key is negotiated >>(not declared) and it takes two to negotiate, that requirement >>cannot be achieved by an implementation if the other side >>doesn't cooperate. This needs to be rewritten to talk about >>offering the key as "Yes" and replying as "Yes" and that >>if the result is not "Yes" then iSER is not used (traditional >>iSCSI is used instead). >> >>[mk] ok >> >>(3) Section 3.3., item 5. says "MUST successfully negotiate >>the TargetRecvDataSegmentLength key". Again there's a "takes >>two to negotiate" problem, and the "failed to successfully >>negotiate" case needs to be specified. >> >>[mk] The old items 4 and 5 are now replaced by the new item 4 >>with the >>follwowing text: >> >>"The iSCSI Layers at both the initiator and the target MUST >>support the >>keys as defined in section 6 on Login/Text Operational Keys. >>If used as >>specified, these keys MUST NOT be answered with NotUnderstood and the >>semantics as defined MUST be followed for each iSER-assisted >>connection." >> >>(4) Section 5.1, last two paragraphs have similar problems in >>that they specify required negotiation behavior without >>describing what to do when the other side doesn't cooperate >>or do what it is supposed to. Those failure cases need to >>be covered. >> >>[mk] The new text for comment #3 should address this issue. >> >>(5) Section 5.1.2, in the Note at the very end of the section >>about two steps needing to be atomic, "must" should be "MUST". >> >>[mk] ok >> >>(6) Section 5.1.3 is missing specification and explanation of >>version negotiation and version numbers in the iSER Hello >>Exchange. The error case instructions for when version >>negotiation fails need to be copied here in addition to their >>current location in Section 10.1.3.2 . >> >>[mk] ok >> >>(7) Section 7.3.9 - I believe sending of Login Request or Login >>Response in Datamover mode is always an error. This section >>should say so and say what to do about it. >> >>[mk] ok >> >>(8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling >>does not work because the instruction in 10.2.1 to handle SNACK >>as per RFC 3720 would require retransmission of non-existent >>Data and R2T PDUs. I can see a couple of possible corrective >>approaches: >>a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK >>PDUs (instead of the current SHOULD NOT) and change >>Section 10.2.1 to define reception of any SNACK PDU as >>an error. >>b) Put limits on what SNACK PDUs can be used to recover >>(Status only?) in Section 7.3.11, and modify Section >>10.2.1 to say how to recover that and what to do when >>a prohibited SNACK is received. >> >>[mk] The updated iSER draft will follow the suggestion in 8a. Also >>updated text in section 3.3 and section 8.3 on SNACK handling. >> >>(9) Section 8.1 uses the phrase "buffer underrun" for an "out >>of buffers" condition. That should be "buffer exhaustion". >> >>[mk] ok >> >>(10) Section 8.4 could result in a situation where an iSER Target >>cannot send a Reject PDU that an iSCSI Target would be >>able send. It needs to explain what to do in that situation. >> >>[mk] The following text has been added in section 8.4: >>(Implementation note: If the number of outstanding unexpected >>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the >>target will not >>be able to send another unexpected control-type PDU until >>some outstanding >>ones have been retired. To ensure that the initiator has a means of >>retiring outstanding PDUs, the target should reserve the last >>unexpected >>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as >>a NOP-in >>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>initiator to return the NOP-out ping response with the >>current ExpStatSN.) >> >>(11) Section 11 on Security Considerations is weak, but the >>overall approach of appealing to security considerations in >>other specifications is probably ok. This section needs to >>be strengthened by saying that since iSER is still functionally >>iSCSI, all of the iSCSI security considerations in RFC 3720 >>apply, and it should also reference the discussion of iSCSI >>security in RFC 3723. >> >>[mk] This section now references RFC3723 and the security >>drafts for RDDP. >> Both documents have also been added to the list of references. >> >>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 >>---------------------------------------------------- >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips >> >> > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 14 14:57:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiGb2-0002kY-Fr; Tue, 14 Jun 2005 14:57:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiGaz-0002hO-Dl for ips@megatron.ietf.org; Tue, 14 Jun 2005 14:57:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18508 for ; Tue, 14 Jun 2005 14:57:08 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiGxW-0007Cm-5O for ips@ietf.org; Tue, 14 Jun 2005 15:20:27 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id BBE63402561; Tue, 14 Jun 2005 11:57:02 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id 608E3805A; Tue, 14 Jun 2005 11:51:48 -0700 (PDT) Message-ID: <42AF2882.9020103@rose.hp.com> Date: Tue, 14 Jun 2005 11:57:06 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Ko Subject: Re: [Ips] WG Last Call Review: iSER References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 81ca0cebdb446e1ff4e2b634791f24a9 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mike, >In > section 6.7 of RFC3720, if the initiator receives a PDU with a payload > digest error, as long as there is no header digest error, the initiator > need not take any action if the PDU is an unexpected PDU (e.g., Async, > Reject). You may have discovered a piece of somewhat misleading text for the implementer's guide. The 6.7 text clearly says that the PDU with a payload digest error must be discarded - the StatSN of a discarded PDU must not be considered as received. This is analogous to the target throwing away the entire command PDU (including the CmdSN) even when there's a payload digest error on the immediate data (6.7 describes this case as well). OTOH, I see that the "no further action is necessary" piece of text is misleading at best, since it could imply that no status SNACKs are necessary when in fact they are. I am adding it to my to-do list for the new draft. >Since the target knows that it is a Reject (or Async) PDU > that it wants to send and it is the lack of buffer resources at the > initiator that is preventing it from sending the PDU, a less destructive > way of handling this corner case is to discard the PDU and NOT advance > StatSN. I am inclined to suggest that we make no exceptions to cover for a seriously corner case, making implementations' life even more complex. At this point, I think there are two legitimate Options for the iSCSI Layer to deal with this corner case - A) Do not generate any unexpected PDUs if there's no currently available credit. B) Generate the PDU as always. (i) Wait for the credit to become available. (ii) Don't wait, discard the generated PDU immediately. (iii) A combination thereof, wait for sometime and discard based on implementation considerations, e.g. resource pressure. IMHO, Option A should never consume a StatSN and Option B (all its sub-cases) should always consume a StatSN. I prefer this approach because in an Option B implementation, depending on the implementation, the next target-to-initiator PDU "in the line" may have already taken the "next number" of StatSN. In the replacement text I suggested earlier, I was leaning towards "B-(ii) with StatSN consumed" semantics. Rethinking this now, I see that there are wire protocol implications depending on the Option. One can argue that A is better, and I'd be personally agreeable to it. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mike Ko wrote: > Mallikarjun, > > Should change "SHOULD NOT advance StatSN" to "MUST NOT advance StatSN". > > Mike > Sent by: ips-bounces@ietf.org > To: "Mallikarjun C." > cc: ips@ietf.org > Subject: Re: [Ips] WG Last Call Review: iSER > > > Mallikarjun, > > Thanks for your review. I have incorporated all of your suggestions in > the iSER draft except for the revised text for section 8.1.2. I have some > problem with the discarded PDU being treated as a lost PDU by the > initiator. Since the target can always send the SCSI Response PDU > (because it is expected and not bound by the MaxOutstandingUnexpectedPDUs > limit), this will appear to the initiator as an out of order StatSN and > section 6.8 of RFC3720 requires that "it MUST address the one or more > missing status PDUs as described in Section 6.7 Digest Errors." In > section 6.7 of RFC3720, if the initiator receives a PDU with a payload > digest error, as long as there is no header digest error, the initiator > need not take any action if the PDU is an unexpected PDU (e.g., Async, > Reject). This is the desired result. But a lost PDU would appear as a > header digest error and RFC3720 stipulates that the iSCSI layer can close > the connection. This is not the desired result. In other words, the > initiator can live with losing a Reject PDU if it knows it is a Reject PDU > that is lost. Since the target knows that it is a Reject (or Async) PDU > that it wants to send and it is the lack of buffer resources at the > initiator that is preventing it from sending the PDU, a less destructive > way of handling this corner case is to discard the PDU and NOT advance > StatSN. So here is my suggested revised text for section 8.1.2: > > "If the number of outstanding unexpected control-type PDUs equals > MaxOutstandingUnexpectedPDUs, the iSCSI layer at the target will not be > able to send another unexpected control-type PDU until some outstanding > ones have been retired. In this case the the iSCSI layer at the target > SHOULD discard the unexpected PDU and if the PDU is discarded, it SHOULD > NOT advance StatSN. Task timeouts as in the initiator waiting for a > command completion, will ensure that the correct operational behavior will > result in these cases despite the discarded PDU." > > Mike > Sent by: ips-bounces@ietf.org > To: ips@ietf.org > cc: > Subject: Re: [Ips] WG Last Call Review: iSER > > > Hi Mike, > > Some comments on the text discussed in this thread. > > 7.3.11 > > Get rid of " In particular, the Proactive (Time out) SNACK MUST NOT be > issued." It is redundant now with the MUST NOT that precedes it. > > > 3.3 (new replacement text) > > Change bullet 4 to: > > 4. The iSCSI Layer at the initiator MUST NOT issue SNACKs for PDUs. > > > 8.1.2 (new text) > > Suggest changing the text to: > > "If the number of outstanding unexpected control-type PDUs equals > MaxOutstandingUnexpectedPDUs, the target iSCSI layer will not be > able to send another unexpected control-type PDU until some outstanding > ones have been retired. In this case the the iSCSI layer SHOULD > discard the unexpected PDU and allow the initiator iSCSI layer > to respond to the resulting error (the discard in the target iSCSI > layer manifests as as a lost PDU on the initiator). Task or sequence > timeouts - as in the initiator waiting for a command completion - > will ensure that the correct operational behavior will result in these > cases despite the discarded PDU." > > 10.2.1 (new text) > > Suggest changing it to: > "As described in section 7.3.11, SNACK PDUs are not used by the iSCSI > Layer in the iSER-assisted mode." > > 11 (new text) > > Suggest changing it to: > Since iSER-asisted iSCSI protocol is still functionally iSCSI from a > security considerations perspective, all of the iSCSI security > requirements as described in [RFC3720] and [RFC3723] apply. " > > > Thanks. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Mike Ko wrote: > >>David, >> >>On rereading section 3, bullet 1 should have been separated out from the >>other bullets. Bullet 1 addressed the issue where an iSER > > implementation > >>attempts a connection with a non-iSER one, and it mandates that >>iSER-assisted mode must not be used if RDMAExtensions is negotiated to >>"No". But the remaining bullets deal with the situation assuming >>RDMAExtensions have been negotiated to "Yes". If the connection is to >>operate in iSER-assisted mode, then the rest of the bullets (except > > bullet > >>1) must be followed. If any of the other bullets are not followed, then >>the connection cannot really fall back to traditional iSCSI mode since >>RDMAExtensions have been negotiated to "Yes". Not implementing those >>other bullets in an iSER-assisted mode is an error. So here is the >>proposed new text for section 3.3: >> >>--- start of replacement section 3.3 >>To operate in an iSER-assisted mode, the iSCSI Layers at both the >>initiator and the target MUST negotiate the RDMAExtensions key (see >>section 6.3) to "Yes" on the leading connection. If the RDMAExtensions >>key is not negotiated to "Yes", then iSER-assisted mode MUST NOT be > > used. > >>If the RDMAExtensons key is negotiated to "Yes" but the invocation of > > the > >>Allocate_Connection_Resources Operational Primitive to the iSER layer >>fails, the iSCSI layer MUST fail the iSCSI Login process or terminate > > the > >>connection as appropriate. See section 10.1.3.1 for details. >> >>If the RDMAExtensions key is negotiated to "Yes", the iSCSI Layer MUST >>satisfy the following protocol usage requirements from the iSER > > protocol: > >>1. The iSCSI Layer at the initiator MUST set ExpDataSN = 0 in Task >>Management Function Requests for Task Allegiance Reassignment for >>read/bidirectional commands, so as to cause the target to send all >>unacknowledged read data. >> >>2. The iSCSI Layer at the target MUST always return the SCSI status >>in a separate SCSI Response PDU for read commands, i.e., there MUST NOT > > be > >>a "phase collapse" in concluding a SCSI Read Command. >> >>3. The iSCSI Layers at both the initiator and the target MUST > > support > >>the keys as defined in section 6 on Login/Text Operational Keys. If > > used > >>as specified, these keys MUST NOT be answered with NotUnderstood and the >>semantics as defined MUST be followed for each iSER-assisted connection. >> >>4. The iSCSI Layer at the initiator MUST NOT issue proactive (based >>on time-outs) SNACKs for PDUs that it presumes are lost. >> >>--- end of replacement section 3.3 >> >>For section 8.4 (now section 8.1.2), if the iSER target wants to send a >>Reject but couldn't do so because of the limits imposed by >>MaxOutstandingUnexpectedPDUs, the PDU will be discarded. To the >>initiator, this is similar to receiving a Reject PDU with a digest > > error. > >>Section 6.7 of RFC3720 states that "When an initiator receives any iSCSI >>PDU with a payload digest error, it MUST discard the PDU." Furthermore, >>"No further action is necessary for initiators if the discarded PDU is > > an > >>unsolicited PDU (e.g., Async, Reject). Task timeouts as in the > > initiator > >>waiting for a command completion, or process >>timeouts, as in the target waiting for a Logout, will ensure that the >>correct operational behavior will result in these cases despite the >>discarded PDU." >> >>It is incumbent upon the initiator to declare a reasonable limit on >>MaxOutstandingUnexpectedPDUs to avoid the situation where the target has >>to discard a PDU due to lack of resources on the initiator's side. As >>stated in section 8.1, shared buffer pools can always be used to > > minimize > >>the risk. I can modify the new text in section 8.1.2 as follows: >> >>"If the number of outstanding unexpected control-type PDUs equals >>MaxOutstandingUnexpectedPDUs, the target will not be able to send > > another > >>unexpected control-type PDU until some outstanding ones have been > > retired. > >> In this case the unexpected PDU will be discarded and not sent by the >>target. Task timeouts as in the initiator waiting for a command >>completion, or process timeouts, as in the target waiting for a Logout, >>will ensure that the correct operational behavior will result in these >>cases despite the discarded PDU. >> >>(Implementation note: To ensure that the initiator has a means to > > inform > >>the target that outstanding PDUs have been retired, the target should >>reserve ... with the current ExpStatSN.)" >> >>Mike >>To: mako@almaden.ibm.com >>cc: ips@ietf.org >>Subject: RE: [Ips] WG Last Call Review: iSER >> >> >>Mike, >> >>There are a couple of problems in what you propose: >> >> >> >>>(3) Section 3.3., item 5. says "MUST successfully negotiate >>>the TargetRecvDataSegmentLength key". Again there's a "takes >>>two to negotiate" problem, and the "failed to successfully >>>negotiate" case needs to be specified. >>> >>>[mk] The old items 4 and 5 are now replaced by the new item 4 >>>with the following text: >>> >>>"The iSCSI Layers at both the initiator and the target MUST >>>support the keys as defined in section 6 on Login/Text Operational Keys. >>>If used as specified, these keys MUST NOT be answered with NotUnderstood >>>and the semantics as defined MUST be followed for each iSER-assisted >>>connection." >> >> >>That would be ok for the case where there are iSER systems on both >>ends of a connection, but your new text indirectly forbids connecting >>an iSER implementation to a non-iSER one (i.e., Traditional iSCSI), >>as this would violate the first MUST (at least one of the systems >>will not support the new keys). This text (and all of the negotiation >>text) needs to be rephrased to apply to a single system, and specify >>requirements on that system - if iSER is to be used, then the following >>keys MUST be offered or responded to in negotiation *and* if this >>negotiation fails for any reason (e.g., a NotUnderstood response, or >>lack of an offered key that would be necessary to use iSER), then >>iSER MUST NOT be used, and traditional iSCSI is used instead. It >>is important to specify the fallback-to-Traditional-iSCSI cases in >>the negotiation requirements, as appealing to the covering "in order >>to use iSER" text is not enough because it doesn't cover what happens >>when negotiation fails. This needs to be done at least in Section 5.1 >>also. >> >> >> >>>(10) Section 8.4 could result in a situation where an iSER Target >>>cannot send a Reject PDU that an iSCSI Target would be >>>able send. It needs to explain what to do in that situation. >>> >>>[mk] The following text has been added in section 8.4: >>>(Implementation note: If the number of outstanding unexpected >>>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will >> >>not >> >> >> >>>be able to send another unexpected control-type PDU until some >> >>outstanding >> >> >> >>>ones have been retired. To ensure that the initiator has a means of >>>retiring outstanding PDUs, the target should reserve the last unexpected >>>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in >>>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>>initiator to return the NOP-out ping response with the >>>current ExpStatSN.) >> >> >>While that helps, it still doesn't respond to the comment's request to >>explain what an iSER target should do when it wants to send a Reject PDU >>but cannot due to this limitation. Is the target required to remember >>the PDU that caused the reject until it gets enough space to send a >>Reject? How much effort does it put into obtaining permission to send >>the Reject before doing something else, and what is that something else? >> >>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: Mike Ko [mailto:mako@almaden.ibm.com] >>>Sent: Monday, June 13, 2005 1:10 AM >>>To: Black_David@emc.com >>>Cc: ips@ietf.org >>>Subject: Re: [Ips] WG Last Call Review: iSER >>> >>>David, >>> >>>Thanks for the review. Please see my comments inline. >>> >>>Mike >>>Sent by: ips-bounces@ietf.org >>>To: ips@ietf.org >>>cc: >>>Subject: [Ips] WG Last Call Review: iSER >>> >>> >>>I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, >>>and in addition to editorial issues that I will send >>>directly to Mike, I found a number of technical issues: >>> >>>(1) Section 3.3 has a structural problem in that the first >>>sentence says "should satisfy" and the remaining sentences >>>to be satisfied are expressed as "MUST" requirements. The >>>net result is that all the requirements in that section are >>>"should" requirements, which is not what was intended. >>>The first sentence needs to be rewritten to say something >>>to the effect of "In order to use iSER, the following MUST >>>be done:" . >>> >>>[mk] ok >>> >>>(2) Section 3.3, item 1. says "MUST negotiate the >>>RDMAExtensions key to "Yes" " Since the key is negotiated >>>(not declared) and it takes two to negotiate, that requirement >>>cannot be achieved by an implementation if the other side >>>doesn't cooperate. This needs to be rewritten to talk about >>>offering the key as "Yes" and replying as "Yes" and that >>>if the result is not "Yes" then iSER is not used (traditional >>>iSCSI is used instead). >>> >>>[mk] ok >>> >>>(3) Section 3.3., item 5. says "MUST successfully negotiate >>>the TargetRecvDataSegmentLength key". Again there's a "takes >>>two to negotiate" problem, and the "failed to successfully >>>negotiate" case needs to be specified. >>> >>>[mk] The old items 4 and 5 are now replaced by the new item 4 >>>with the >>>follwowing text: >>> >>>"The iSCSI Layers at both the initiator and the target MUST >>>support the >>>keys as defined in section 6 on Login/Text Operational Keys. >>>If used as >>>specified, these keys MUST NOT be answered with NotUnderstood and the >>>semantics as defined MUST be followed for each iSER-assisted >>>connection." >>> >>>(4) Section 5.1, last two paragraphs have similar problems in >>>that they specify required negotiation behavior without >>>describing what to do when the other side doesn't cooperate >>>or do what it is supposed to. Those failure cases need to >>>be covered. >>> >>>[mk] The new text for comment #3 should address this issue. >>> >>>(5) Section 5.1.2, in the Note at the very end of the section >>>about two steps needing to be atomic, "must" should be "MUST". >>> >>>[mk] ok >>> >>>(6) Section 5.1.3 is missing specification and explanation of >>>version negotiation and version numbers in the iSER Hello >>>Exchange. The error case instructions for when version >>>negotiation fails need to be copied here in addition to their >>>current location in Section 10.1.3.2 . >>> >>>[mk] ok >>> >>>(7) Section 7.3.9 - I believe sending of Login Request or Login >>>Response in Datamover mode is always an error. This section >>>should say so and say what to do about it. >>> >>>[mk] ok >>> >>>(8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling >>>does not work because the instruction in 10.2.1 to handle SNACK >>>as per RFC 3720 would require retransmission of non-existent >>>Data and R2T PDUs. I can see a couple of possible corrective >>>approaches: >>>a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK >>>PDUs (instead of the current SHOULD NOT) and change >>>Section 10.2.1 to define reception of any SNACK PDU as >>>an error. >>>b) Put limits on what SNACK PDUs can be used to recover >>>(Status only?) in Section 7.3.11, and modify Section >>>10.2.1 to say how to recover that and what to do when >>>a prohibited SNACK is received. >>> >>>[mk] The updated iSER draft will follow the suggestion in 8a. Also >>>updated text in section 3.3 and section 8.3 on SNACK handling. >>> >>>(9) Section 8.1 uses the phrase "buffer underrun" for an "out >>>of buffers" condition. That should be "buffer exhaustion". >>> >>>[mk] ok >>> >>>(10) Section 8.4 could result in a situation where an iSER Target >>>cannot send a Reject PDU that an iSCSI Target would be >>>able send. It needs to explain what to do in that situation. >>> >>>[mk] The following text has been added in section 8.4: >>>(Implementation note: If the number of outstanding unexpected >>>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the >>>target will not >>>be able to send another unexpected control-type PDU until >>>some outstanding >>>ones have been retired. To ensure that the initiator has a means of >>>retiring outstanding PDUs, the target should reserve the last >>>unexpected >>>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as >>>a NOP-in >>>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>>initiator to return the NOP-out ping response with the >>>current ExpStatSN.) >>> >>>(11) Section 11 on Security Considerations is weak, but the >>>overall approach of appealing to security considerations in >>>other specifications is probably ok. This section needs to >>>be strengthened by saying that since iSER is still functionally >>>iSCSI, all of the iSCSI security considerations in RFC 3720 >>>apply, and it should also reference the discussion of iSCSI >>>security in RFC 3723. >>> >>>[mk] This section now references RFC3723 and the security >>>drafts for RDDP. >>>Both documents have also been added to the list of references. >>> >>>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 >>>---------------------------------------------------- >>> >>>_______________________________________________ >>>Ips mailing list >>>Ips@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ips >>> >>> >> >> >> >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 14 15:42:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHIk-0003Ax-RG; Tue, 14 Jun 2005 15:42:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHIi-000399-VQ for ips@megatron.ietf.org; Tue, 14 Jun 2005 15:42:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24162 for ; Tue, 14 Jun 2005 15:42:19 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiHfF-0002ah-JC for ips@ietf.org; Tue, 14 Jun 2005 16:05:39 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j5EJg8Fh018279; Tue, 14 Jun 2005 15:42:09 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jun 2005 15:42:08 -0400 Message-ID: To: elliott@hp.com, ips@ietf.org Subject: RE: [Ips] New work item: iSCSI Implementer's Guide Date: Tue, 14 Jun 2005 15:42:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.14.24 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CHILD_PORN_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Rob, I don't think advancing iSCSI from SAM-2 to SAM-3 or beyond is a sufficient reason by itself to make incompatible changes, so: - The implementers guide is an ok place to a) remove features, e.g., say that SCSI Asynchronous Event Reporting SHOULD NOT be supported because SAM-3 has made it obsolete, and b) do housekeeping e.g., rename TARGET WARM RESET and TARGET COLD RESET for SAM-3 purposes without functional change. - Added features belong in a separate draft that defines both the feature (e.g., QUERY TASK) and the key used to negotiate whether it is supported. All added features or incompatible iSCSI changes for SAM-3 must be negotiated so that an implementation that provides NotUnderstood responses for all new SAM-3 keys receives RFC 3720 behavior. All-in-all, I think putting all the SAM-3 and related changes into a separate draft is probably better than trying to spread them across two drafts, although I'd have no problem with repeating feature removal (e.g., SCSI Asynchronous Event Reporting SHOULD NOT be implemented) in both the Implementer's Guide and a separate SAM-3 for iSCSI draft. 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: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Elliott, Robert (Server Storage) > Sent: Tuesday, June 14, 2005 11:06 AM > To: ips@ietf.org > Subject: RE: [Ips] New work item: iSCSI Implementer's Guide > > T10 has finished SAM-3 (ANSI INCITS 402-2005) and is wrapping > up SPC-3. > When (and how) should iSCSI be updated from its SAM-2 basis? > > Some changes to consider: > * SCSI Command PDU: add Task Priority field > * SCSI Command PDU ATTR field: make Untagged obsolete > * Asynchronous Message: make SCSI Asynchronous Event Reporting obsolete > * Task Management Function Request PDU: make TARGET RESET obsolete > * Task Management Function Request PDU: add QUERY TASK > * Task Management Function Response PDU Response field: add FUNCTION > SUCCEEDED (for QUERY TASK or any other new function that wants to use > it) > > SAM-4 is still in its early stages, but it includes a new feature that > also warrants consideration: > * SCSI Response PDU: add a Retry Delay field > > -- > Rob Elliott, elliott@hp.com > Hewlett-Packard Industry Standard Server Storage Advanced Technology > https://ecardfile.com/id/RobElliott > > > > > > -----Original Message----- > > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > > Behalf Of Black_David@emc.com > > Sent: Monday, June 13, 2005 2:53 PM > > To: ips@ietf.org > > Subject: [Ips] New work item: iSCSI Implementer's Guide > > > > Everyone, > > > > The IPS WG has received Area Director approval to work on > > an iSCSI Implementers Guide. This will be a standards > > track draft (will become a Proposed Standard RFC) whose > > purpose is to clarify and correct any problems in the > > iSCSI RFC (RFC 3720). It is **not** a license to > > revisit iSCSI design decisions, make major changes to > > the iSCSI protocol or add major functionality to iSCSI, > > although it may be a means to discourage implementation > > of things that aren't in use (e.g., a sentence saying > > that iSCSI markers SHOULD NOT be implemented would be > > within reason). > > > > I want to thank Mallikarjun for agreeing to edit this > > draft. The initial version should be submitted with a > > name of draft-ietf-ips-iscsi-impl-guide-00.txt or > > something like that. > > > > To a first approximation, the things that belong in > > the implementers guide are things that an implementer wishes > > s/he had known after first reading RFC 3720 ... but had > > to learn/figure out the hard way. So far, we have two > > topics for this draft: > > - Update to task management function handling when multiple > > tasks are to be terminated (Mallikarjun C.). > > - Explanation of why REPORT LUNS command cannot cause an > > iSCSI overrun (David B.). > > If Eddy Q. comes up with a specific proposal to clarify > > some error conditions that a target should not be REQUIRED > > to check (and we agree to it), that could be a third topic. > > Those who would like to see other topics covered should send > > those suggestions to the list, but be aware than any suggestion > > to cover a topic will be interpreted as an offer to write > > text describing it ... > > > > My initial intention is to hold this draft open for a while > > so that we can pick up more issues as they arise - at the > > moment, my thinking is to hold this open for at least a year. > > > > 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 > > ---------------------------------------------------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 14 17:08:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIeM-0006r7-LS; Tue, 14 Jun 2005 17:08:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIeI-0006qu-33 for ips@megatron.ietf.org; Tue, 14 Jun 2005 17:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06377 for ; Tue, 14 Jun 2005 17:08:39 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiJ0p-00028I-Kh for ips@ietf.org; Tue, 14 Jun 2005 17:32:00 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5EL8QKX021073 for ; Tue, 14 Jun 2005 17:08:26 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5EL8Qhh237852 for ; Tue, 14 Jun 2005 17:08:26 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5EL8Px1025697 for ; Tue, 14 Jun 2005 17:08:25 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5EL8PXJ025659; Tue, 14 Jun 2005 17:08:25 -0400 In-Reply-To: <42AF2882.9020103@rose.hp.com> Importance: Normal MIME-Version: 1.0 To: "Mallikarjun C." Subject: Re: [Ips] WG Last Call Review: iSER X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Tue, 14 Jun 2005 14:08:21 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_04122005|April 12, 2005) at 06/14/2005 17:08:25, Serialize complete at 06/14/2005 17:08:25 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 47f87af9e1d92eac54caf69b67f82b72 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, For any of the option B you have listed, StatSN is advanced. If the PDU is discarded, it then creates a sequence error. Since the iSER draft states that SNACK PDUs are not used, creating a sequence error on purpose can be problematic for the initiator. Since you are personally agreeable to option A, I suggest we stick with this simpler and cleaner solution for this corner case. The wording "SHOULD discard" in my revised text could be misconstrued to imply option B (ii). To make it clear that it is option A that is the intended course of action, the revised text in section 8.1.2 now reads as follows: "If the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the iSCSI Layer at the target MUST NOT generate and send any unexpected PDU even if the PDU is used to indicate an iSCSI error condition (e.g., Asynchronous Message, Reject). Task timeouts as in the initiator waiting for a command completion, will ensure that correct operational behavior will result in these cases despite the missing PDU." Mike To: Mike Ko cc: ips@ietf.org Subject: Re: [Ips] WG Last Call Review: iSER Mike, >In > section 6.7 of RFC3720, if the initiator receives a PDU with a payload > digest error, as long as there is no header digest error, the initiator > need not take any action if the PDU is an unexpected PDU (e.g., Async, > Reject). You may have discovered a piece of somewhat misleading text for the implementer's guide. The 6.7 text clearly says that the PDU with a payload digest error must be discarded - the StatSN of a discarded PDU must not be considered as received. This is analogous to the target throwing away the entire command PDU (including the CmdSN) even when there's a payload digest error on the immediate data (6.7 describes this case as well). OTOH, I see that the "no further action is necessary" piece of text is misleading at best, since it could imply that no status SNACKs are necessary when in fact they are. I am adding it to my to-do list for the new draft. >Since the target knows that it is a Reject (or Async) PDU > that it wants to send and it is the lack of buffer resources at the > initiator that is preventing it from sending the PDU, a less destructive > way of handling this corner case is to discard the PDU and NOT advance > StatSN. I am inclined to suggest that we make no exceptions to cover for a seriously corner case, making implementations' life even more complex. At this point, I think there are two legitimate Options for the iSCSI Layer to deal with this corner case - A) Do not generate any unexpected PDUs if there's no currently available credit. B) Generate the PDU as always. (i) Wait for the credit to become available. (ii) Don't wait, discard the generated PDU immediately. (iii) A combination thereof, wait for sometime and discard based on implementation considerations, e.g. resource pressure. IMHO, Option A should never consume a StatSN and Option B (all its sub-cases) should always consume a StatSN. I prefer this approach because in an Option B implementation, depending on the implementation, the next target-to-initiator PDU "in the line" may have already taken the "next number" of StatSN. In the replacement text I suggested earlier, I was leaning towards "B-(ii) with StatSN consumed" semantics. Rethinking this now, I see that there are wire protocol implications depending on the Option. One can argue that A is better, and I'd be personally agreeable to it. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mike Ko wrote: > Mallikarjun, > > Should change "SHOULD NOT advance StatSN" to "MUST NOT advance StatSN". > > Mike > Sent by: ips-bounces@ietf.org > To: "Mallikarjun C." > cc: ips@ietf.org > Subject: Re: [Ips] WG Last Call Review: iSER > > > Mallikarjun, > > Thanks for your review. I have incorporated all of your suggestions in > the iSER draft except for the revised text for section 8.1.2. I have some > problem with the discarded PDU being treated as a lost PDU by the > initiator. Since the target can always send the SCSI Response PDU > (because it is expected and not bound by the MaxOutstandingUnexpectedPDUs > limit), this will appear to the initiator as an out of order StatSN and > section 6.8 of RFC3720 requires that "it MUST address the one or more > missing status PDUs as described in Section 6.7 Digest Errors." In > section 6.7 of RFC3720, if the initiator receives a PDU with a payload > digest error, as long as there is no header digest error, the initiator > need not take any action if the PDU is an unexpected PDU (e.g., Async, > Reject). This is the desired result. But a lost PDU would appear as a > header digest error and RFC3720 stipulates that the iSCSI layer can close > the connection. This is not the desired result. In other words, the > initiator can live with losing a Reject PDU if it knows it is a Reject PDU > that is lost. Since the target knows that it is a Reject (or Async) PDU > that it wants to send and it is the lack of buffer resources at the > initiator that is preventing it from sending the PDU, a less destructive > way of handling this corner case is to discard the PDU and NOT advance > StatSN. So here is my suggested revised text for section 8.1.2: > > "If the number of outstanding unexpected control-type PDUs equals > MaxOutstandingUnexpectedPDUs, the iSCSI layer at the target will not be > able to send another unexpected control-type PDU until some outstanding > ones have been retired. In this case the the iSCSI layer at the target > SHOULD discard the unexpected PDU and if the PDU is discarded, it SHOULD > NOT advance StatSN. Task timeouts as in the initiator waiting for a > command completion, will ensure that the correct operational behavior will > result in these cases despite the discarded PDU." > > Mike > Sent by: ips-bounces@ietf.org > To: ips@ietf.org > cc: > Subject: Re: [Ips] WG Last Call Review: iSER > > > Hi Mike, > > Some comments on the text discussed in this thread. > > 7.3.11 > > Get rid of " In particular, the Proactive (Time out) SNACK MUST NOT be > issued." It is redundant now with the MUST NOT that precedes it. > > > 3.3 (new replacement text) > > Change bullet 4 to: > > 4. The iSCSI Layer at the initiator MUST NOT issue SNACKs for PDUs. > > > 8.1.2 (new text) > > Suggest changing the text to: > > "If the number of outstanding unexpected control-type PDUs equals > MaxOutstandingUnexpectedPDUs, the target iSCSI layer will not be > able to send another unexpected control-type PDU until some outstanding > ones have been retired. In this case the the iSCSI layer SHOULD > discard the unexpected PDU and allow the initiator iSCSI layer > to respond to the resulting error (the discard in the target iSCSI > layer manifests as as a lost PDU on the initiator). Task or sequence > timeouts - as in the initiator waiting for a command completion - > will ensure that the correct operational behavior will result in these > cases despite the discarded PDU." > > 10.2.1 (new text) > > Suggest changing it to: > "As described in section 7.3.11, SNACK PDUs are not used by the iSCSI > Layer in the iSER-assisted mode." > > 11 (new text) > > Suggest changing it to: > Since iSER-asisted iSCSI protocol is still functionally iSCSI from a > security considerations perspective, all of the iSCSI security > requirements as described in [RFC3720] and [RFC3723] apply. " > > > Thanks. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Mike Ko wrote: > >>David, >> >>On rereading section 3, bullet 1 should have been separated out from the >>other bullets. Bullet 1 addressed the issue where an iSER > > implementation > >>attempts a connection with a non-iSER one, and it mandates that >>iSER-assisted mode must not be used if RDMAExtensions is negotiated to >>"No". But the remaining bullets deal with the situation assuming >>RDMAExtensions have been negotiated to "Yes". If the connection is to >>operate in iSER-assisted mode, then the rest of the bullets (except > > bullet > >>1) must be followed. If any of the other bullets are not followed, then >>the connection cannot really fall back to traditional iSCSI mode since >>RDMAExtensions have been negotiated to "Yes". Not implementing those >>other bullets in an iSER-assisted mode is an error. So here is the >>proposed new text for section 3.3: >> >>--- start of replacement section 3.3 >>To operate in an iSER-assisted mode, the iSCSI Layers at both the >>initiator and the target MUST negotiate the RDMAExtensions key (see >>section 6.3) to "Yes" on the leading connection. If the RDMAExtensions >>key is not negotiated to "Yes", then iSER-assisted mode MUST NOT be > > used. > >>If the RDMAExtensons key is negotiated to "Yes" but the invocation of > > the > >>Allocate_Connection_Resources Operational Primitive to the iSER layer >>fails, the iSCSI layer MUST fail the iSCSI Login process or terminate > > the > >>connection as appropriate. See section 10.1.3.1 for details. >> >>If the RDMAExtensions key is negotiated to "Yes", the iSCSI Layer MUST >>satisfy the following protocol usage requirements from the iSER > > protocol: > >>1. The iSCSI Layer at the initiator MUST set ExpDataSN = 0 in Task >>Management Function Requests for Task Allegiance Reassignment for >>read/bidirectional commands, so as to cause the target to send all >>unacknowledged read data. >> >>2. The iSCSI Layer at the target MUST always return the SCSI status >>in a separate SCSI Response PDU for read commands, i.e., there MUST NOT > > be > >>a "phase collapse" in concluding a SCSI Read Command. >> >>3. The iSCSI Layers at both the initiator and the target MUST > > support > >>the keys as defined in section 6 on Login/Text Operational Keys. If > > used > >>as specified, these keys MUST NOT be answered with NotUnderstood and the >>semantics as defined MUST be followed for each iSER-assisted connection. >> >>4. The iSCSI Layer at the initiator MUST NOT issue proactive (based >>on time-outs) SNACKs for PDUs that it presumes are lost. >> >>--- end of replacement section 3.3 >> >>For section 8.4 (now section 8.1.2), if the iSER target wants to send a >>Reject but couldn't do so because of the limits imposed by >>MaxOutstandingUnexpectedPDUs, the PDU will be discarded. To the >>initiator, this is similar to receiving a Reject PDU with a digest > > error. > >>Section 6.7 of RFC3720 states that "When an initiator receives any iSCSI >>PDU with a payload digest error, it MUST discard the PDU." Furthermore, >>"No further action is necessary for initiators if the discarded PDU is > > an > >>unsolicited PDU (e.g., Async, Reject). Task timeouts as in the > > initiator > >>waiting for a command completion, or process >>timeouts, as in the target waiting for a Logout, will ensure that the >>correct operational behavior will result in these cases despite the >>discarded PDU." >> >>It is incumbent upon the initiator to declare a reasonable limit on >>MaxOutstandingUnexpectedPDUs to avoid the situation where the target has >>to discard a PDU due to lack of resources on the initiator's side. As >>stated in section 8.1, shared buffer pools can always be used to > > minimize > >>the risk. I can modify the new text in section 8.1.2 as follows: >> >>"If the number of outstanding unexpected control-type PDUs equals >>MaxOutstandingUnexpectedPDUs, the target will not be able to send > > another > >>unexpected control-type PDU until some outstanding ones have been > > retired. > >> In this case the unexpected PDU will be discarded and not sent by the >>target. Task timeouts as in the initiator waiting for a command >>completion, or process timeouts, as in the target waiting for a Logout, >>will ensure that the correct operational behavior will result in these >>cases despite the discarded PDU. >> >>(Implementation note: To ensure that the initiator has a means to > > inform > >>the target that outstanding PDUs have been retired, the target should >>reserve ... with the current ExpStatSN.)" >> >>Mike >>To: mako@almaden.ibm.com >>cc: ips@ietf.org >>Subject: RE: [Ips] WG Last Call Review: iSER >> >> >>Mike, >> >>There are a couple of problems in what you propose: >> >> >> >>>(3) Section 3.3., item 5. says "MUST successfully negotiate >>>the TargetRecvDataSegmentLength key". Again there's a "takes >>>two to negotiate" problem, and the "failed to successfully >>>negotiate" case needs to be specified. >>> >>>[mk] The old items 4 and 5 are now replaced by the new item 4 >>>with the following text: >>> >>>"The iSCSI Layers at both the initiator and the target MUST >>>support the keys as defined in section 6 on Login/Text Operational Keys. >>>If used as specified, these keys MUST NOT be answered with NotUnderstood >>>and the semantics as defined MUST be followed for each iSER-assisted >>>connection." >> >> >>That would be ok for the case where there are iSER systems on both >>ends of a connection, but your new text indirectly forbids connecting >>an iSER implementation to a non-iSER one (i.e., Traditional iSCSI), >>as this would violate the first MUST (at least one of the systems >>will not support the new keys). This text (and all of the negotiation >>text) needs to be rephrased to apply to a single system, and specify >>requirements on that system - if iSER is to be used, then the following >>keys MUST be offered or responded to in negotiation *and* if this >>negotiation fails for any reason (e.g., a NotUnderstood response, or >>lack of an offered key that would be necessary to use iSER), then >>iSER MUST NOT be used, and traditional iSCSI is used instead. It >>is important to specify the fallback-to-Traditional-iSCSI cases in >>the negotiation requirements, as appealing to the covering "in order >>to use iSER" text is not enough because it doesn't cover what happens >>when negotiation fails. This needs to be done at least in Section 5.1 >>also. >> >> >> >>>(10) Section 8.4 could result in a situation where an iSER Target >>>cannot send a Reject PDU that an iSCSI Target would be >>>able send. It needs to explain what to do in that situation. >>> >>>[mk] The following text has been added in section 8.4: >>>(Implementation note: If the number of outstanding unexpected >>>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will >> >>not >> >> >> >>>be able to send another unexpected control-type PDU until some >> >>outstanding >> >> >> >>>ones have been retired. To ensure that the initiator has a means of >>>retiring outstanding PDUs, the target should reserve the last unexpected >>>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in >>>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>>initiator to return the NOP-out ping response with the >>>current ExpStatSN.) >> >> >>While that helps, it still doesn't respond to the comment's request to >>explain what an iSER target should do when it wants to send a Reject PDU >>but cannot due to this limitation. Is the target required to remember >>the PDU that caused the reject until it gets enough space to send a >>Reject? How much effort does it put into obtaining permission to send >>the Reject before doing something else, and what is that something else? >> >>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: Mike Ko [mailto:mako@almaden.ibm.com] >>>Sent: Monday, June 13, 2005 1:10 AM >>>To: Black_David@emc.com >>>Cc: ips@ietf.org >>>Subject: Re: [Ips] WG Last Call Review: iSER >>> >>>David, >>> >>>Thanks for the review. Please see my comments inline. >>> >>>Mike >>>Sent by: ips-bounces@ietf.org >>>To: ips@ietf.org >>>cc: >>>Subject: [Ips] WG Last Call Review: iSER >>> >>> >>>I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, >>>and in addition to editorial issues that I will send >>>directly to Mike, I found a number of technical issues: >>> >>>(1) Section 3.3 has a structural problem in that the first >>>sentence says "should satisfy" and the remaining sentences >>>to be satisfied are expressed as "MUST" requirements. The >>>net result is that all the requirements in that section are >>>"should" requirements, which is not what was intended. >>>The first sentence needs to be rewritten to say something >>>to the effect of "In order to use iSER, the following MUST >>>be done:" . >>> >>>[mk] ok >>> >>>(2) Section 3.3, item 1. says "MUST negotiate the >>>RDMAExtensions key to "Yes" " Since the key is negotiated >>>(not declared) and it takes two to negotiate, that requirement >>>cannot be achieved by an implementation if the other side >>>doesn't cooperate. This needs to be rewritten to talk about >>>offering the key as "Yes" and replying as "Yes" and that >>>if the result is not "Yes" then iSER is not used (traditional >>>iSCSI is used instead). >>> >>>[mk] ok >>> >>>(3) Section 3.3., item 5. says "MUST successfully negotiate >>>the TargetRecvDataSegmentLength key". Again there's a "takes >>>two to negotiate" problem, and the "failed to successfully >>>negotiate" case needs to be specified. >>> >>>[mk] The old items 4 and 5 are now replaced by the new item 4 >>>with the >>>follwowing text: >>> >>>"The iSCSI Layers at both the initiator and the target MUST >>>support the >>>keys as defined in section 6 on Login/Text Operational Keys. >>>If used as >>>specified, these keys MUST NOT be answered with NotUnderstood and the >>>semantics as defined MUST be followed for each iSER-assisted >>>connection." >>> >>>(4) Section 5.1, last two paragraphs have similar problems in >>>that they specify required negotiation behavior without >>>describing what to do when the other side doesn't cooperate >>>or do what it is supposed to. Those failure cases need to >>>be covered. >>> >>>[mk] The new text for comment #3 should address this issue. >>> >>>(5) Section 5.1.2, in the Note at the very end of the section >>>about two steps needing to be atomic, "must" should be "MUST". >>> >>>[mk] ok >>> >>>(6) Section 5.1.3 is missing specification and explanation of >>>version negotiation and version numbers in the iSER Hello >>>Exchange. The error case instructions for when version >>>negotiation fails need to be copied here in addition to their >>>current location in Section 10.1.3.2 . >>> >>>[mk] ok >>> >>>(7) Section 7.3.9 - I believe sending of Login Request or Login >>>Response in Datamover mode is always an error. This section >>>should say so and say what to do about it. >>> >>>[mk] ok >>> >>>(8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling >>>does not work because the instruction in 10.2.1 to handle SNACK >>>as per RFC 3720 would require retransmission of non-existent >>>Data and R2T PDUs. I can see a couple of possible corrective >>>approaches: >>>a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK >>>PDUs (instead of the current SHOULD NOT) and change >>>Section 10.2.1 to define reception of any SNACK PDU as >>>an error. >>>b) Put limits on what SNACK PDUs can be used to recover >>>(Status only?) in Section 7.3.11, and modify Section >>>10.2.1 to say how to recover that and what to do when >>>a prohibited SNACK is received. >>> >>>[mk] The updated iSER draft will follow the suggestion in 8a. Also >>>updated text in section 3.3 and section 8.3 on SNACK handling. >>> >>>(9) Section 8.1 uses the phrase "buffer underrun" for an "out >>>of buffers" condition. That should be "buffer exhaustion". >>> >>>[mk] ok >>> >>>(10) Section 8.4 could result in a situation where an iSER Target >>>cannot send a Reject PDU that an iSCSI Target would be >>>able send. It needs to explain what to do in that situation. >>> >>>[mk] The following text has been added in section 8.4: >>>(Implementation note: If the number of outstanding unexpected >>>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the >>>target will not >>>be able to send another unexpected control-type PDU until >>>some outstanding >>>ones have been retired. To ensure that the initiator has a means of >>>retiring outstanding PDUs, the target should reserve the last >>>unexpected >>>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as >>>a NOP-in >>>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>>initiator to return the NOP-out ping response with the >>>current ExpStatSN.) >>> >>>(11) Section 11 on Security Considerations is weak, but the >>>overall approach of appealing to security considerations in >>>other specifications is probably ok. This section needs to >>>be strengthened by saying that since iSER is still functionally >>>iSCSI, all of the iSCSI security considerations in RFC 3720 >>>apply, and it should also reference the discussion of iSCSI >>>security in RFC 3723. >>> >>>[mk] This section now references RFC3723 and the security >>>drafts for RDDP. >>>Both documents have also been added to the list of references. >>> >>>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 >>>---------------------------------------------------- >>> >>>_______________________________________________ >>>Ips mailing list >>>Ips@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ips >>> >>> >> >> >> >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jun 15 18:13:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dig8W-0005pr-6t; Wed, 15 Jun 2005 18:13:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dig8T-0005mr-QD for ips@megatron.ietf.org; Wed, 15 Jun 2005 18:13:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10881 for ; Wed, 15 Jun 2005 18:13:22 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DigVE-0001ho-Oq for ips@ietf.org; Wed, 15 Jun 2005 18:36:57 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id 3418C17F0; Wed, 15 Jun 2005 15:13:18 -0700 (PDT) Received: from [127.0.0.1] (palnai12-1017.corp.hp.com [15.244.195.249]) by rosemail.rose.hp.com (Postfix) with ESMTP id 7507B80E3; Wed, 15 Jun 2005 15:07:57 -0700 (PDT) Message-ID: <42B0A800.60909@rose.hp.com> Date: Wed, 15 Jun 2005 15:13:20 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Ko Subject: Re: [Ips] WG Last Call Review: iSER References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d01c7b9466fe967a5df27b46fdb03146 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mike, I am generally ok with this except for editorials (suggested text below). It had also occurred to me that the initiator-to-target transfer has the same upper bound issue, the draft should address that as well. "While the number of outstanding unexpected control-type PDUs equals MaxOutstandingUnexpectedPDUs, the iSCSI Layer at the target MUST NOT generate any unexpected PDUs which otherwise it would have generated, even if its intent is to indicate an iSCSI error condition (e.g., Asynchronous Message, Reject). Task timeouts as in the initiator waiting for a command completion or other connection and session level exceptions will ensure that correct operational behavior will result in these cases despite not generating the PDU." I have a different editorial/technical on 8.1.1 - "At any time, the number of outstanding PDUs MUST not exceed MaxOutstandingUnexpectedPDUs." should be: "At any time, the number of outstanding unexpected PDUs (i.e. immediate commands, and one-way NOP-Outs) MUST NOT exceed the target-advertised value of MaxOutstandingUnexpectedPDUs." And a similar comment on similar text in 8.1.2. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mike Ko wrote: > Mallikarjun, > > For any of the option B you have listed, StatSN is advanced. If the PDU > is discarded, it then creates a sequence error. Since the iSER draft > states that SNACK PDUs are not used, creating a sequence error on purpose > can be problematic for the initiator. Since you are personally agreeable > to option A, I suggest we stick with this simpler and cleaner solution for > this corner case. The wording "SHOULD discard" in my revised text could > be misconstrued to imply option B (ii). To make it clear that it is > option A that is the intended course of action, the revised text in > section 8.1.2 now reads as follows: > > "If the number of outstanding unexpected control-type PDUs equals > MaxOutstandingUnexpectedPDUs, the iSCSI Layer at the target MUST NOT > generate and send any unexpected PDU even if the PDU is used to indicate > an iSCSI error condition (e.g., Asynchronous Message, Reject). Task > timeouts as in the initiator waiting for a command completion, will ensure > that correct operational behavior will result in these cases despite the > missing PDU." > > Mike > To: Mike Ko > cc: ips@ietf.org > Subject: Re: [Ips] WG Last Call Review: iSER > > > Mike, > > >>In >>section 6.7 of RFC3720, if the initiator receives a PDU with a payload >>digest error, as long as there is no header digest error, the initiator >>need not take any action if the PDU is an unexpected PDU (e.g., Async, >>Reject). > > > You may have discovered a piece of somewhat misleading text for the > implementer's guide. > > The 6.7 text clearly says that the PDU with a payload digest error must > be discarded - the StatSN of a discarded PDU must not be considered as > received. This is analogous to the target throwing away the entire > command PDU (including the CmdSN) even when there's a payload digest > error on the immediate data (6.7 describes this case as well). > > OTOH, I see that the "no further action is necessary" piece of text is > misleading at best, since it could imply that no status SNACKs are > necessary when in fact they are. > > I am adding it to my to-do list for the new draft. > > >>Since the target knows that it is a Reject (or Async) PDU >>that it wants to send and it is the lack of buffer resources at the >>initiator that is preventing it from sending the PDU, a less destructive >>way of handling this corner case is to discard the PDU and NOT advance >>StatSN. > > > I am inclined to suggest that we make no exceptions to cover for a > seriously corner case, making implementations' life even more complex. > > At this point, I think there are two legitimate Options for the iSCSI > Layer to deal with this corner case - > > A) Do not generate any unexpected PDUs if there's no currently > available credit. > > B) Generate the PDU as always. > (i) Wait for the credit to become available. > (ii) Don't wait, discard the generated PDU immediately. > (iii) A combination thereof, wait for sometime and discard > based on implementation considerations, e.g. resource > pressure. > > IMHO, Option A should never consume a StatSN and Option B (all its > sub-cases) should always consume a StatSN. I prefer this approach > because in an Option B implementation, depending on the implementation, > the next target-to-initiator PDU "in the line" may have already taken > the "next number" of StatSN. > > In the replacement text I suggested earlier, I was leaning towards > "B-(ii) with StatSN consumed" semantics. Rethinking this now, I see > that there are wire protocol implications depending on the Option. One > can argue that A is better, and I'd be personally agreeable to it. > > Thanks. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Mike Ko wrote: > >>Mallikarjun, >> >>Should change "SHOULD NOT advance StatSN" to "MUST NOT advance StatSN". >> >>Mike >>Sent by: ips-bounces@ietf.org >>To: "Mallikarjun C." >>cc: ips@ietf.org >>Subject: Re: [Ips] WG Last Call Review: iSER >> >> >>Mallikarjun, >> >>Thanks for your review. I have incorporated all of your suggestions in >>the iSER draft except for the revised text for section 8.1.2. I have > > some > >>problem with the discarded PDU being treated as a lost PDU by the >>initiator. Since the target can always send the SCSI Response PDU >>(because it is expected and not bound by the > > MaxOutstandingUnexpectedPDUs > >>limit), this will appear to the initiator as an out of order StatSN and >>section 6.8 of RFC3720 requires that "it MUST address the one or more >>missing status PDUs as described in Section 6.7 Digest Errors." In >>section 6.7 of RFC3720, if the initiator receives a PDU with a payload >>digest error, as long as there is no header digest error, the initiator >>need not take any action if the PDU is an unexpected PDU (e.g., Async, >>Reject). This is the desired result. But a lost PDU would appear as a >>header digest error and RFC3720 stipulates that the iSCSI layer can > > close > >>the connection. This is not the desired result. In other words, the >>initiator can live with losing a Reject PDU if it knows it is a Reject > > PDU > >>that is lost. Since the target knows that it is a Reject (or Async) PDU >>that it wants to send and it is the lack of buffer resources at the >>initiator that is preventing it from sending the PDU, a less destructive >>way of handling this corner case is to discard the PDU and NOT advance >>StatSN. So here is my suggested revised text for section 8.1.2: >> >>"If the number of outstanding unexpected control-type PDUs equals >>MaxOutstandingUnexpectedPDUs, the iSCSI layer at the target will not be >>able to send another unexpected control-type PDU until some outstanding >>ones have been retired. In this case the the iSCSI layer at the target >>SHOULD discard the unexpected PDU and if the PDU is discarded, it SHOULD >>NOT advance StatSN. Task timeouts as in the initiator waiting for a >>command completion, will ensure that the correct operational behavior > > will > >>result in these cases despite the discarded PDU." >> >>Mike >>Sent by: ips-bounces@ietf.org >>To: ips@ietf.org >>cc: >>Subject: Re: [Ips] WG Last Call Review: iSER >> >> >>Hi Mike, >> >>Some comments on the text discussed in this thread. >> >>7.3.11 >> >>Get rid of " In particular, the Proactive (Time out) SNACK MUST NOT be >>issued." It is redundant now with the MUST NOT that precedes it. >> >> >>3.3 (new replacement text) >> >>Change bullet 4 to: >> >>4. The iSCSI Layer at the initiator MUST NOT issue SNACKs for PDUs. >> >> >>8.1.2 (new text) >> >>Suggest changing the text to: >> >>"If the number of outstanding unexpected control-type PDUs equals >>MaxOutstandingUnexpectedPDUs, the target iSCSI layer will not be >>able to send another unexpected control-type PDU until some outstanding >>ones have been retired. In this case the the iSCSI layer SHOULD >>discard the unexpected PDU and allow the initiator iSCSI layer >>to respond to the resulting error (the discard in the target iSCSI >>layer manifests as as a lost PDU on the initiator). Task or sequence >>timeouts - as in the initiator waiting for a command completion - >>will ensure that the correct operational behavior will result in these >>cases despite the discarded PDU." >> >>10.2.1 (new text) >> >>Suggest changing it to: >>"As described in section 7.3.11, SNACK PDUs are not used by the iSCSI >>Layer in the iSER-assisted mode." >> >>11 (new text) >> >>Suggest changing it to: >>Since iSER-asisted iSCSI protocol is still functionally iSCSI from a >>security considerations perspective, all of the iSCSI security >>requirements as described in [RFC3720] and [RFC3723] apply. " >> >> >>Thanks. >> >>Mallikarjun >> >>Mallikarjun Chadalapaka >>Networked Storage Architecture >>StorageWorks Division >>Hewlett-Packard MS 5668 >>Roseville CA 95747 >>cbm [at] rose.hp.com >> >> >>Mike Ko wrote: >> >> >>>David, >>> >>>On rereading section 3, bullet 1 should have been separated out from the >>>other bullets. Bullet 1 addressed the issue where an iSER >> >>implementation >> >> >>>attempts a connection with a non-iSER one, and it mandates that >>>iSER-assisted mode must not be used if RDMAExtensions is negotiated to >>>"No". But the remaining bullets deal with the situation assuming >>>RDMAExtensions have been negotiated to "Yes". If the connection is to >>>operate in iSER-assisted mode, then the rest of the bullets (except >> >>bullet >> >> >>>1) must be followed. If any of the other bullets are not followed, then >>>the connection cannot really fall back to traditional iSCSI mode since >>>RDMAExtensions have been negotiated to "Yes". Not implementing those >>>other bullets in an iSER-assisted mode is an error. So here is the >>>proposed new text for section 3.3: >>> >>>--- start of replacement section 3.3 >>>To operate in an iSER-assisted mode, the iSCSI Layers at both the >>>initiator and the target MUST negotiate the RDMAExtensions key (see >>>section 6.3) to "Yes" on the leading connection. If the RDMAExtensions >>>key is not negotiated to "Yes", then iSER-assisted mode MUST NOT be >> >>used. >> >> >>>If the RDMAExtensons key is negotiated to "Yes" but the invocation of >> >>the >> >> >>>Allocate_Connection_Resources Operational Primitive to the iSER layer >>>fails, the iSCSI layer MUST fail the iSCSI Login process or terminate >> >>the >> >> >>>connection as appropriate. See section 10.1.3.1 for details. >>> >>>If the RDMAExtensions key is negotiated to "Yes", the iSCSI Layer MUST >>>satisfy the following protocol usage requirements from the iSER >> >>protocol: >> >> >>>1. The iSCSI Layer at the initiator MUST set ExpDataSN = 0 in Task >>>Management Function Requests for Task Allegiance Reassignment for >>>read/bidirectional commands, so as to cause the target to send all >>>unacknowledged read data. >>> >>>2. The iSCSI Layer at the target MUST always return the SCSI status >>>in a separate SCSI Response PDU for read commands, i.e., there MUST NOT >> >>be >> >> >>>a "phase collapse" in concluding a SCSI Read Command. >>> >>>3. The iSCSI Layers at both the initiator and the target MUST >> >>support >> >> >>>the keys as defined in section 6 on Login/Text Operational Keys. If >> >>used >> >> >>>as specified, these keys MUST NOT be answered with NotUnderstood and the >>>semantics as defined MUST be followed for each iSER-assisted connection. >>> >>>4. The iSCSI Layer at the initiator MUST NOT issue proactive (based >>>on time-outs) SNACKs for PDUs that it presumes are lost. >>> >>>--- end of replacement section 3.3 >>> >>>For section 8.4 (now section 8.1.2), if the iSER target wants to send a >>>Reject but couldn't do so because of the limits imposed by >>>MaxOutstandingUnexpectedPDUs, the PDU will be discarded. To the >>>initiator, this is similar to receiving a Reject PDU with a digest >> >>error. >> >> >>>Section 6.7 of RFC3720 states that "When an initiator receives any iSCSI >>>PDU with a payload digest error, it MUST discard the PDU." Furthermore, >>>"No further action is necessary for initiators if the discarded PDU is >> >>an >> >> >>>unsolicited PDU (e.g., Async, Reject). Task timeouts as in the >> >>initiator >> >> >>>waiting for a command completion, or process >>>timeouts, as in the target waiting for a Logout, will ensure that the >>>correct operational behavior will result in these cases despite the >>>discarded PDU." >>> >>>It is incumbent upon the initiator to declare a reasonable limit on >>>MaxOutstandingUnexpectedPDUs to avoid the situation where the target has >>>to discard a PDU due to lack of resources on the initiator's side. As >>>stated in section 8.1, shared buffer pools can always be used to >> >>minimize >> >> >>>the risk. I can modify the new text in section 8.1.2 as follows: >>> >>>"If the number of outstanding unexpected control-type PDUs equals >>>MaxOutstandingUnexpectedPDUs, the target will not be able to send >> >>another >> >> >>>unexpected control-type PDU until some outstanding ones have been >> >>retired. >> >> >>>In this case the unexpected PDU will be discarded and not sent by the >>>target. Task timeouts as in the initiator waiting for a command >>>completion, or process timeouts, as in the target waiting for a Logout, >>>will ensure that the correct operational behavior will result in these >>>cases despite the discarded PDU. >>> >>>(Implementation note: To ensure that the initiator has a means to >> >>inform >> >> >>>the target that outstanding PDUs have been retired, the target should >>>reserve ... with the current ExpStatSN.)" >>> >>>Mike >>>To: mako@almaden.ibm.com >>>cc: ips@ietf.org >>>Subject: RE: [Ips] WG Last Call Review: iSER >>> >>> >>>Mike, >>> >>>There are a couple of problems in what you propose: >>> >>> >>> >>> >>>>(3) Section 3.3., item 5. says "MUST successfully negotiate >>>>the TargetRecvDataSegmentLength key". Again there's a "takes >>>>two to negotiate" problem, and the "failed to successfully >>>>negotiate" case needs to be specified. >>>> >>>>[mk] The old items 4 and 5 are now replaced by the new item 4 >>>>with the following text: >>>> >>>>"The iSCSI Layers at both the initiator and the target MUST >>>>support the keys as defined in section 6 on Login/Text Operational > > Keys. > >>>>If used as specified, these keys MUST NOT be answered with > > NotUnderstood > >>>>and the semantics as defined MUST be followed for each iSER-assisted >>>>connection." >>> >>> >>>That would be ok for the case where there are iSER systems on both >>>ends of a connection, but your new text indirectly forbids connecting >>>an iSER implementation to a non-iSER one (i.e., Traditional iSCSI), >>>as this would violate the first MUST (at least one of the systems >>>will not support the new keys). This text (and all of the negotiation >>>text) needs to be rephrased to apply to a single system, and specify >>>requirements on that system - if iSER is to be used, then the following >>>keys MUST be offered or responded to in negotiation *and* if this >>>negotiation fails for any reason (e.g., a NotUnderstood response, or >>>lack of an offered key that would be necessary to use iSER), then >>>iSER MUST NOT be used, and traditional iSCSI is used instead. It >>>is important to specify the fallback-to-Traditional-iSCSI cases in >>>the negotiation requirements, as appealing to the covering "in order >>>to use iSER" text is not enough because it doesn't cover what happens >>>when negotiation fails. This needs to be done at least in Section 5.1 >>>also. >>> >>> >>> >>> >>>>(10) Section 8.4 could result in a situation where an iSER Target >>>>cannot send a Reject PDU that an iSCSI Target would be >>>>able send. It needs to explain what to do in that situation. >>>> >>>>[mk] The following text has been added in section 8.4: >>>>(Implementation note: If the number of outstanding unexpected >>>>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the target will >>> >>>not >>> >>> >>> >>> >>>>be able to send another unexpected control-type PDU until some >>> >>>outstanding >>> >>> >>> >>> >>>>ones have been retired. To ensure that the initiator has a means of >>>>retiring outstanding PDUs, the target should reserve the last > > unexpected > >>>>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as a NOP-in >>>>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>>>initiator to return the NOP-out ping response with the >>>>current ExpStatSN.) >>> >>> >>>While that helps, it still doesn't respond to the comment's request to >>>explain what an iSER target should do when it wants to send a Reject PDU >>>but cannot due to this limitation. Is the target required to remember >>>the PDU that caused the reject until it gets enough space to send a >>>Reject? How much effort does it put into obtaining permission to send >>>the Reject before doing something else, and what is that something else? >>> >>>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: Mike Ko [mailto:mako@almaden.ibm.com] >>>>Sent: Monday, June 13, 2005 1:10 AM >>>>To: Black_David@emc.com >>>>Cc: ips@ietf.org >>>>Subject: Re: [Ips] WG Last Call Review: iSER >>>> >>>>David, >>>> >>>>Thanks for the review. Please see my comments inline. >>>> >>>>Mike >>>>Sent by: ips-bounces@ietf.org >>>>To: ips@ietf.org >>>>cc: >>>>Subject: [Ips] WG Last Call Review: iSER >>>> >>>> >>>>I have reviewed the iSER draft, draft-ietf-ips-iser-03.txt, >>>>and in addition to editorial issues that I will send >>>>directly to Mike, I found a number of technical issues: >>>> >>>>(1) Section 3.3 has a structural problem in that the first >>>>sentence says "should satisfy" and the remaining sentences >>>>to be satisfied are expressed as "MUST" requirements. The >>>>net result is that all the requirements in that section are >>>>"should" requirements, which is not what was intended. >>>>The first sentence needs to be rewritten to say something >>>>to the effect of "In order to use iSER, the following MUST >>>>be done:" . >>>> >>>>[mk] ok >>>> >>>>(2) Section 3.3, item 1. says "MUST negotiate the >>>>RDMAExtensions key to "Yes" " Since the key is negotiated >>>>(not declared) and it takes two to negotiate, that requirement >>>>cannot be achieved by an implementation if the other side >>>>doesn't cooperate. This needs to be rewritten to talk about >>>>offering the key as "Yes" and replying as "Yes" and that >>>>if the result is not "Yes" then iSER is not used (traditional >>>>iSCSI is used instead). >>>> >>>>[mk] ok >>>> >>>>(3) Section 3.3., item 5. says "MUST successfully negotiate >>>>the TargetRecvDataSegmentLength key". Again there's a "takes >>>>two to negotiate" problem, and the "failed to successfully >>>>negotiate" case needs to be specified. >>>> >>>>[mk] The old items 4 and 5 are now replaced by the new item 4 >>>>with the >>>>follwowing text: >>>> >>>>"The iSCSI Layers at both the initiator and the target MUST >>>>support the >>>>keys as defined in section 6 on Login/Text Operational Keys. >>>>If used as >>>>specified, these keys MUST NOT be answered with NotUnderstood and the >>>>semantics as defined MUST be followed for each iSER-assisted >>>>connection." >>>> >>>>(4) Section 5.1, last two paragraphs have similar problems in >>>>that they specify required negotiation behavior without >>>>describing what to do when the other side doesn't cooperate >>>>or do what it is supposed to. Those failure cases need to >>>>be covered. >>>> >>>>[mk] The new text for comment #3 should address this issue. >>>> >>>>(5) Section 5.1.2, in the Note at the very end of the section >>>>about two steps needing to be atomic, "must" should be "MUST". >>>> >>>>[mk] ok >>>> >>>>(6) Section 5.1.3 is missing specification and explanation of >>>>version negotiation and version numbers in the iSER Hello >>>>Exchange. The error case instructions for when version >>>>negotiation fails need to be copied here in addition to their >>>>current location in Section 10.1.3.2 . >>>> >>>>[mk] ok >>>> >>>>(7) Section 7.3.9 - I believe sending of Login Request or Login >>>>Response in Datamover mode is always an error. This section >>>>should say so and say what to do about it. >>>> >>>>[mk] ok >>>> >>>>(8) Sections 7.3.11 and 10.2.1 - The specified SNACK handling >>>>does not work because the instruction in 10.2.1 to handle SNACK >>>>as per RFC 3720 would require retransmission of non-existent >>>>Data and R2T PDUs. I can see a couple of possible corrective >>>>approaches: >>>>a) Change Section 7.3.11 to prohibit (MUST NOT) sending SNACK >>>>PDUs (instead of the current SHOULD NOT) and change >>>>Section 10.2.1 to define reception of any SNACK PDU as >>>>an error. >>>>b) Put limits on what SNACK PDUs can be used to recover >>>>(Status only?) in Section 7.3.11, and modify Section >>>>10.2.1 to say how to recover that and what to do when >>>>a prohibited SNACK is received. >>>> >>>>[mk] The updated iSER draft will follow the suggestion in 8a. Also >>>>updated text in section 3.3 and section 8.3 on SNACK handling. >>>> >>>>(9) Section 8.1 uses the phrase "buffer underrun" for an "out >>>>of buffers" condition. That should be "buffer exhaustion". >>>> >>>>[mk] ok >>>> >>>>(10) Section 8.4 could result in a situation where an iSER Target >>>>cannot send a Reject PDU that an iSCSI Target would be >>>>able send. It needs to explain what to do in that situation. >>>> >>>>[mk] The following text has been added in section 8.4: >>>>(Implementation note: If the number of outstanding unexpected >>>>control-type PDUs equals MaxOutstandingUnexpectedPDUs, the >>>>target will not >>>>be able to send another unexpected control-type PDU until >>>>some outstanding >>>>ones have been retired. To ensure that the initiator has a means of >>>>retiring outstanding PDUs, the target should reserve the last >>>>unexpected >>>>control-type PDU allowable by MaxOutstandingUnexpectedPDUs as >>>>a NOP-in >>>>ping request with ITT = 0xffffffff and TTT != 0xffffffff to allow the >>>>initiator to return the NOP-out ping response with the >>>>current ExpStatSN.) >>>> >>>>(11) Section 11 on Security Considerations is weak, but the >>>>overall approach of appealing to security considerations in >>>>other specifications is probably ok. This section needs to >>>>be strengthened by saying that since iSER is still functionally >>>>iSCSI, all of the iSCSI security considerations in RFC 3720 >>>>apply, and it should also reference the discussion of iSCSI >>>>security in RFC 3723. >>>> >>>>[mk] This section now references RFC3723 and the security >>>>drafts for RDDP. >>>>Both documents have also been added to the list of references. >>>> >>>>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 >>>>---------------------------------------------------- >>>> >>>>_______________________________________________ >>>>Ips mailing list >>>>Ips@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ips >>>> >>>> >>> >>> >>> >>> >>>_______________________________________________ >>>Ips mailing list >>>Ips@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ips >> >> >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips >> >> >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips >> >> >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jun 17 21:57:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjSaV-0004W4-NO; Fri, 17 Jun 2005 21:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjSaU-0004Va-2m for ips@megatron.ietf.org; Fri, 17 Jun 2005 21:57:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11288 for ; Fri, 17 Jun 2005 21:57:31 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjSxg-0006SM-Bx for ips@ietf.org; Fri, 17 Jun 2005 22:21:33 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id 2C6EC4030CD for ; Fri, 17 Jun 2005 18:57:31 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.36]) by rosemail.rose.hp.com (Postfix) with ESMTP id 793C07FFE for ; Fri, 17 Jun 2005 18:52:02 -0700 (PDT) Message-ID: <42B37F91.5020800@rose.hp.com> Date: Fri, 17 Jun 2005 18:57:37 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Ips] MaxOutstandingUnexpectedPDUs X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mike & I had an offline discussion on the current description of this key in the iSER spec, which I stumbled on in addressing the Last Call comments. I suggested changing the current text (excuse my delayed comment). While Mike is agreeable to the change, we thought we should poll the list for any objections. The current text reads: 6.7 MaxOutstandingUnexpectedPDUs ....... MaxOutstandingUnexpectedPDUs= Default is None AFAICT, this will be the only official key with a "numerical-value" label that can also take a "None" string value. This may (or may not) challenge some parsers. So my suggested change was: 6.7 MaxOutstandingUnexpectedPDUs ....... MaxOutstandingUnexpectedPDUs= Default is 0 And then to define the semantics of the default 0 (unlimited). Does anyone have an objection to this change? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Jun 18 02:20:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjWgm-0007Is-Cx; Sat, 18 Jun 2005 02:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjWgi-0007Ik-Dz; Sat, 18 Jun 2005 02:20:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13925; Sat, 18 Jun 2005 02:20:12 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjX3v-0002jr-Cy; Sat, 18 Jun 2005 02:44:16 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5I6K3mf187070; Sat, 18 Jun 2005 06:20:03 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5I6K3EI099266; Sat, 18 Jun 2005 08:20:03 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5I6K2KT024102; Sat, 18 Jun 2005 08:20:03 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j5I6K2J0024099; Sat, 18 Jun 2005 08:20:02 +0200 In-Reply-To: <000301c57043$769dcce0$9101a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05032005NP May 03, 2005 From: Julian Satran Message-ID: Date: Sat, 18 Jun 2005 01:19:56 -0500 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 18/06/2005 09:20:02, Serialize complete at 18/06/2005 09:20:02 X-Spam-Score: 2.6 (++) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: ips@ietf.org, ips-bounces@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0015321540==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0015321540== Content-Type: text/html; charset="US-ASCII"
Eddy,

Why  should we say what an I or T is not expected to do - except in case of errors?
At best it should say "are not mandated" instead of "not expected"  and it would be redundant and somewhat harmful (some will interpret as a license to improve by doing something beyond "mandated").

Julo



"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

13/06/2005 13:12

To
"Mallikarjun C." <cbm@rose.hp.com>, <ips@ietf.org>
cc
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET





Actually, I was talking about a clarification of what is expected of the
target and initiator in the event that the RFC does not cover it with a
MUST. The problem is that some people think the target must check for all
protocol errors. This is not practical and sometimes not even possible for
all cases.

Perhaps wording similar to this would be in order:

"Except where specifically noted, the initiator and target are
not expected to catch all protocol errors introduced by the other
party and it is the implementers option as to which errors may be
caught due to internal dynamics."

Eddy

----- Original Message -----
From: "Mallikarjun C." <cbm@rose.hp.com>
To: <ips@ietf.org>
Sent: Friday, June 10, 2005 2:00 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


> My comment on this is that such a blanket statement will be a problem.
>
> RFC 3720 has a defined notion of protocol errors and their handling, and
> uses a fair number of MUSTs (sometimes conditional) on Rejects (as PDUs
> and in negotiation) - e.g., if you support data digests, you must discard
> a bad digest PDU with a Reject.  These actions inherently require protocol
> validation and catching errors.  I don't think we want to weaken any of
> that.
>
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> StorageWorks Division
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
>
>
> Eddy Quicksall wrote:
>> What do you think  about this? I don't remember seeing an answer.
>>
>> Eddy
>>
>> ----- Original Message ----- From: "Eddy Quicksall"
>> <eddy_quicksall_iVivity_iSCSI@comcast.net>
>> To: <Black_David@emc.com>; <cbm@rose.hp.com>; <ips@ietf.org>
>> Sent: Friday, June 03, 2005 12:45 PM
>> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET
>>
>>
>>> If you are going to write this guide, I would like to suggest that a
>>> paragraph be added saying something like "the initiator and target are
>>> not expected to catch all protocol errors introduced by the other party
>>> and it is the implementers option as to which errors may be caught due
>>> to internal dynamics, crash dynamics or data corruption".
>>>
>>> Eddy
>>>
>>> ----- Original Message ----- From: <Black_David@emc.com>
>>> To: <cbm@rose.hp.com>; <ips@ietf.org>
>>> Sent: Friday, June 03, 2005 8:51 AM
>>> Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET
>>>
>>>
>>>> Mallikarjun,
>>>>
>>>>> I am concerned that the current lack of detailed specification would
>>>>> allow targets that might even cause silent data corruptions
>>>>> to qualify as RFC 3720-compliant.
>>>>>
>>>>> Here are what I believe to be semantics applicable to all TMF requests
>>>>> that can potentially terminate multiple tasks.  I do not know the IETF
>>>>> process well enough here, but I suggest that we consider this text
>>>>> replacing the existing section 10.6.2 in RFC 3720 - so the new text
>>>>> can
>>>>> cover all the TMFs that can impact multiple tasks.  This is basically
>>>>> a
>>>>> superset of the current 10.6.2 semantics.
>>>>
>>>>
>>>> IETF does have an errata process, but (IMHO) it's not a great venue
>>>> for something like this that it's important for implementers to pay
>>>> attention to.  What I would suggest is that we start an Internet-Draft
>>>> that is intended to become an Implementers Guide RFC (standards track)
>>>> to include both technical corrections like this one, and explanations
>>>> of subtle points such as how to deal with (what appear to be) REPORT
>>>> LUNS overruns as discussed here earlier.  An available example is that
>>>> an implementers guide draft is being maintained for SCTP (see
>>>> draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that
>>>> an iSCSI implementers guide won't grow to that size.
>>>>
>>>> For this task management issue, explaining what the problem is and why
>>>> the change fixes it in an implementers guide is at least as important
>>>> as
>>>> specifying the change.  For the REPORT LUNS overruns, the implementers
>>>> guide text would be an explanation of why no change is needed,
>>>> including
>>>> some elaboration on the (less than completely obvious) SPC-2 text that
>>>> specifies the behavior of REPORT LUNS in this circumstance.  Before I
>>>> go looking for another volunteer, would you be interested in editing
>>>> an implementers guide Internet Draft?  Between Julian and I, we should
>>>> be able write the REPORT LUNS explanation paragraph or two.
>>>>
>>>> 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
>>>> ----------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Ips mailing list
>>>> Ips@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ips
>>>
>>>
>>>
>>> _______________________________________________
>>> Ips mailing list
>>> Ips@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ips
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--===============0015321540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0015321540==-- From ips-bounces@ietf.org Mon Jun 20 16:34:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSyH-0007gX-Sv; Mon, 20 Jun 2005 16:34:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSyG-0007gS-5i for ips@megatron.ietf.org; Mon, 20 Jun 2005 16:34:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08354 for ; Mon, 20 Jun 2005 16:34:14 -0400 (EDT) Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkTM1-0004oE-Nd for ips@ietf.org; Mon, 20 Jun 2005 16:58:51 -0400 Received: from smtp2.corp.netapp.com (10.57.159.114) by mx2.netapp.com with ESMTP; 20 Jun 2005 13:34:03 -0700 X-IronPort-AV: i="3.93,216,1115017200"; d="scan'208"; a="250280181:sNHT17798472" Received: from [10.60.8.108] ([10.60.8.108]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j5KKY2kL004477; Mon, 20 Jun 2005 13:34:03 -0700 (PDT) Message-ID: <42B727FC.9030108@netapp.com> Date: Mon, 20 Jun 2005 16:33:00 -0400 From: David Wysochanski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] New work item: iSCSI Implementer's Guide References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Black_David@emc.com wrote: > Everyone, > > The IPS WG has received Area Director approval to work on > an iSCSI Implementers Guide. This will be a standards > track draft (will become a Proposed Standard RFC) whose > purpose is to clarify and correct any problems in the > iSCSI RFC (RFC 3720). It is **not** a license to > revisit iSCSI design decisions, make major changes to > the iSCSI protocol or add major functionality to iSCSI, > although it may be a means to discourage implementation > of things that aren't in use (e.g., a sentence saying > that iSCSI markers SHOULD NOT be implemented would be > within reason). > > I want to thank Mallikarjun for agreeing to edit this > draft. The initial version should be submitted with a > name of draft-ietf-ips-iscsi-impl-guide-00.txt or > something like that. > > To a first approximation, the things that belong in > the implementers guide are things that an implementer wishes > s/he had known after first reading RFC 3720 ... but had > to learn/figure out the hard way. So far, we have two > topics for this draft: > - Update to task management function handling when multiple > tasks are to be terminated (Mallikarjun C.). > - Explanation of why REPORT LUNS command cannot cause an > iSCSI overrun (David B.). > If Eddy Q. comes up with a specific proposal to clarify > some error conditions that a target should not be REQUIRED > to check (and we agree to it), that could be a third topic. > Those who would like to see other topics covered should send > those suggestions to the list, but be aware than any suggestion > to cover a topic will be interpreted as an offer to write > text describing it ... > I would propose a clarification of the ISID rule in discovery sessions, as outlined (at least partially) here: http://www1.ietf.org/mail-archive/web/ips/current/msg00882.html > My initial intention is to hold this draft open for a while > so that we can pick up more issues as they arise - at the > moment, my thinking is to hold this open for at least a year. > > 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 > ---------------------------------------------------- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 20 19:48:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkW0T-00020g-Gk; Mon, 20 Jun 2005 19:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkW0R-00020O-KL for ips@megatron.ietf.org; Mon, 20 Jun 2005 19:48:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22464 for ; Mon, 20 Jun 2005 19:48:42 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkWOD-00017q-Ub for ips@ietf.org; Mon, 20 Jun 2005 20:13:20 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5KNmV6V007708 for ; Mon, 20 Jun 2005 19:48:31 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5KNmVLd262318 for ; Mon, 20 Jun 2005 19:48:31 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5KNmVI4020620 for ; Mon, 20 Jun 2005 19:48:31 -0400 Received: from [9.56.227.90] (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5KNmVnN020614 for ; Mon, 20 Jun 2005 19:48:31 -0400 Importance: Normal MIME-Version: 1.0 To: ips@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Mon, 20 Jun 2005 16:48:29 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_06092005|June 09, 2005) at 06/20/2005 19:48:30, Serialize complete at 06/20/2005 19:48:30 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ips] Retiring unexpected PDUs X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun and I have an offline discussion on immediate commands and how they should be retired. In iSCSI, an immediate command can be rejected for out of resource conditions at the target. But the Reject PDU may not get sent if the limit imposed by MaxOutstandingUnexpectedPDUs declared by the initiator is reached at the target. To avoid the situation where the credit consumed by the immediate command is lost forever, the following rule to retire outstanding PDUs in the unexpected category (where the immediate flag is set) is proposed to be incorporated in iSER: "An oustanding PDU in this category is retired as follows. If the CmdSN of the PDU sent by the intiator in this category is x, the PDU is outstanding until the initiator sends a non-immediate control-type PDU on the same connection with CmdSN = y (where y is at least x) and the target responds with a control-type PDU on any connection where ExpCmdSN is at least y+1." This rule is the same as the one previously used for retiring unidirectional NOP-Outs. It is now the only rule for retiring all unexpected PDUs where the immediate flag is set and replaces all other rules. Please comment if you find a problem with this approach. Mike _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jun 21 16:13:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp87-0005zD-Hr; Tue, 21 Jun 2005 16:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp83-0005sh-4w; Tue, 21 Jun 2005 16:13:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01446; Tue, 21 Jun 2005 16:13:49 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpW0-0001EG-7H; Tue, 21 Jun 2005 16:38:37 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc12) with SMTP id <2005062120133601200mf8o5e>; Tue, 21 Jun 2005 20:13:36 +0000 Message-ID: <002601c5769d$b4b76cb0$03031eac@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Tue, 21 Jun 2005 16:13:35 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b Cc: ips@ietf.org, ips-bounces@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0496201416==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0496201416== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C5767C.2D1329A0" This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C5767C.2D1329A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Not mandated sounds good. We could drop the "... and it is the ... = clause if it is not of any informational use. "Except where specifically noted, the initiator and target are not mandated to catch all protocol errors introduced by the other party and it is the implementers option as to which errors may be caught." Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: Mallikarjun C. ; ips@ietf.org ; ips-bounces@ietf.org=20 Sent: Saturday, June 18, 2005 2:19 AM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Eddy,=20 Why should we say what an I or T is not expected to do - except in = case of errors?=20 At best it should say "are not mandated" instead of "not expected" = and it would be redundant and somewhat harmful (some will interpret as a = license to improve by doing something beyond "mandated").=20 Julo=20 "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 13/06/2005 13:12=20 To "Mallikarjun C." , =20 cc =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 Actually, I was talking about a clarification of what is expected of = the=20 target and initiator in the event that the RFC does not cover it with = a=20 MUST. The problem is that some people think the target must check for = all=20 protocol errors. This is not practical and sometimes not even possible = for=20 all cases. Perhaps wording similar to this would be in order: "Except where specifically noted, the initiator and target are not expected to catch all protocol errors introduced by the other party and it is the implementers option as to which errors may be caught due to internal dynamics." Eddy ----- Original Message -----=20 From: "Mallikarjun C." To: Sent: Friday, June 10, 2005 2:00 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > My comment on this is that such a blanket statement will be a = problem. > > RFC 3720 has a defined notion of protocol errors and their handling, = and=20 > uses a fair number of MUSTs (sometimes conditional) on Rejects (as = PDUs=20 > and in negotiation) - e.g., if you support data digests, you must = discard=20 > a bad digest PDU with a Reject. These actions inherently require = protocol=20 > validation and catching errors. I don't think we want to weaken any = of=20 > that. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Eddy Quicksall wrote: >> What do you think about this? I don't remember seeing an answer. >> >> Eddy >> >> ----- Original Message ----- From: "Eddy Quicksall"=20 >> >> To: ; ; >> Sent: Friday, June 03, 2005 12:45 PM >> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET >> >> >>> If you are going to write this guide, I would like to suggest that = a=20 >>> paragraph be added saying something like "the initiator and target = are=20 >>> not expected to catch all protocol errors introduced by the other = party=20 >>> and it is the implementers option as to which errors may be caught = due=20 >>> to internal dynamics, crash dynamics or data corruption". >>> >>> Eddy >>> >>> ----- Original Message ----- From: >>> To: ; >>> Sent: Friday, June 03, 2005 8:51 AM >>> Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET >>> >>> >>>> Mallikarjun, >>>> >>>>> I am concerned that the current lack of detailed specification = would >>>>> allow targets that might even cause silent data corruptions >>>>> to qualify as RFC 3720-compliant. >>>>> >>>>> Here are what I believe to be semantics applicable to all TMF = requests >>>>> that can potentially terminate multiple tasks. I do not know = the IETF >>>>> process well enough here, but I suggest that we consider this = text >>>>> replacing the existing section 10.6.2 in RFC 3720 - so the new = text=20 >>>>> can >>>>> cover all the TMFs that can impact multiple tasks. This is = basically=20 >>>>> a >>>>> superset of the current 10.6.2 semantics. >>>> >>>> >>>> IETF does have an errata process, but (IMHO) it's not a great = venue >>>> for something like this that it's important for implementers to = pay >>>> attention to. What I would suggest is that we start an = Internet-Draft >>>> that is intended to become an Implementers Guide RFC (standards = track) >>>> to include both technical corrections like this one, and = explanations >>>> of subtle points such as how to deal with (what appear to be) = REPORT >>>> LUNS overruns as discussed here earlier. An available example is = that >>>> an implementers guide draft is being maintained for SCTP (see >>>> draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to = believe that >>>> an iSCSI implementers guide won't grow to that size. >>>> >>>> For this task management issue, explaining what the problem is = and why >>>> the change fixes it in an implementers guide is at least as = important=20 >>>> as >>>> specifying the change. For the REPORT LUNS overruns, the = implementers >>>> guide text would be an explanation of why no change is needed,=20 >>>> including >>>> some elaboration on the (less than completely obvious) SPC-2 text = that >>>> specifies the behavior of REPORT LUNS in this circumstance. = Before I >>>> go looking for another volunteer, would you be interested in = editing >>>> an implementers guide Internet Draft? Between Julian and I, we = should >>>> be able write the REPORT LUNS explanation paragraph or two. >>>> >>>> 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 >>>> ---------------------------------------------------- >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>> >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0023_01C5767C.2D1329A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Not mandated sounds good. We could drop the "... and = it is the=20 ... clause if it is not of any informational use.
 
"Except where specifically = noted, the=20 initiator and target are
not mandated to catch all protocol = errors=20 introduced by the other
party and it is the implementers option as to = which=20 errors may be
caught."
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Saturday, June 18, 2005 = 2:19=20 AM
Subject: Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET


Eddy, =

Why  should we say what an I or T is = not expected=20 to do - except in case of errors?
At=20 best it should say "are not mandated" instead of "not expected" =  and it=20 would be redundant and somewhat harmful (some will interpret as a = license to=20 improve by doing something beyond "mandated").

Julo



"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20
Sent by: ips-bounces@ietf.org=20

13/06/2005 13:12

To
"Mallikarjun C." <cbm@rose.hp.com>, = <ips@ietf.org>=20
cc
Subject
Re: [Ips] ABORT TASK vs = ABORT=20 TASK SET

=




Actually, I was talking about a clarification of what is = expected of=20 the
target and initiator in the event that the RFC does not cover = it with=20 a
MUST. The problem is that some people think the target must = check for=20 all
protocol errors. This is not practical and sometimes not even = possible=20 for
all cases.

Perhaps wording similar to this would be in=20 order:

"Except where specifically noted, the initiator and = target=20 are
not expected to catch all protocol errors introduced by the=20 other
party and it is the implementers option as to which errors = may=20 be
caught due to internal dynamics."

Eddy

----- = Original=20 Message -----
From: "Mallikarjun C." = <cbm@rose.hp.com>
To:=20 <ips@ietf.org>
Sent: Friday, June 10, 2005 2:00 = PM
Subject: Re:=20 [Ips] ABORT TASK vs ABORT TASK SET


> My comment on this = is that=20 such a blanket statement will be a problem.
>
> RFC 3720 = has a=20 defined notion of protocol errors and their handling, and
> = uses a fair=20 number of MUSTs (sometimes conditional) on Rejects (as PDUs
> = and in=20 negotiation) - e.g., if you support data digests, you must discard =
> a=20 bad digest PDU with a Reject.  These actions inherently require = protocol=20
> validation and catching errors.  I don't think we want = to weaken=20 any of
> that.
>
> Mallikarjun
>
> = Mallikarjun=20 Chadalapaka
> Networked Storage Architecture
> = StorageWorks=20 Division
> Hewlett-Packard MS 5668
> Roseville CA = 95747
>=20 cbm [at] rose.hp.com
>
>
> Eddy Quicksall = wrote:
>>=20 What do you think  about this? I don't remember seeing an=20 answer.
>>
>> Eddy
>>
>> ----- = Original=20 Message ----- From: "Eddy Quicksall"
>>=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>
>> To:=20 <Black_David@emc.com>; <cbm@rose.hp.com>;=20 <ips@ietf.org>
>> Sent: Friday, June 03, 2005 12:45=20 PM
>> Subject: Re: [Ips] ABORT TASK vs ABORT TASK=20 SET
>>
>>
>>> If you are going to write = this=20 guide, I would like to suggest that a
>>> paragraph be = added=20 saying something like "the initiator and target are
>>> = not=20 expected to catch all protocol errors introduced by the other party=20
>>> and it is the implementers option as to which errors = may be=20 caught due
>>> to internal dynamics, crash dynamics or = data=20 corruption".
>>>
>>>=20 Eddy
>>>
>>> ----- Original Message ----- = From:=20 <Black_David@emc.com>
>>> To: = <cbm@rose.hp.com>;=20 <ips@ietf.org>
>>> Sent: Friday, June 03, 2005 8:51=20 AM
>>> Subject: RE: [Ips] ABORT TASK vs ABORT TASK=20 SET
>>>
>>>
>>>>=20 Mallikarjun,
>>>>
>>>>> I am = concerned that=20 the current lack of detailed specification = would
>>>>> allow=20 targets that might even cause silent data = corruptions
>>>>>=20 to qualify as RFC=20 3720-compliant.
>>>>>
>>>>> Here = are what=20 I believe to be semantics applicable to all TMF=20 requests
>>>>> that can potentially terminate = multiple=20 tasks.  I do not know the IETF
>>>>> process = well=20 enough here, but I suggest that we consider this = text
>>>>>=20 replacing the existing section 10.6.2 in RFC 3720 - so the new text=20
>>>>> can
>>>>> cover all the = TMFs that=20 can impact multiple tasks.  This is basically =
>>>>>=20 a
>>>>> superset of the current 10.6.2=20 semantics.
>>>>
>>>>
>>>> = IETF=20 does have an errata process, but (IMHO) it's not a great=20 venue
>>>> for something like this that it's important = for=20 implementers to pay
>>>> attention to.  What I = would=20 suggest is that we start an Internet-Draft
>>>> that is = intended to become an Implementers Guide RFC (standards=20 track)
>>>> to include both technical corrections like = this=20 one, and explanations
>>>> of subtle points such as how = to deal=20 with (what appear to be) REPORT
>>>> LUNS overruns as = discussed=20 here earlier.  An available example is that
>>>> = an=20 implementers guide draft is being maintained for SCTP = (see
>>>>=20 draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe=20 that
>>>> an iSCSI implementers guide won't grow to = that=20 size.
>>>>
>>>> For this task management = issue,=20 explaining what the problem is and why
>>>> the change = fixes it=20 in an implementers guide is at least as important
>>>> = as
>>>> specifying the change.  For the REPORT = LUNS=20 overruns, the implementers
>>>> guide text would be an=20 explanation of why no change is needed,
>>>>=20 including
>>>> some elaboration on the (less than = completely=20 obvious) SPC-2 text that
>>>> specifies the behavior of = REPORT=20 LUNS in this circumstance.  Before I
>>>> go = looking for=20 another volunteer, would you be interested in = editing
>>>> an=20 implementers guide Internet Draft?  Between Julian and I, we=20 should
>>>> be able write the REPORT LUNS explanation = paragraph=20 or two.
>>>>
>>>> = Thanks,
>>>>=20 --David
>>>>=20 = ----------------------------------------------------
>>>> = David=20 L. Black, Senior Technologist
>>>> EMC Corporation, 176 = South=20 St., Hopkinton, MA  01748
>>>> +1 (508) 293-7953 =  =20           FAX: +1 (508) = 293-7786
>>>>=20 black_david@emc.com        Mobile: +1 (978)=20 394-7754
>>>>=20 = ----------------------------------------------------
>>>><= BR>>>>>=20 _______________________________________________
>>>> = Ips=20 mailing list
>>>> Ips@ietf.org
>>>>=20 = https://www1.ietf.org/mailman/listinfo/ips
>>>
>>>= ;
>>>
>>>=20 _______________________________________________
>>> Ips = mailing=20 list
>>> Ips@ietf.org
>>>=20 https://www1.ietf.org/mailman/listinfo/ips
>
>
>=20 _______________________________________________
> Ips mailing=20 list
> Ips@ietf.org
> = https://www1.ietf.org/mailman/listinfo/ips=20


_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0023_01C5767C.2D1329A0-- --===============0496201416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0496201416==-- From ips-bounces@ietf.org Wed Jun 29 15:50:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniZx-0002Dt-QH; Wed, 29 Jun 2005 15:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniZT-0001vf-AY; Wed, 29 Jun 2005 15:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03646; Wed, 29 Jun 2005 15:50:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dniz3-0006fR-9R; Wed, 29 Jun 2005 16:16:33 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DniZO-0000gk-IR; Wed, 29 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iser-04.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Extensions for RDMA Specification Author(s) : M. Ko, et al. Filename : draft-ietf-ips-iser-04.txt,.pdf Pages : 88 Date : 2005-6-29 iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of the Remote Direct Memory Access Protocol (RDMAP). The iWARP protocol suite provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as defined by the iWARP protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iser-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iser-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iser-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-29145057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iser-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iser-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-29145057.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed Jun 29 15:50:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnia8-0002JR-Ag; Wed, 29 Jun 2005 15:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniZU-0001wb-Fc; Wed, 29 Jun 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03665; Wed, 29 Jun 2005 15:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dniz3-0006fQ-Gf; Wed, 29 Jun 2005 16:16:33 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DniZO-0000gf-HT; Wed, 29 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iwarp-da-03.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Datamover Architecture for iSCSI (DA) Author(s) : M. Chadalapaka, et al. Filename : draft-ietf-ips-iwarp-da-03.txt,.pdf Pages : 65 Date : 2005-6-29 iSCSI is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. The Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. The new Datamover protocol provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition would help map iSCSI to generic RDMA-capable IP fabrics in the future comprising TCP, SCTP, and possibly other underlying network transport layers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iwarp-da-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iwarp-da-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iwarp-da-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-29145027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iwarp-da-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iwarp-da-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-29145027.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart--